Why It’s So Hard to Become a Staff Engineer

Bridging the Senior SWE to Staff Divide: Part 1

While all promotions have challenges, from my experience and from watching and working with others, one of the most challenging promotions is moving from a Senior Software Engineer to a Staff Software Engineer. Advancing from entry-level to Senior SWE focuses primarily on becoming more independent and being able to solve problems with more ambiguity. The focus is on building technical and project management skills while also building the confidence to tackle more complex challenges — both those you’ve seen before and those totally unlike any others. The specifics will vary depending on the exact role and the company, but the rubrics for these levels are typically very well-defined.

Staff, however, marks the first time when the job itself starts to shift. The job continues to change as you move up the ladder, but this is the first, and may be the largest, shift. Instead of doing more and better like you’ve done for each promotion up to this point, you suddenly need to do something different, which can be a challenging mental shift.

This job shift is also true if you move into management. However, it’s typically apparent what a manager’s responsibility is. With Staff, however, the job description itself becomes vaguer. As StaffEng discusses, there are roughly four archetypes. Realistically, however, there’s a lot of grey area, and to make it worse, all of this varies by company and team need, not to mention individual strength and interest. Instead of just picking up management responsibilities, you need to choose which type of Staff engineer you want to be. It’s also essential to pick an archetype your company needs and will recognize. In addition to doing a new job, it’s not usually apparent what that job even is.

For the management side, there’s often a well-defined promotion process. First, you become a TLM (tech lead or tech lead manager), managing a project. Next, you start meeting with the team members in 1:1s. Then, you slowly take over management responsibilities, such as giving feedback, and you continue until you get promoted. Even if there isn’t a formal process, there will be a clear progression and a distinct set of responsibilities. For Staff Engineers, however, there is rarely a well-defined promotion process — both because there are multiple types and because many organizations still need to wrap their heads around the IC track fully. Instead of just taking over various tasks from your manager, you need to figure out what those responsibilities even are and attempt to find opportunities to take them on. Instead of having someone hand over parts of their job, you’re often carving out a new position entirely.

In theory, your manager should help you identify opportunities to show your abilities. However, it’s distinctly possible that your manager has never worked closely with a staff engineer and may struggle to help. While every manager is a manager and has worked with managers (making it easier for them to understand that job), the same isn’t true of senior ICs, especially not of the archetype you’ve chosen. Even if you and your manager agree that you are trying to reach Staff, the sad reality is that they may also struggle to define what that means and how to get you there.

So far, we’ve assumed that your manager is actively trying to help you reach the next level. However, another common problem is a mismatch in expectations between the engineer and their manager. From the manager’s perspective, the engineer may appear to be performing at or even below their current level because they’re not contributing as much code or they’re not as involved with the team itself as other Senior Engineers. In many cases, the manager is unaware of or might disregard at least some cross-team involvement and contributions. Because a Staff Engineer should be working beyond their immediate team, it makes sense that they would be contributing less at the team level. To make matters worse, some glue work (appropriately coined by Tanya Reilly) that is often considered a part of leadership can also be nearly invisible at lower levels. Unfortunately, if your manager isn’t seeing everything you’re doing, it can be challenging to distinguish cross-team and glue work from someone who’s slacking off. Unlike management tasks that you directly take over from your manager, all of this is much less visible. Unless you specifically tell your manager, they have no way of knowing what you’re working on and, even if they do, may have no insight into why it’s impactful or valuable.

Next is the problem of navigating your organization’s processes and politics. How do decisions get made? Whose opinions matter? What persuades people? As a more junior engineer, you likely have limited exposure to all of this. If you move into management, it’s often the case that there are explicit processes and meetings already in place which help give you access and insight into all of this. On the IC track, however, things are typically less explicit. Understanding your organization’s inner workings can be necessary for the promotion itself — who needs to know what you’ve been working on and how important is that work? But also, a Staff engineer is typically expected to work beyond the scope of a single team and rarely has actual authority. So how do you get those teams to work on your top priorities? How is work prioritized at your company? Who do you need to influence, and how do you convince them? Without a clear understanding of how best to accomplish these things at your company, you could be doing a ton of work with very little actual influence.

The final challenge is that there’s often an expectation that a Staff engineer can leverage past experiences to up-level a team. Unfortunately, it’s often the case that you only gain experience with time and, well, experiences. A team rarely faces the same challenge twice, and even if they do, you won’t be able to uniquely take advantage of your experience. To fully leverage your experiences, you need to work in different groups throughout your career, if not at various companies. I managed to move from a Software Engineer role to Senior Staff at a single company, so switching companies is by no means required, but moving to different and new problems often is.

If you combine all of these, you can see that it’s hard to know what the role is, it’s hard to know how to get there, you may not have a lot of help, and your progress can look like a regression if you’re not careful. It’s no wonder that it’s so challenging to move into a Staff role.