Normally, my blog post would have been up sooner, but I was on a break for a couple of weeks when my work anniversary came around.
This year’s blog posts were also broken up into smaller parts, so this one only covers February 2023 to mid-June 2023.
If you haven’t read them already, you may want to take a look at my first fifth year reflection post and my reflection on being the Acting Chief of Staff to CTO for our fourth quarter to get a sense of what I’ve been doing so far in my fifth year. If you’re a first time reader, you may want to read one or more of my previous reflections posts for more context.
Working more strategically
The longer I’m in the role at the Staff level, the more I’ve been thinking about how my work has shifted, and I’ve had to be more strategic in how I use my time and what I work on.
Measuring the work that I do is still sometimes difficult though since I spend a lot of my time helping people through Slack. It’s easier in GitLab, because I can look up merge requests that I’ve created or approved. While it’s difficult to search for comments and suggestions I’ve made in GitLab, at least it’s there in perpetuity. Slack, on the other hand, has a 90 day retention, and basically no personal analytics. It’s not like I have a graph that says I responded to X number of threads in non-social channels. It’s certainly not something I would try to track myself. Nevertheless, these conversations often end up with internal comments on tickets, or merge requests either that I author or review, which are measurable.
As a result, the biggest shift I’ve noticed is doing more reviews and less authoring of content (handbook and documentation). While I’ve been working towards getting others to author merge requests, it obviously takes time to get people comfortable with doing it themselves. Thankfully, we have great resources to help guide people, team members willing to learn, and my team members know that I’ll help if they’re stuck (plus more often than not, I explicitly offer). I have been doing more code reviews as well, but tend to work on code changes myself more often than not since I feel like I need to continue to improve on my programming skills.
Of course, there are other areas that our team needs to upskill on. Our management team is working on a bunch of things, such as decreasing expertise or knowledge gaps, and getting team members more comfortable offering and leading customer calls.
I’ve been thinking about how we can get team members more comfortable declaring incidents and turning off feature flags, when they suspect there’s a problem. While we consistently say it’s better to declare an incident and decide it’s not one, I still often see hesitation in our team members. Most of the time, the incident manager will decide whether to turn off a feature flag. We also have guidance on dealing with emergencies on turning off feature flags. The team members who work on incidents and have been around longer tend to be better at both of these, so maybe continuing to model this behaviour is the best thing to do.

The concerted efforts my director and I have been working on to more strategically and purposefully choose impactful work for me are in the OKRs. I keep busy with helping others and all the work that crops up, but the OKR gives me a place to focus and progress on something meaningful and impactful.
Q1 OKR: Improving Auth in Support
My Q1 OKR revolved around analyzing gaps and pain points around Authentication and Authorization (Auth for short) within Support. I was primarily working with the Auth Support Pod (essentially a group of learners and experts typically revolving around a topic), but invited everyone on the team to participate if they had interest.
The work involved 3 main parts:
- An analysis of the distribution of Auth expertise across our Support Groups, and determining possible actions where gaps were identified.
- Survey to gauge comfort level and identify pain points.
- Identify actionable pain points and resolve them.
It turns out, Auth is less of a “problematic” area than we had thought, but it was good to get an understanding of that. We did solve a bunch of major pain points though. Thanks to the collaboration and efforts of various people, the highlights of what we got:
- A Google test workspace account for our team.
- A Google SAML and Group Sync demo video added to the documentation.
- Consolidated documentation.
Based on the survey I sent out to the team, we saw an overall positive change from the beginning to the end of the quarter, and no actionable pain points at the end. Yay!

