It’s a bit mind boggling to me that I’m talking about my sixth year at GitLab. It’s not quite been half (5 months), but as I’m internally transferring out of Support, I thought this was a good place to break up “the year”.
First time readers may want to check out my previous reflection posts.
Some may think that the title of this blog post is a bit odd, because I’ve been helping other team members, especially others in Support, more or less since I started at GitLab. At the Staff level in Support though, one of the things we’re thinking about is how to help others not just individually, but at scale. What can you do to be helping 80%+ of the team, and those beyond the team?
My Q2 (May to July) and Q3 (August to October) OKRs (Objective and Key Results) were focused on things at scale and helping others.
Q2 OKR: Auto-creation of account escalation resources
I mentioned the Q2 OKR before on integrating a Slack command into an existing Slack app (managed by the infrastructure team) to auto-create a bunch of the things necessary (issue, Slack channel, Google doc) when an account is escalated. The goal was to make it easier for anyone (typically Customer Success, or Support) to get everything they need to start an account escalation.
I’d never written in Golang so it took longer than I expected. I also decided to start with only creating the issue as a proof of concept/minimal thing so that we could test it, since it shouldn’t be hard to add things that the command creates. Thanks to another Support Engineer, Manu, who helped debug errors, we got the code to the point where the code worked, and the pipeline passed. Unfortunately, the merge request got stalled on my trying to get access to test it.
It’s not wasted effort though, since the code is there, and once our Director of Global Readiness works things out with the infrastructure maintainers, someone should be able to pick it up and move it forward.
You may notice that my Q2 OKR was on the lighter side. Partly, it was that I had other work-related things going on, like Write the Docs. The main reason we didn’t add to it though was that I ended up dealing with some health issues. It wasn’t life threatening, but I could barely sleep and my productivity took a nose dive until I finally got to see a specialist. When planning for my Q3 OKR, my director focused on things that played to my strengths, so that even when I wasn’t feeling 100%, I could make progress on it.
Q3 OKR: Supporting Support Engineers
In a way, the Q3 OKR was a bit of a mishmash of stuff, but we both agreed that they were all important things to get done.
GET Training
Every quarter, we have a training objective, where each region decides on a topic to focus on and have a specific number of people complete it. Typically, the KRs are taken by managers in the respective regions. I’m not familiar with the GitLab Environment Toolkit (GET), but I could certainly send out reminders and such. Thanks to Ben Prescott (the other Staff Support Engineer) for putting together a training schedule (as EMEA was also doing GET), and for helping review some completed training modules. Next quarter, to increase completion rate, it might be good to try combining accountability buddy and body doubling.
Start up a Runner pod
There was actually very little work involved, so I’m not sure it really should have been a KR, but we threw it in there as a “stretch” goal. The idea was to create the “structure” required for the pod (Slack channel, project readme) and find the minimum number of people. I didn’t get as much response as I’d hoped, but there was enough to get things started. Thanks to the APAC team members who responded, and especially Justin Farmiloe who agreed to be the first lead.
On to the “meatier” pieces!
90% of the 50 identified organizations with verified domain
We introduced the ability for group owners to disable 2FA for their users quite some time ago. However, due to the way users are marked as belonging to the group (an “Enterprise user”), this option was not available for many existing users. We’ve been waiting for auto-claiming of enterprise users, which allows for both new and existing users to be marked as users of the organization. For this feature to work, organizations have to verify their domain, which matches it against a user’s primary email address.
Therefore, to significantly reduce the number of 2FA tickets Support receives, we need the organizations that submit the most 2FA tickets to verify their domain so they can self-serve. Attempting to decrease these tickets has been something we’ve iterated on for a long time, because they’re expensive to do with the number of security guardrails we have in place.
The 50 organizations are mostly top 2FA ticket submitters, with the inclusion of those with the large organization workflow. The large org workflow was designed to improve the experience, and what better way to further improve the experience than to let people do it themselves?
We did not reach the rather ambitious goal of 90%, but we got to 45% with at least 3 adding a verified domain during the quarter (many of them added it when we sent out the notification emails earlier in the year).
Next to this KR, I was also handling Support readiness for the rollout of changes.
Hopefully, once everything is in place, we should see a significant decrease in 2FA tickets.
Thanks to everyone involved, especially the Product and Development teams for prioritizing and implementing the features, and the Customer Success Managers who worked with their customers to verify their domain.
Review Development Request for Help issues and help SEs get help
We have a process for Support Engineers to request help from Development. While we’re free to ask questions in Slack channels, with tickets we’re working on, often there is too much information and follow-up required for these to be in Slack.
Earlier this year, our CTO and Support Senior Leadership encouraged us to open a request for help issue earlier in the ticket cycle, since one of the company’s objectives this year is to make it easier for customers to work with GitLab. However, many Support Engineers were still reluctant to open a request for help issue, and even more so earlier in the ticket. Aside from the perspective that Development engineers are busy and they didn’t want to add to their workload, many Support Engineers had had varying levels of success in getting responses on the issues.
My KR was to review a bunch of the issues and see what improved guidance we could provide to Support Engineers on how to progress and “escalate” an issue as needed.
I was actually surprised to learn that numerous Support team members (both Engineers and Managers) weren’t aware of the best practices I ended up adding to the guidance on how best to get responses, and to “escalate”. The process certainly made me aware that I’ve gotten used to communicating with Engineering and Product team members a particular way based on how the majority of them use GitLab (especially with notifications), but obviously, not everyone works with team members in the relevant departments/divisions on a regular basis.
In particular, mentioning (or pinging) the engineer in every comment that needs their attention is not something most Support Engineers seem to do. Just this one small change should make a significant difference to responsiveness.
Thanks to everyone who provided issues, feedback, and reviews. Thanks to Cleveland as well for implementing auto-closing of stale issues.
Helping others outside of OKRs
I’ve continued to pick up issues and make merge requests that crop up. I’ve mentioned before that I try to get other Support Engineers to do most of these to get them experienced in leading and completing these.
Sometimes though, someone will directly ask me or I may have an idea in mind that may not coalesce until I start writing and editing. For example, as a follow up to one of his skip level meetings, my director asked me to open an issue on How to reach out to CSMs. I had some idea of what I wanted to include, but not exactly, and appreciated people’s comments, which provided additional content to what we added.
Mentoring and coaching are things I continue to do, including being a mentor in the mentorship program. In terms of helping to grow the team though, one of the things I’ve been doing more of is reviewing promotion documents, both for those looking to be promoted to Senior, and to Staff level. My involvement varies from simple proofreading to taking on an editor’s role. Most commonly, I help with two things:
- Identify examples that fit better in other sections (such as “Results” vs. “Collaboration”).
- Help cut down on the amount of content and choosing what to keep, since we have a strict page limit.
Outside of Support, I recently wrapped up my second internship for learning with the Chief of Staff to CEO Team on OKRs as well.
Early hacktoberfest
In order to help our team and our customers, a significant part of what a Staff Support Engineer does is submit and review merge requests (MRs). Since I knew October was going to be really busy for me, I decided to set a goal of at least 1 MR per week in September instead. To make it a little easier, they didn’t need to be difficult ones (though many turned out to be more work than I initially thought it would be).
While I asked others to join me, sadly, I didn’t get any takers. That didn’t stop me from trying anyway!
- Simple UI text change which included spec tests: Clarify users have to sign in with primary email, because a lot of people were trying to sign in with a secondary email.
- Adding a column to a display table (which touched a lot more files than I would’ve thought was necessary): Add SCIM identity active info to admin, primarily for the Support team so they don’t need to look it up via the API.
- My first JavaScript MR (which I had to refactor twice): Add Provider ID field to add new/edit Group SAML identity in Admin UI, because otherwise you had to use the Rails console, which admins don’t necessarily have.
- Simple UI text change (in Vue, rather than Rails haml file): Add period for consistency, which was prompted by an internal discussion.
- Rails haml view addition (for Enterprise Edition only): Add Enterprise group attributes to Admin User details, again so we didn’t have to look it up via the API.
- Simple UI text change (in rb/spec): Make error message clearer, requested by my director and prompted by a review of a bug fix for a customer.
In the end, I managed to beat my goal of 1 MR per week! I’m not sure any of it was my best work, but that wasn’t the point.
While half of them were simple UI text changes, it was great to realize I do think of them as simple now. I don’t hesitate to make this sort of MR anymore, and it doesn’t take me a lot of time. Now, I’ll even readily do them regardless of what type of file the string is in: haml, rb, js, vue.
Product prioritization and impact analysis
I’ve mentioned before that I work with product to prioritize issues that Support sees a lot. In recent months, there are a couple of long standing ones that we closed:
- Allow password reset emails to be sent to a verified secondary email, which we mentioned in over 690 tickets over the years (and I’m certain there were many we didn’t mention it in).
- Auto delete unconfirmed users, which got mentioned in over 50 tickets. We used to constantly get tickets where someone registered with the wrong email and wanted to fix it, but you can’t login to change anything unless you confirm the account first. This way, people can wait a couple of days to re-register. When first enabled, the system deleted over 320,000 accounts.
- New Enterprise User rollout: 20 issues with a total of 40 weight including an updated system definition, auto-claim of new and existing users (was only new users before), group domain verification, and updated features to use the new attributes. There are so many issues involved, it’s hard to know how many related tickets there were, but it’s over 300. Within the first week of turning the feature on, the system claimed over 175,000 users.
We’re expecting a significant drop in tickets, especially 2FA tickets, with this last set of features. Unfortunately, we won’t really see the impact on the number of new tickets so soon, but we did get numbers on tickets mentioning it.
Support Driven Expo and Leadership Summit
I was excited to be presenting at Support Driven Expo again this year. It was also great to see and catch up with some people from previous years, and meet new people as well. I got to meet and hang out with another Support Engineer, whom I’d never met in person before, as well. A little sad that it’s very unlikely I’ll be attending next year.
I’ll be attending Support Driven Leadership Summit this month where I’ll be presenting about Chief of Staff and how a similar role might fit in Support. As usual, blog post with a copy of the slides and script to come.
Leaving Support
I mentioned at the very beginning that I’m posting this now because I’m leaving the Support team.
I joined almost 5.5 years ago thanks to Trevor Knudsen, the recruiter at the time, mentioning that Support also had the Support Agent role, which we agreed I was better suited for; and to the interviewing team, especially Lyle Kozloff (the hiring manager) for hiring me despite my lack of experience in “support” positions. The Agent role was a less technical hire than Engineer. (Though we later discovered the tickets were not necessarily so. While not the only reason, the level of technical knowledge ramp-up is one of the reasons why Tristan Williams and I are the only ones left from the first year of Agent hires.)
Since then, I’ve been promoted 4 times, the first time under 8 months from my start date: Support Agent → Senior Support Agent → Support Engineer → Senior Support Engineer → Staff Support Engineer. While I’ve rarely received discretionary bonuses, I’ve been told that I’ve been considered one of the top team members in the Support team year over year during performance reviews.
Honestly, I’m still a bit surprised. I was baffled the first time my manager mentioned seriously working on my promotion document. In so many other places I’ve worked at, I’ve been told that there was no way I could advance unless I stopped pushing for change, became less direct/straightforward, and less opinionated. Rather ironically, I’ve done the opposite while at GitLab (though I believe it’s generally tempered as needed).
There are so many people that have had an influence in my growth these past few years, mostly within Support, but many outside of the department as well. There are too many to list here (and many of them can be found in my last letter of thanks), but I do have to thank all the managers I’ve had for everything they’ve done for/with me, and especially for giving me both guidance and room to grow: Lyle Kozloff, Ronnie Alfraro, and Lee Matos. I’ve told many that it’s that balance of stepping in when they need or asked to, and giving autonomy with trust in being a good manager-of-one, which has allowed me to go as far as I have.
It’s been an amazing journey being part of an awesome department. And, I can with confidence say it’s an awesome team since I’ve paired or had a coffee chat with every single team member in Support! (Wasn’t someone supposed to make a shirt as a reward? lol) There’s still a number of Support team members who started before me: 5 APAC, 6 AMER, 1 EMEA; so a total of 12.
In my last reflection post, I listed the highlights at 5 years with many of them being Support specific. The only thing I’ll add is remembering how welcoming the team has always been: from being welcomed and introduced in meetings during my first week, to Cindy making sure I was in the picture with other Support team members during our Cape Town excursion, and Andrew telling me he’d been wanting to meet me (when I didn’t even know most of the APAC team members’ names at that point), to Emily and the other APAC Maple SGG members inviting me to join the guess-who’s-desk-this-is team building activity, and so many other things in between and since; and for “having my back” whenever I needed others to take over.
I’ll definitely miss being a part of Support, Engineering, and being a counterpart for Technical Writing, UX, and the Authentication group. I was touched by all the “thank you” messages I received on Slack.
Moving on
I wrote last time that I can’t imagine working anywhere else, so it’s not as if I’m leaving GitLab.
I hadn’t intended to leave Support when I still feel like we’re working out what a Staff Support Engineer really looks like. However, the opportunity presented itself in the form of a job posting, and I applied. After a few interviews and some waiting while some things were being sorted out, I got the offer!
So, I’m moving on from Support to be the newest addition in the Chief of Staff to CEO Team as a “Staff, Strategy and Operations”.
With having just wrapped up my second internship for learning with the team, I don’t think anyone was surprised.
While I was constantly learning in Support, I feel like the rate at which I did had slowed, in part because only senior leadership is “above” Staff. So, I think the move is a great growth opportunity since almost everyone else on the team is a higher level than me (most of them are Director level), and I’ll be able to learn a lot from them. I’ve also just been interested in what the team does and the level of impact they have. This type of role is a great fit for my skills and experiences as well.
I’m very excited to join the team and that I’m able to start contributing right away since I don’t need to onboard to GitLab.
Look forward to the next reflection post!
Thank you
Thanks for making it all the way to the end!
