I recently organized an AMA on Being and Becoming a Staff Support Engineer. This was meant to be similar to last year’s Being/Becoming a Senior Support Engineer. Normally, I would have actually waited longer to do it, since I only got promoted in February and I feel like I haven’t been working at the Staff level very long. However, at the end of May, our other Staff Support Engineer, Will Chandler was transferring to the development team. So, I decided before he transferred would be a good time to have the AMA. Additionally, I invited Drew Blessing, our first Staff Support Engineer (who had transferred to development a couple years ago) to also join the group of people answering questions.
This is not just a summary of the answers from that AMA session though. I’ve tried to put the answers and thoughts together with the previous video that I recorded with Lyle Kozloff while I was still working on becoming Staff, and some additional insights.
Brief context
Similar to the Senior level, we have guidance and resources on getting promoted to a Staff Support Engineer, but it’s not the same as asking someone who has gone through the process.
Not becoming Staff
I want to start with the fact that much like you don’t have to move to Senior (from Intermediate), you don’t have to move up past Senior either.
Part of moving up means different responsibilities, and focus. Some may not want to move up, and there’s no pressure to keep moving up.
That’s one of the things about GitLab Support – you’re not pigeonholed. Everyone can contribute, as long as what you work on adds value to our team or customers you have a choice about what you work on. -Will Chandler
Evolving promotion process
Every time we’ve promoted an IC to Staff Support Engineer, the promotion document template and the process they followed has changed. We didn’t have the competencies when we got our first Staff Support Engineer, and we didn’t have the same level of emphasis on highlighting a company need that the IC is fulfilling with the second one.
Currently, I would say one of the first things to do once you’re seriously considering becoming Staff is to talk to your manager’s manager about what company need you might fulfill.
Staff’s based on organizational need and on merit. So you can have lots of merit, but if there’s no need, you may never be promoted to Staff. […] If you wanted to be a manager, you could have all of the manager skills, [… and] experience, but if there’s nobody to manage, then you won’t be hired as a manager. -Lyle Kozloff
This quarter, we have a new job framework and promotion template, so it’s changed again in terms of exactly what a promotion document will look like.
Identifying possible gaps
Unlike the Senior Support Engineer job description, the Staff Support Engineer job description provides a very general statement and some examples rather than a specific list of additional responsibilities.
This lack of “a list” makes it more difficult to identify possible gaps or pieces an individual contributor (IC) might be missing to get promoted to the Staff level. You need to instead rely on reviewing the leadership and technical competencies, the job framework, and performance review worksheet to evaluate whether you’re working at the Staff level.
There’s going to be a set of requirements, but the way in which you fulfill them is not going to be more prescriptive than it was at Senior; rather I think it will be less, because influence takes a lot of different forms. -Lyle
Difference between Senior and Staff
The difference between someone working at each level (intermediate, senior, and staff) can be looked at various ways, including:
| Intermediate | Senior | Staff | |
|---|---|---|---|
| Leverage | – | levers | lever’s levers |
| Expertise | learn | be an expert | level up the team |
| Time outlook | day and week | quarter | beyond |
| Focus | self | team | team and beyond |
| Shapes | customer experience | team | environment in which support is done |
Typically, for an IC, you consider a promotion when you’re already working towards the next level.
It’s not a dramatic change. You’re already building up to Staff when you get the promotion. -Drew Blessing
So you’re gradually shifting the focus to more impactful, strategic level, cross-team work to achieve team and company goals.
Becoming Staff
To start, you should be performing (or exceeding) as a Senior Support Engineer, building out the team, helping intermediates, etc.
If you’re doing those things, then you’re probably going to be encountering more systemic problems or larger problems within GitLab, and starting to build relationships with other engineering teams. […] that’s where you find a problem area where you can make an impact, or the things that interest you also meet the needs of support, and […] you get results, you deliver. -Lyle
In terms of skills, we recommend extensive troubleshooting skills, understanding and building tools to better understand problems, knowing the resources available within and from the product like backtraces and logs, and knowing the resources available to help you, including who to ask.
For some folks [promotion to Staff] could come quite quickly, because they’ve spent the time on relationships, […] time looking at large problems, and they’ve gotten results. For others, they may just require more coaching, they may not encounter the problems naturally […], and they may not get the exposure to problems that would boost them out of support… -Lyle
It’s generally natural to develop expertise in a couple of areas by working on tickets and having interest in certain topics. If you want to focus more on one specific area, you can become a Support Stable Counterpart. The more you work across teams, the more you’ll work in-depth with engineers in other teams, which may include development, security, and infrastructure.
At some point, you become an:
expert not defined by the support team, but [as] defined by the engineering team that you’re working with. -Lyle
As part of developing your expertise, it’s also about expanding and developing your influence, while looking at how things can be improved for Support and our users.
Influence is never built overnight […] It takes consistent action over time. It’s the same as building trust. [… It’s about] expanding your influence beyond support. It’s […] understanding the problems, and seeing the things that are affecting support, and are holding us back from resolving customer problems more quickly, holding the team back either through tickets being generated, or not handling tickets efficiently, seeing those opportunities and going out into the world to make those things better. […] It’s really all about changing, augmenting, and improving the environment where support happens. -Lyle
I think it’s hard to provide really concrete general advice to someone trying to become a Staff Support Engineer, because it’s going to look different for each individual. What an IC works on in order to “improve the environment support happens” can take so many different directions.
At its base, even the performance review worksheet (at least in its current draft state) reflects the job description of “Senior level plus more”. There’s a clear focus on improving how the team works, improving the team’s ability to answer tickets effectively and efficiently, collaborating cross-team, improving the user experience through technical competencies, and so on. But again, exactly what to work on will be different depending on an IC’s interests and areas of expertise. Being a manager of one is a huge part of working at the Staff level, especially identifying and prioritizing the “right” things.
Being a Staff Support Engineer
A Staff Support Engineer has the
influence of a manager with a focus on technical problems. -Lyle
When working as a Staff, we spend a lot of time helping others; sometimes directly, such as pairing, answering questions; but often indirectly, working on (internal) tooling, documentation, training, and code contributions.
Even at the Staff level though, the product is too big to know everything, so it’s about knowing how to get others unstuck and moving forward, not always knowing the answers.
[You want to be] T-shaped. You have to be broad, in general, but you’re also specializing at the same time. Submitting MRs to resolve customer problems often requires specialization. With being a resource to the Support team, breadth of knowledge is more important. -Will
Support has a tough job since the GitLab product is so broad and expansive. Staff is definitely T-Shaped. The expectation is you’ll be part specialist and part generalist. -Drew
While we tend to take less tickets, we’re further challenged on managing our time and priorities, because we get pulled in a lot of different directions by a lot of different people.
We also struggle more with measuring our performance and accomplishments.
Additional projects and tooling may be used widely by the team but it’d difficult to understand exactly how big of an impact it makes. -Drew
Not only do we spread our contributions (tickets, issues, merge requests, answering questions in Slack), it’s more difficult to see and measure the results of our efforts because a lot of what we do is “indirect”.
I’m hoping to work with my manager to better define what and how we measure performance for a Staff Support Engineer as I spend more time in the role.
Moving on from Staff Support Engineer
Drew and Will both moved to a development position and so some wondered if it’s a natural transition. From Support though, we’ve had people move to a lot of different teams including infrastructure, customer success, and product management.
In a way, moving to development can be natural since Support Engineers tend to become experts in at least one specific area and become more familiar with that part of the product including the codebase, but
It mostly depends on your own interests. -Drew
Honestly, I’m not a great programmer, so I plan to stay in Support. If I ever changed team it’d probably be Technical Writing, Product Management, or possibly Chief of Staff (team).
I also considered SRE, I like the focus on performance and troubleshooting production problems. […] I decided I’d prefer to work in Dev for Gitaly slightly more than SRE. -Will
I briefly mentioned too during the AMA that for the majority of team members, their current position is likely not where they retire. It’s important to consider your career interests when looking at what you want to work on.
Thanks!
Thanks to everyone who participated in the discussions, especially the other (former) Staff Support Engineers, Will Chandler and Drew Blessing, and Lyle Kozloff for his senior manager perspective.
