Ever since becoming a Senior Support team member at GitLab, I’ve had various conversations about becoming and being a Senior level team member; even more so after I became a Senior Support Engineer (SSE). A couple of recent conversations made me realize that a lot of team members have questions and we should have a way to share the answers, so I organized “Ask Us Anything” (AUA) sessions on Being and Becoming a Senior Support Engineer.
I’ve written a bit about this topic already if you check out my previous blog posts, especially my year 1 and 2 reflections, but it’s been some time since I wrote those posts, and the posts were focused on my overall time at GitLab. We also have a bunch of resources on getting promoted (including a dedicated handbook page for Support), but it’s not quite the same as knowing “what it’s really like”. In this post, I wanted to gather and summarize the thoughts and insights from the sessions and my own answers to the questions we got.
There were a few topics or themes from the sessions, so I’ve grouped the thoughts rather than separating answers by individual question.
Note: I cite specific individuals when it was 1 or 2, but not where there were a significant number of people who said similar things.
Brief background
For those unfamiliar with my path to Senior-level, I had a unique one. A brief timeline:
- Feb 2019: Promoted to Senior Support Agent
- Jan 2020: Moved to Support Engineer
- May 2020: Promoted to Senior Support Engineer
So I ended up being promoted to Senior-level twice though the second time was almost more of a formality than something I really had to work at.
Why become a SSE
For those who were not hired as a SSE, it seems common that those who become a SSE naturally start working at that level, focusing on the success of the team and team-level initiatives as opposed to their own individual work. These individual contributors (ICs) tend to enjoy helping others as well. At some point, their manager (and others) will comment that they’re working at the Senior level and should actively work on their promotion document.
You don’t have to become a SSE if you don’t want to, and Ronald reminds us that it’s possible to move back being Intermediate level if the Senior level turns out to not be a good fit.
If you’re interested in hearing about career progression, consider reading article on how moving between manager and engineer is not a promotion/demotion (via keybits aka TomA), and this Critical Career Path Conversation video that Ronald mentions:
Being ready for Senior level
While there is a certain mindset, it really is being more concerned about the team than yourself as an individual, and having a “bigger picture” (Ronald). Ronald talks about there being two “tracks” (technical and workflow), but I would disagree that there are tracks, and instead say that different people have different strengths or areas they want to focus on, so you’ll see a range of the type of work emphasized, but all SSEs do both technical and non-technical work and are expected to work at the Senior-level regardless.
Those who haven’t seen it may find this section of the “Becoming a Staff Support Engineer” video useful since we discuss the difference between Intermediate, Senior, and Staff level:
As mentioned in the previous section, most of the time, you’re ready when you’re already working at the Senior level, and your manager confirms that for you. After that, the main thing is putting together your promotion document.
Getting the promotion document together
The promotion process as Katrin points out is probably one of the most “bureaucratic” at GitLab. A lot of people are used to going through an interview or having a short recommendation blurb written by their manager for approval. In comparison, we put together a multi-page (6 pages max) document providing blurbs and examples of how the IC is working at the Senior level for their particular position.
For those who don’t have access, the template is divided into sections where there’s typically a blurb to summarize with a short list (including links) of exemplars. The first set of sections reflects the SSE job description and following the general promotion template, the second set of sections reflects the GitLab values.
- Summary
- Mentor team members on new technologies and features
- Expert debugging skills
- Submit merge requests to resolve bugs
- Help hire and train
- Drive product enhancements and fixes
- Suggest and improvement improvements to workflows/process
- Contribute to complementary project(s)
- Collaboration
- Results
- Efficiency
- Diversity, Inclusion, and Belonging
- Iteration
- Transparency
Reactions vary towards the process, and some ICs needed more push than others. Personally, I track my work fairly regularly and consider putting together this kind of document time consuming, but relatively easy. Others I know have struggled with finding examples or tracking their work, and/or writing blurbs about themselves and how “amazing” they are.
To make it easier on yourself, track your work (Support team members can make a copy of the “Track Your Work” document or promotion template), which I recommend for performance reviews as well even for those not interested in promotion. Set aside time in your calendar (daily, weekly, or monthly) to add items to your doc. Katrin points out that it’s basically a “side project” to becoming a SSE.
Also, don’t get dejected if it doesn’t get approved the first time. Your manager and/or their managers provide feedback to help improve it such that it’s easily accepted by those who aren’t familiar with your work.
Level of technical knowledge
One of the big questions is “when is enough. enough?” Considering the size of the product and all the things that can get connected to it, “you can’t know everything”. A few of the SSEs (Greg, Anton, AlexS) mentioned you should have a good “foundational knowledge”, but it’s less about how much you know and more about knowing how to get to the next steps towards resolution (Lyle, me), whether that’s knowing who to ask, digging into the code, or something else.
Even the GitLab values page says it’s impossible to know everything (h/t Greg, Ben).
I recommend having an “expert” level of knowledge in a couple of areas, but remind everyone that expert means “above average”. In Support, when we’re not focused on a single product area, working on a single ticket that requires you to really dig into a topic could make you an “expert” by the end of it. So, don’t try to learn everything, and focus on a few areas to start (Adam via Alvin).
Imposter syndrome
The fear of not knowing enough often stems from imposter syndrome.
Imposter syndrome sucks – Anton
Lyle mentions how you’re looked up to more, and it can be scary to be more visible, especially if you end up in meetings with VP+, but many mention that it’s in our handbook that we don’t know everything (as mentioned in the previous section), that it’s okay to say “I don’t know.” Ben (in the video segment I link to in the previous section) mentions how it’s about working together, and I also talk about how we get better results by collaborating. “The whole is more than the sum of its parts” as they say.
Numerous SSEs also talked about being forward and learning focus. Over time, you’ll learn more, and that’s part of growing into the role of a SSE.
Based on the various discussions I’ve listened to in and outside of GitLab, it’s a common issue at every level of technical knowledge and organizational hierarchy, so if you’re feeling it, you’re not alone. Talk to your manager or peers, or consider learning about how to deal with it through reading, courses, or whatever works for you.
Working smarter not harder
It’s fairly typical that a higher level position means more responsibilities, but when you’re not moving to a management position and don’t have others to delegate work to, how do you handle having additional responsibilities with the same number of work hours?
Greg shared how he has struggled because he wants to do “all the things”. I’m often in that boat too, assigning things to myself whenever I create an issue. Over time, I started learning to leave things unassigned (unless one of the managers told me it needed to be prioritized) and I found time to work on it later.
Rather than trying to get more things done, it’s about being a better Manager of One. Sometimes, that necessitates asking your manager to help you prioritize based on their view of the team’s and company’s priorities, and that’s okay.
Numerous times, I’ve shared with others that SSEs aren’t meant to spend the same amount of time or necessarily work on Intermediate-level responsibilities the same way. For example, most SSEs take on less number of tickets (compared to when they were an Intermediate SE), spending more of their time solving complex or escalated tickets, and helping others with their tickets. This difference in how SSEs spend time on tickets is directly reflected in our performance review template by emphasizing tickets a little less and adding a line on helping others.
The main thing to keep in mind is that what you do adds value to the team (Ben, from the related question on work that’s visible).
A day in the life of
Each day is different, and each SSE’s day is different. Compared to before they were working at the Senior level, some SSEs said they spend more time on projects, helping others, helping with hiring, and doing things that will help the team like taking a solution to a ticket and generalizing it so that it helps the team and others.
While SSEs technically have more responsibilities, managers recognize that we don’t have more hours. I’ve often talked about how the added responsibilities shouldn’t mean that we have to do more, but that we have more opportunities to expand and grow, and decide where to put our time.
Working with others
A couple of questions revolved around whether our relationships changed, and whether we could “run faster” or “jump higher” after becoming a SSE. (Note: these were not in the recordings, but were in the pool of questions, so I asked for answers to be added to the doc asynchronously later.)
We talk about how you get promoted to SSE to make it official and recognize that you’re already working at the Senior level. So, it’s not really any different before and after you become a SSE.
It’s a natural progression that as you grow into the role with time, experience, and knowledge, that you have more impact and influence. That’s true at any level.
I would say it’s likely that on initial contact with someone who you don’t have an established relationship with that they may have different expectations of you if you have a designation in your job title.
Take away
While there are a bunch of key points, the one I’ll pull out as the take away is to enjoy the process.
I don’t know what he’s doing but he makes it really fun – Bo
In writing this blog post, I was attempting to help organize my own thoughts, so hopefully I didn’t misrepresent anything (any questions/concerns, please reach out). I recommend watching the AUA sessions to get everything in context.
As always, if you made it to the end, thanks for reading!
