This reflection is a direct continuation of part 1 of my time at GitLab so far. If you haven’t, please read the first part before beginning this one.
Becoming an Engineer (18 months)
The more time I spent working in Support, the more I realized that the job was much more technical than I originally thought it to be.
For GitLab.com (SaaS product), we’re the administrators of the instance, so we do get a lot of procedural questions around people’s accounts, and things like dormant namespace requests.
At the same time, the more we integrated and promoted some of our features, the more questions we got on them. Some areas that I’m still very much a beginner with but we often help with are Kubernetes and package registries (especially maven and gradle). On the flip side, I’ve become an expert in CI, API, project imports, and SAML.
The hardest problems are the ones that potentially involve all parts of the setup (Docker, Kubernetes, certificates, etc.) because it’s hard to pin down the problem. What’s more, some of the issues we have, we can’t use the “typical” workaround, because it would involve changing the configuration of the GitLab instance, which we can’t do for GitLab.com.
When I started the job, I knew it’d be technical. It was supporting GitLab after all. However, as time went on, questions started getting more complex. More than once, I’ve asked the managers to dig into why we weren’t always meeting our performance goals. The most interesting part was we were supposedly not getting more customer tickets. And yet, others and I felt like we were spending more time on tickets than ever before. Our theory is the complexity of tickets, though that’s hard to measure.
Honestly, if you read the “Support Agent” job description, it sounds a lot of like any other generic Support job, but unlike most other larger organizations, we don’t do tiered support. Meaning, everyone works on all tickets. If you can’t take a ticket further, it is your responsibility to find someone who is willing to take it on. We encourage team members to find someone to work on it together, to learn how to troubleshoot or resolve similar issues in the future, but there’s no levels of support such that if it’s too technical for you, you’d push it up to the next tier.
Even as an “agent”, I was contributing code to GitLab projects.
In recognition of all this, my manager worked hard to get approval and do all the work necessary to deprecate our position. This meant converting all our existing “Support Agents” to “Support Engineers” and that we would no longer hire for the agent role (which was actually really good, because we had too many applications who weren’t technical enough).
That whole process was even more amazing to me than my promotion. Having come from working in institutions with unions, I was skeptical that it could happen, let alone in a matter of months.
In December 2019, all the Support Agents officially became Support Engineers.
Becoming Senior Again (2 years)
My one regret with the move to engineer was that I lost the “Senior” part of my title. The way it was mapped over was that a senior agent became an intermediate engineer, so my title became simply “Support Engineer”.
It was a badge of honour, a recognition of the level of work, an indicator to others that they can rely on me to help, and more.
Nevertheless, my job itself didn’t really change. I kept doing what I was doing before and continued to try to improve myself, the team, and the company in whatever ways I could.
While I became an expert in some topics, I wanted to make sure that the knowledge I gained wasn’t “bottled up”, but that everyone (including our users) could benefit from it. For the most part, I update the docs but sometimes a walkthrough is more useful so I’ll do a demo video. We have a joint OKR (Objective and Key Result) with docs this quarter, so based on everything I knew I put in a review merge request which in some ways probably went a little beyond our OKR (since we weren’t supposed to be creating new pages).
At the team level, I started getting more involved with the hiring process again (which was somewhat paused for me in making the transition to engineer).
Jerome Uy, another team member, and I also took on revising the support portal (again). This time, we had a manager’s backing to help purchase a theme we could edit for our own use (thanks Tom Atkins). Jerome did most of the coding work while I helped to compile the content we would use and the requirements (like changing the search bar to search our docs instead of the ZenDesk articles). In the end, we had a lot of content and didn’t want to overload the change, so we kept the content mostly the same as a first iteration.
Last year, when I started to feel like I didn’t know everyone on the team anymore, I started up a pairing challenge to make a conscious effort to get to know everyone on the team, and encourage everyone else to do the same by making a template. Admittedly, even waking up early or staying late, I wouldn’t have completed it without having spent 2 weeks in Europe back in January. Still, it was a great accomplishment that I fully completed earlier this year, and I’m still keeping it up with new support team members.
At the company level, sometimes I wonder how much of an impact I have, but I do what I can. I was honoured to be part of the women of GitLab fireside chat at this year’s GitLab Contribute.
What’s a Senior?
Shortly after the whole “agent” to “engineer” transition completed, my manager suggested we write up and submit a promotion document to get me promoted to Senior again. I was super excited partly because we often see members with code-oriented contributions promoted and I didn’t think I was “qualified” to become one (thank imposter syndrome for that).
In our discussions, he re-iterated that he considered what I do to be what a “senior” does. While working on my first promotion, we discussed how a senior is primarily distinguished from an intermediate by their focus.
A junior or intermediate team member focuses on their work and getting good at it. On a side note, this isn’t a bad thing, and team members can be very successful at that level.
A senior focuses on the team. In many ways, they do a lot of the same work. However, if answering tickets for example, instead of just answering a ticket, a senior will consider what they can do to radiate that knowledge they gained. Generally, the default is a docs update, but if it’s not appropriate for a docs update or issue, they might still share it during a team meeting.
Generally, a senior will also think about how they can improve the team’s work, which can be manifested in many different ways. For non-technical contributions, it might involve helping to hire and train team members, improve or create processes, help with strategic work (such as a quarterly OKR (Objective and Key Result), or lead projects.
Even technical contributions, aside from helping improve the GitLab products, might be to improve the team efficacy. We’ve had team members build ZenDesk apps, browser plugins, and information gathering tools for troubleshooting.
When you look over the engineering career development page, this starts to make even more sense. Once at the Senior level, you typically start thinking about whether you want to become “Staff” or a manager (not that moving up is required), but to get to the Senior level, you could be on the way to one or the other.
In May, I became a Senior again, this time as a Senior Support Engineer.
During this time, my then manager was making the transition to Senior Manager, and I was going to be moved over to a new manager.
Honestly, this news was met with some trepidation. I had had the same manager since I started at GitLab; and honestly, he was the best manager I had ever had.
To be clear, this is not to say my previous managers were bad. Instead, Lyle has had a huge impact on my growth at GitLab. Without his support and advice, I wouldn’t have as much of a positive impact as I do today. Though not as directly, he continues to support and advise many of his previous direct reports, including myself, as our Senior Manager.
Thankfully, Lyle put a lot of thought into the decision into who was moving over to which new manager.
As part of the move, he was also moving any of the operation work that he did to my new manager. To give the new manager time to learn and understand how all that worked, only 4 of us moved to our new manager.
Not only that, my one teammate in Americas West working on GitLab.com was moving with me so that we would both continue to report to the same manager. Keeping us together makes sense because we were both part of the early batch of GitLab.com hires (2 of the 5 left) and have a lot of “institutional knowledge”. Having the same manager meant it was easier to coordinate some of our efforts. Also, if we both raised the same concerns, our manager would know.
I’m not sure that we “immediately hit it off”, but we certainly got along, and the more weeks that went by, the more I began to appreciate Lyle’s decision.
Ronnie was open and friendly from the beginning, and the more we bonded over many shared stories and random food stuff (like furikake and bánh mì, in which I bought the book he recommended for Pomax), the more I became willing to bring up the “hard stuff”.
When my promotion document got a bit “stuck”, he took it upon himself to meet with me to finish it up and get it pushed through.
When I was stressing out about work, in addition to helping me sort out my priorities, he set aside time during our one-on-one just to make sure I booked a day off.
You can see that in recent months, I have empty contribution days where I obviously took a day off, and that the days I am working, there are more contributions than before; taking days off so that I can be more effective when I am working.
The longer I’m at GitLab, the more I get pinged on things and the more responsibilities I have. In the past, I’ve always done a good job of prioritizing, but I’ve never been in Support where there’s a constant balance between tickets and the rest of the work that needs to get done. Having a manager who seems to know the right things to say and to help you tone down the stress level is invaluable.
The Support Team
I talk a lot about the Support team and the way we work in my series on the GitLab values and culture, but that focuses on how we do our work.
Here, I have to express how working with the Support team we have at GitLab is one of the big reasons that continuously makes me want to stay.
Every team member is smart, dedicated, helpful, and friendly. Some team members seem to tend to keep to themselves more, but if you do a pairing session with them, it’s obvious that they’re simply “quieter” than others.
Most engineering teams are a dozen members or less, so Support is by far the largest engineer team with over 80 members, and one of the largest teams at GitLab.
While there have certainly been some “growing pains”, most of them have been fairly typical. These include making sure everyone is aware of changes, and that we create or update processes that are scalable. Communication and change management at scale are not new problems, so were fairly expected.
One of the things I love is that we have this sense of belonging and camaraderie in Support of being “one team”. Despite the fact that we currently have two groups of people working on the two products, and we’re divided up by regions, when asked about splitting up for team dinner at Contribute, the general consensus was to have everyone together. We frequently discuss making sure we’re not silo’ed by region.
We are one team.
We share our shortcomings and our successes together. While we’re not there yet, we’re also moving towards working as a single team even in tickets. Nevertheless, we often exceed our performance goals, and consistently receive not only a high rate of positive satisfaction ratings, but also a high rate of users completing them. We’ve received praises from our executive team.
In recognition of our awesome work, we’ve also received a pizza party or two.
A lot of what I got done and so much of what I’ve learnt was thanks to help from others: their feedback, knowledge, trust, and support, plus allowing me to not step on their toes.
At 2 years, it’s currently hard to imagine working anywhere else.
Thank you GitLab and the Support team, with special thanks to my awesome managers. Here’s to more amazing things in year 3!
Thanks for reading!
If you made it all the way to end, just want to say, thanks for reading! Have a red panda as a reward =D
I’m excited to keep exploring how I can continue to make a positive impact at GitLab.