It’s about 2 months early for my 8 year work anniversary reflection. However, my work situation has changed, and it feels like the right time to be reflecting on the past (almost a) year.
It’s interesting that 8 years sounds like a long time, but since I’ve changed divisions a couple of times, it also doesn’t feel super long. Definitely hard to believe it’s been ~2.5 years since I left Support, but I still have coffee chats with all the new team members! (And I’m still waiting for that t-shirt.)
Also intriguing, there are still 65 at the company that started before me, so almost one quarter of the people from when I started. That’s quite good after 8 years.
If you want to know what happened in previous years, take a look at the other reflection posts.
Let me start with follow-ups to a couple of initiatives, then get to the new things.
Handbook maintenance and fixes
I mentioned last time about how I handed over ownership of the handbook. It’s now actually split into two: technical maintenance is under Business Technology Enterprise Applications, and the rest is under People Group.
Since then, I’ve continued to answer questions and help with maintenance when requested or needed, including:
- Fix regression: headings no longer self-link
- Migrate asdf to mise
- May 2025 dependencies
- Delete stale branches
- Fix Slack channel display issue for Technical Writing team
A few things I wanted to complete but hadn’t done so before transferring ownership, so I worked on them when I had time, including:
- Add dark mode to the handbook sites
- Replace aliases with redirects
- Add spec tests for maintenance jobs
- Add folder and file name linting
Dark mode was particularly nice to work on, since after investigating, it turns out that the parent theme had implemented it, so we just needed to turn it on!
Updating our Product Sections, Stages, and Groups list
I mentioned doing an investigation last time on using our data files as the single source of truth (SSOT), which I continued to do in compiling a list of requirements.
We’re actually still waiting for the Workday data to be standardized, but we knew that the list needed to be updated in the meantime with the number of people complaining about it being out of date.
So I documented how changes can be made and compiled a list of changes that were required at the time to bring it up to date. Aside from updating the documentation, and making the changes to the list itself, a lot of other work was done:
- Created a data flow chart to outline dependencies.
- Created an issue template with a list of tasks.
- Created an issue template specifically for codebase changes.
- Added linter validation for required fields, and to check things exist/match.
- Added code in the handbook to display SREs (Infrastructure Engineers) and SETs (Software Engineer in Test).
There’s a full(?) list in the relevant issue Product#14293.
SOX compliance
Because it’s compliance related, I don’t know how much detail I’m allowed to go into, meaning I’m only going to cover what I did in a very general manner.
In previous years, what was required from the Product division had been done by someone who left the company. My manager was originally tagged in, who then asked me to do it.
Some parts were easy enough and involved pulling product features data. Thankfully, for most of the data requests, I had examples from previous years, and could simply follow suit. Of course, when I did it, I documented my methodology instead of only providing the results. Next year, it shouldn’t need my involvement (or at least, less of it).
However, one part required significant change in how it was done. I think the group went through 3-4 iterations before we settled on what we should do. I only ended up heavily involved because Engineering didn’t have anyone with the combination of knowledge and time. It was definitely the most time consuming part of the process. Next year, the idea is we can pull the information from the relevant data set directly. Regardless, I shouldn’t be involved in that part anymore since it’s under Engineering’s purview.
Release post review and maintenance
The release post (18.10 example) used to be written and put together by Product Managers (PMs). Individual PMs would write each entry, and then a PM volunteered or was nominated to be the “release post manager”, who would need to wrangle the final page together, including ensuring all entries were in, and all reviews were completed.
My manager asked me to do a review of the process and suggest options on a path forward. If we wanted to keep some form of the release post, we would still need PMs to write the feature descriptions, and someone to ensure the post gets put together properly and published. However, the existing tech stack didn’t work well and hadn’t been properly maintained in years.
I ended up being in charge of finding volunteers for the release post manager role, and fixed a few issues while we waited for senior leadership to make a decision.
- Job to generate YAML for in-app what’s new
- Regression bug fix: Image not part of auto release post item generation
- Update required release post item fields
- Have triage ops add subtype label when release post item label is present
- Change links button position on release post top item to be consistent with other types
Eventually, a decision was made. More on that in the next reflection.
Deprecating direction pages
One of the biggest problems with the projects that the release posts (and a few other things) belonged to was how long the pipeline would take.
On average, it would take 30 minutes for a single pipeline. Just think, after every change you make, wait up to 30 minutes to see if something is wrong. To merge the change, you would have to wait 30 minutes to see if the merge train pipeline would pass. Sometimes it failed because of a timeout. If that happened, you had to re-run an entirely new pipeline, then have a merge train pipeline pass as well, meaning waiting about 60 minutes.
How is that related to direction pages?
Well, the main reason the pipeline took such a long time was due to the website build job. The build took an extremely long time because it was querying the GitLab API for a list of epics and issues tied to the current and future milestones. The direction pages were the reason the query existed.
I had previously done a content review of the direction pages, where I found 44% had not been updated in the last 6 months. During that review, 32 pages (of 203) were removed. Some were, but many were not updated.
For various reasons, senior leadership wanted the whole set of pages removed.
I was asked to create a new report and implementation plan. Almost a year later, 78% had not been updated in the last 6 months. Additionally, I got analytics to show that the pages got very few views. (Maybe because they’re not kept up to date?)
After finalizing the plan and communications, and giving people plenty of time to respond and move their content, I merged the MR to remove direction pages from the build, along with the necessary redirects. 142 pages were removed altogether, and 9 pages were moved to the handbook.
On a 7 days median, the pipeline was 19 minutes faster, taking less than half of the previous median time!
It’s weird that one of my greatest achievements in the role is removing something, but technical/content debt is real. It’s better to have less information than inaccurate and confusing information out there.
Quick rundown of other things that got done
There are so many things I could include in this post, but in an attempt to not make it too much longer, here is a rundown of a few other things of note that I did:
- Investigated how the bot triages backlog issues and make recommendations, and getting AI triaging turned on for existing issues.
- Helped with moving the product roadmap planning process move from slide decks to GitLab, including backporting items.
- Reviewed R&D and Marketing FY27-Q1 company objective epics.
- Learnt Tableau in order to create a Features requests age dashboard.
- Took over answering/triaging Product-related RFP questions.
- Removed 129 outdated pages/files from the Product and Engineering parts of the handbook.
- Made sure that GitLab Duo was made available for team members’ personal accounts.
- Participated in a Red Team Scavenger Hunt (internal).
- Finally sent out another batch of postcards to team members! I also continue to be the de facto main #postcrossing Slack channel manager.
Thanks
There’s so much I couldn’t have gotten done without people’s help. So in today’s edition of thanks:
I can’t thank Michael Friedrich enough for continuing to collaborate on handbook changes/discussions, and many other things.
Thanks to Jennifer Li, Hercules Merscher, and Bob Van Landuyt for answering so many myriad questions about how our sections, stages, and feature categories data files work with the codebase and related projects, as well as reviewing a bunch of the MR.
Karen Fang for program managing us successfully through the compliance stuff.
Always a great collaborator Lee Tickett, thanks for working on the AI triaging changes.
Thank you charlie for coming up with a security scavenger hunt that I could participate in!
Carolyn Braza for helping me with the numerous Tableau questions I had while I was learning how to use it.
Finally, thank you David Tuan for being a great manager; letting me run with things, while making me stop and strategize more when needed; talking about “the art of saying no”, “the realm of possible”, and “having someone else between you and the bear”; having more confidence in my abilities than I do; leaving some parting advice that I will keep in mind as much as possible; and much more.
Changing managers and reporting lines
So, finally getting to the reason why I wrote this reflection post two months early.
My manager recently left the company. With the departure of the Chief of Staff to CPMO, I’m now reporting directly to our CPMO (Chief Product & Marketing Officer), one of the executive group members. It’s rather unusual. Aside from Executive Business Assistants (EBA, or EA in many other organizations), someone at the Staff level typically reports to a (Senior) Manager, or Director. It was already unusual when I reported to a Chief of Staff (Senior Director or VP), but reporting to an executive is basically unheard of.
Needless to say, I have some trepidation. I worry about the expectations of any senior leader when all their other direct reports are at the Director+ level. My experience is that they always have higher expectations of people in general, and they’re so used to the level of work at the Director+ level, they don’t realize that their expectations don’t necessarily match what is normally expected at the Staff level.
To put it into context, Staff is the equivalent of a Manager. The different levels go in this order (listing the relevant ones):
- Manager, or Staff individual contributor (IC)
- Senior Manager, or Principal IC
- Director
- Senior Director
- VP
- Executive
Nevertheless, I’m also somewhat optimistic. Thankfully, this is not my first time working with senior leaders or executives. I’ve also heard a lot of good things, and have positive impressions about our current CPMO. Before departing, my manager also reassured me that he thinks I’ll do well in the role, and left some parting advice.
Things are always changing
I think I say this every year at this point, but it really is hard to imagine working elsewhere. There are some companies that have been started by former team members, and from what I hear, in many, their company culture is similar. So, maybe those ones.
Things are always changing though, and it certainly keeps work interesting. When I next provide an update will really depend on what happens in the next year.
For now, wish me luck with the new “my job description hasn’t actually changed, but wait, I don’t officially have a job description” role.
