This week is my seventh anniversary at GitLab, and it’s still a little hard to believe. At this point, there are 82 people who started before me and are still at the company. That’s actually pretty good, 7 years later, when there were about 275 people when I started, so about a third are still here.
If you want to know what happened in the first half of the year, check out my previous reflection post.
Context
After I wrote my last reflection post, we got a new CEO and my manager went on leave. That meant that everyone on the team, except the CEO’s Executive Business Administrator (EBA), went to other teams, including me. I was temporarily moved over to report to the Chief of Staff to the Chief Product Officer (CPO), David Tuan.
Unfortunately, we didn’t know how long exactly I would be in the temporary position, so I’ve been dealing with fairly discreet problems that typically don’t span a long period of time. Nonetheless, they’ve been interesting problems to try to solve.
Handing over the Handbook
As part of the long term plan for the handbook, my ultimate goal was to transfer ownership of the handbook and its related projects to another team.
From October through December 2024, we held various training sessions for the Learning & Development team (L&D), who agreed to take it on. We also improved the handbook development documentation including the maintenance information, and adding a page on search.
In January 2025, we officially transferred ownership.
That’s not to say I’ve stopped contributing to improvements and maintenance. I’ve continued to contribute whenever something comes up, I’m asked to help, or I have time to work on issues I’m interested in completing.
I’m also still listed as one of the handbook code maintainers. And continue to frequently help people with their merge requests.
Investigating Data YAML files and a possible SSOT
We store a bunch of information about how our product and engineering teams are grouped and who’s a part of each group in a folder of data YAML files.
There were a couple of problems that needed to be solved:
- Not all product sections, stages, groups, and the list of team members that belong to each were displaying properly on the product categories page.
- There is no single source of truth (SSOT) for which team member is in which section/stage/group.
The decision was made to have Workday’s specialty field be the SSOT, which is already sync’ed to the team member data files. Eventually, that information will sync to the access control platform Corporate Security is working on, which can include the non-required roles (such as the Support counterpart), and in turn, sync to the current YAML files. Ultimately, the hope is that the data YAML files will not have to be updated manually in terms of who is part of which group in what capacity.
You can check out the data YAML files issue description for more details.
In the meantime, we wanted to update and clean up the data files to the extent that we could:
- Updated the infrastructure team tag to allow for any team member in infra: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/138060
- Added Software Engineer in Test (SET) to listable team members: https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/11595
- Moved team tags to their own field (thanks to AJ for the MR): https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/138203
- Updated all Infrastructure sections, stages, group, and team members: such as https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/138138
Though, the most difficult part was trying to figure out how it all worked in the first place, and the dependencies on the data files. Once I managed to wrap my head around it, I documented the information with a bit of text and (with a little help from AI) a Mermaid diagram.
Team page improvements
While cleaning up the data files, I also made some improvements to the company team page in order to deduplicate the information for individuals.
The issue was that the only thing in the “drop down” filter was the list of entries under “departments” and none of the other fields, so even things like “Engineering” was a manually added entry in “departments”. Unfortunately, because it’s all manually done, it was never up to date, and wasn’t always consistent.
The most obvious solution was to include the fields that are synced from Workday so it’s no longer a manually updated list, and remove the duplicate entries from “departments”.
- Have the “drop down” include “division”: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/138324
- Have the “drop down” include “specialty”: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/138599
Once the specialty field is updated in Workday for consistency, that will be synced over and the drop down should be a lot shorter and “cleaner”.
Monthly release kickoff alternatives
Earlier this year, the decision was made to stop doing monthly release kickoff livestream and videos, so I was asked to look into viable alternatives that would potentially provide the same content, or at least, fulfill the same goal.
It turns out that we have the upcoming releases page, but it had almost nothing on it. After discussing the issue with various people, I updated the page to pull epics and issues using a new set of labels.
I also made a few improvements to how the list is generated:
- Use section and stage names instead of the slugs.
- Add heading anchors and links.
- Filter milestones to release numbers.
- Hide empty stages and milestones.
- Have the list of stages automatically pulled from the relevant YAML files instead of manually hard-coded.
- Refactor the generator to be more performant.
Various content reviews
I was also asked to do a couple of content reviews in the last few months:
- Product direction pages, then getting PMs to acknowledge: https://gitlab.com/gitlab-com/Product/-/issues/14055
- Handbook pages for overlapping content in Product and Engineering: https://gitlab.com/gitlab-com/content-sites/handbook/-/issues/477 ; where I noticed a lot of outdated content and ended up removing 100+ files
There were a couple of things that I started looking into, but they were taken over by other people, so I don’t feel like I did enough to warrant mentioning them.
Mentoring
I’ve continued to mentor within GitLab through the mentorship program, and outside the company, namely with the Support Driven Aspire program.
It’s always great to see the growth that happens during the mentorship program. Aspire is still ongoing, but the Women’s TMRG one wrapped up back in March 2025.
- One mentee said they felt very supported, and appreciated having someone to help them think through improving their interpersonal work situations.
- The other mentee was promoted to the Senior level of their position!
I’m not sure if I would’ve been able to juggle scheduling with 2 mentees normally, but since I had a lighter meeting schedule during most of the mentorship program, it worked out well.
Thanks in non-letter format
I recently noted that instead of waiting however many years it takes me to write a new “Letter of Thanks”, I should just add a thanks section to my reflection posts. Since it’s only been a month since I wrote the list of thanks, I’ll just do a quick summary list for the ones relevant to this time period:
- Thanks to everyone who contributed to the handbook projects, and the L&D team for taking ownership.
- I missed having a team, so thanks to the OCEO team members for having regular chats.
- Of course, thanks to everyone who helped with the projects I’ve been working on, especially Mayra Cabrera, AJ Romaniello, and Jeff Martin for answering questions and helping figure out how our data YAML files work with other systems/tools.
- Last, but definitely not least, many thanks to David Tuan for being my manager for the last 5.5 months, especially as his only direct report (when he normally doesn’t have any), and going through talent assessment during that time.
For the more detailed version, please check out the most recent Letter of Thanks.
On to year 8
I’ve been really enjoying working in R&D again. We’ll see how much longer that lasts.
Considering that my work is more project-based, I may go back to only doing reflection posts once a year, but we’ll see what happens!
Thanks for reading to the end.