Finally, I took what I learnt from the process and thoughts from a couple other managers to document methods on how to identify and action on needed improvements in a Support Pod. My hope is that any pod lead or manager can use what we’ve documented to help the team upskill and decrease friction with working on tickets in a particular area.
As to Q2, I’m helping our Director of Global Readiness improve how we create and track customer escalations. With Write the Docs, internship for learning work, and then being away, I’ve not really started (even though we’re halfway through the quarter, I know!). So, I’ll include it in my next reflection post.
Building on the product relationship and counterpart role
I mentioned before that I’ve done a lot of work to improve the relationship and communication between Support and the groups I’m a counterpart for. In the last few months, I’ve actually passed my counterpart role for some of the product groups to others in Support. I had too many (5, when we recommend 2 max), and not enough time to pay attention to them. I also wanted to find team members who could more easily find time to sync with the product and engineering managers for the groups, since a bunch of them are in Europe.
As a result, I’ve spent the time being a counterpart more focused on the ones I’ve kept. In particular, I’ve continued to work with Authentication & Authorization (Auth) on:
- drafting and reviewing customer communication,
- adding user-focused content and reviewing (security) release post items,
- feature discussion and work breakdown, especially in regards to Enterprise Users, and
- prioritize issues that Support believe will have a big impact and/or that mention a lot of tickets.
Beyond working with the group itself, I’ve been trying to expand the impact of the work. For example:
- Add Support priority and Support efficiency labels to bug prioritization considerations for all groups.
- Discuss instance-wide setting for GitLab.com where it differs from default.
- Impact analysis for completed Auth Support Priority/Efficiency issues.
Anything that isn’t already on the support counterpart page, I’m documenting as ways to further engage with their group.
Internship for Learning
With having done the Acting Chief of Staff to CTO rotation, I was curious to know what it was like to work within the Chief of Staff Team to CEO. I’m grateful that GitLab has the internship for learning program which anyone can take advantage of. As a result, I’m actually doing it in two parts, working on:
- TeamOps
- Company-wide guidance and CEO OKRs – which I’ll post a blog post about later
Write the Docs Portland 2023
I got the chance to go to Write the Docs in Portland this year. Unfortunately, due to budget constraints, most of the technical writers couldn’t go, and I had to partially fund my trip, but I’m still glad I went. It was good to see what it’s like in the new venue, with the new program format, and to meet a couple of former GitLab technical writers whom I hadn’t met in person.

It was particularly great to go with a friend, and to hang out with the former and current GitLab technical writers. We also got a chance to talk to people working on some open source projects that might help our docs site.
Sadly, I’m not sure I’ll go again unless I get funding and more of the team goes.
5 years and beyond
I’m sure there’s a lot more I could include, but those are my highlights.
Honestly, it’s hard for me to believe it’s been 5 years. At 2 years, it was already the longest I’d stayed in any one workplace (though mostly not by choice). At 4 years, some people cheekily call it the vesting anniversary, because the stock (options) you’re given at hire are fully vested. At 5 years, it’s hard to imagine working anywhere else. I could get hired elsewhere for better benefits, a pension, or a higher salary, but I feel like I’d be giving up a fairly significant amount in terms of the work and work culture. At the very least, I’ve refused a number of recruiters and have no plans to leave.
5 year highlights
I’ve accomplished a lot in the last 5 years, but none of it alone. I am so thankful for all the amazing people I’ve worked with to date. There are too many to list here. Some highlights and most memorable moments (in no particular order) include:
The more obvious ones:
- IPO. (The logo is a tanuki, not a Japanese fox!)
- Getting promoted within my first year, and then three more times until I became a Staff Support Engineer.
- My managers.
- Acting Chief of Staff to CTO.
- CEO shadow.
- Cape Town Summit: excursions including seeing penguins in the “wild” for the first time ever, meeting team members in person for the first time, talking to James (PM) and Mek (Quality) about how important labelling is, and getting a picture of our CEO smiling with the chibibibis.
- New Orleans Contribute (Summit): guest speakers (Matt Mullenweg, Ariel Waldman), board game night, and hanging out with Support in the support team room.
Ones that I’ve mentioned before:
- “We trust you to contribute.”
- Being the only person in Support to pair or coffee chat with every other Support team member.
- Updating our Support Portal theme, when I thought I’d left web development behind.
- Getting Support Priority and Efficiency labels added to bug prioritization criteria, and the Auth group’s milestone planning; plus analyzing impact.
- Doing a small backend change to save an engineer’s worth of resources.
- Presenting at Support Driven Expo.
- A Support team member telling me my blog posts convinced them to accept GitLab’s offer.
- Helping a mentee get promoted.
- Stan, Engineering Fellow, recognizing me as a SAML expert.
Ones that I don’t think I’ve mentioned before:
- Breaking GitLab FOSS master, and the “blameless” way it was handled. (We later added “Run as if FOSS” by default to our pipeline.)
- Becoming the Docs/UX support counterpart, and the first support counterpart before it was called that.
- Interviewing and starting from 4 different cities. (Yay remote!)
- Being invited to apply to a Backend Engineer position.
- Getting the documentation training module added as a requirement in Support onboarding.
- Lyle saying that together, we’d written 80% of the support workflows. (With over 500 MRs in the company group that may very well be true.)
I started at GitLab when it was 275-280 team members with 20(?) in support. There’s now ~110 who started before me, with 12 in Support. I am also the most tenured SaaS Support hire. It’s been quite a journey, and look forward to what’s next.
Thank you
Thanks for reading to the end, and here’s to the tanuki!
