How to Get That Staff Engineer Promotion

Bridging the Senior SWE to Staff Divide: Part 2

Published in

Code Like A Girl

6 min readDec 23, 2022

I often see the question asked about how to make the jump from Senior Engineer to Staff Engineer, which makes sense because this jump is really challenging. How do you actually do it?

Understand the Role and Have a Plan

The first and most important thing is fully understanding not just the role of Staff, but also the specific flavor of staff engineer you’re targeting. Read through StaffEng to understand the typical archetypes. Make sure your manager also understands those roles, then work with your manager and skip-level to understand which archetype best fits your strengths and interests and which archetype your organization most needs. Understanding what you’re trying to get to and having a shared understanding with your manager is the most crucial piece of the puzzle.

Say Yes to Opportunities

But only the right opportunities. A big part of becoming an excellent Staff+ Engineer is having a lot of experiences and being able to apply those to future problems. Many of the opportunities that have given me the most valuable experiences were situations where I was presented with an opportunity and said yes. Because you’re only one person, you can’t say yes to everything, so it becomes crucial to identify valuable opportunities. It will be different for everyone, but some of the experiences that helped me advance the most included the following:

Spending two years managing
Serving as a member of our REST API Committee
Switching to join other teams, including moving to one of the early teams replacing our application authorization logic with a new micro-service, and another committed to defining the architecture and approach for our entire split the monolith project.

The best opportunities allowed me to bring in existing knowledge while learning many new things. In several cases, I was initially concerned that I would be unable to contribute much and almost said no (that would have been a huge mistake!). In all cases, there were other people from whom I could learn a lot. Some of the best opportunities, such as the API committee and the architecture team, exposed me to many other engineering teams, increasing my influence and improving my understanding of what was happening org-wide.

Learn as Much as You Can

I’ve been able to apply experiences that I didn’t have directly as well. For example, a friend worked on an audit log project. I spent enough time talking with her about all of their issues that while I didn’t know all of the problems as well as I would have if I had done it, I did learn enough to know where the pitfalls would likely be. I could still apply what I learned from her to research the potentially tricky areas when I later helped build audit logs at my next company. Part of this is taking the time to be curious about other areas of engineering. Why are you adding an API Gateway? Why did it take that team a year to implement that feature which seemed like it should be easy (note that the answer is rarely that the team isn’t good)? Why couldn’t that technique we applied over there also apply over here? It can be scary to ask questions or admit that you don’t understand something, but asking questions is the key to learning.

Start to Shift Your Mindset

It can be easy to get so caught up in the what do they do part of the job that it can be easy to miss the how are they thinking or the why are they doing it pieces. I previously wrote about how I approached my role when I was a Senior Staff Engineer which gives some insight into the why and how. There are three things I want to highlight here.

The first is cultivating a sense of ownership and responsibility beyond your specific work or even your immediate team’s work. By this, I mean that whenever you find yourself thinking, ‘someone should be doing XYZ,’ you should no longer assume that someone else will look into it or that it’s someone else’s responsibility. It’s now your responsibility. You don’t actually have to do everything (you’re only one person), but it is your responsibility to triage if it’s worth doing and if so, make sure that it’s on someone’s backlog to do.

Secondly, think bigger. I mean both more broadly as well as longer term. How does your project affect other teams? Are there similar things that you’re all trying to do? Can you generalize your work to make it reusable by another team? What tradeoffs are you making between ease of building now vs. future maintainability? Would you be able to replace tools or modules easily? How do you avoid future maintenance and work? What are probable product enhancement requests? How do you make those easy to build (without completely sacrificing simplicity or maintainability)?

Finally, you’re a role model now. You no longer have the luxury of doing the easy thing or the thing you want to do, but you should always do whatever you want other people to do. To quote Tanya Reilly’s book The Staff Engineer’s Path,

“Most of all, you’ll be a role model. How you behave is how others will behave. You’ll be the voice of reason, the “adult in the room.” There will be times when you’ll think “This is a problem and someone should say something”…and realize with a sinking feeling that that someone is you. When you model the correct behavior, you’re showing your less experienced colleagues how to be a good engineer.”

Communication, Communication, Communication

The final piece is communication. As you start to work at higher levels, more and more of your job involves communication. Your job typically involves mentoring, which is communicating one-on-one or in a larger group. It also involves convincing others and gaining alignment, which is, again, communication. Finally, to even get the promotion in the first place, your manager and anyone else responsible for promoting you need to understand what you’ve been working on and why it’s impactful. Communication is an integral part of the Staff+ job, but it’s also often necessary to even get that job in the first place. Find which methods of communication you’re most comfortable with and most effective at, and start to do more. You’ve done something cool recently; what is it? Who knows? If you’re worried this is self-promotion, remember that you’re not just communicating so that people know what you’re doing. You’re also communicating so that they don’t make the same mistakes you did, so they learn from the research you already did so that you can avoid duplicate work across teams, and more.

If you’ve done all of these things and still struggle to make it to Staff, take a look at my blog about why bridging the gap is so hard in the first place to see if you can identify where exactly you’re struggling. Identifying the problem is the first step toward fixing it.