Getting the title where you are

The best advice I’ve heard is that often reaching Staff is a combination of luck, timing, and work. - Bert Fan

Most technology companies have a “career level,” which is intended to be the highest level that most folks achieve. Senior engineer is the career level at most companies. While you might get let go for not moving from entry-level engineer to mid-level engineer quickly enough, most companies have no expectation that you’ll ever go from Senior to Staff. Six years at mid-level? Ah, that’s a problem. Twenty years at Senior? Sure, that’s fine.

More than the expectation of progress going away, companies’ promotion systems will often impede your further progress once you attain the career level. Sometimes the folks who already have Staff engineer titles are protective of diluting their prestige. In other cases, organizations may be wary of having multiple Staff engineers on a single team due to team health or budgetary concerns. However, I think the strongest source of friction is that the nature of the job changes. A Staff engineer isn’t a better Senior engineer, but someone who’s moved into fulfilling one of the Staff archetypes.

Even after you’ve developed the prerequisite skills to become a Staff engineer, there will still be one last hurdle: getting your company to grant you the Staff title. For some, this process is a relative non-event, perhaps taking one or two cycles longer than anticipated but ultimately succeeding, and for others, it may not happen at all at their current company. About two-thirds of the Staff engineers I surveyed attained their title as a promotion at the company they were already working at, and the remaining third changed companies to attain the title.

If pursuing that sort of role is your goal, then take the promotion to your career level as an opportunity to reset your approach to navigating your career. From that point onward, there is no standard path to follow. The promotion and performance system will no longer be designed around attaining a timely promotion and may, at times, take on the feel of gatekeeping.

To go further, you will have to take more deliberate control of your progression, and this chapter shares the tools that have worked for folks who’ve made the progression ahead of you.

Finding your trail

If you’ve been relying on your manager to steer your career up to this point, the transition to a self-directed career can feel rather abrupt. There are many books about managing your software career, but most focus from your first job until you reach Senior engineer. Few focus on managing your career beyond the Senior title, which is where this chapter focuses:

• Your promotion packet is your foundational tool to demystify the Staff promotion, prioritize the right personal development to ensure you get there and activate your internal sponsors and network in support of your progression
• There is a widespread belief that moving into a Staff-plus role requires successfully completing a Staff project. This section discusses the reality that most Staff engineers do not have a Staff project but also describes how to approach one if you’re at a company that does require them
• A frequent complaint from engineers is that they’re not “in the room” where decisions happen, and they’re usually right: there is a room, and they’re not in it. What’s less frequently acknowledged is that you’re probably not in the room for a good reason. This section describes how to get into the room, and also how to stay there
• Finally, you won’t get promoted if your company’s leadership doesn’t know who you are. How do you become visible internally without hogging all the oxygen?

Apply these techniques consistently, and you’ll be on the way towards a Staff title, although even the best-laid plans falter if you’re conducting them at the wrong company.

Opportunity is unevenly distributed

One inconvenient reality you’ll encounter in pursuit of a Staff role is that opportunity at any given company is unevenly distributed. If your company leadership views infrastructure engineering as inherently “more complex” or “more leveraged” than product engineering, then opportunity will consolidate within infrastructure teams. If you work in an organization that emphasizes shipping features, then it will be easier to be rewarded for fixing an outage you cause than preventing future outages. Your work will be more visible if you work in your company’s headquarters than in a distributed office.

Many companies believe they have a vested interest in pretending opportunity is evenly distributed, even when it clearly isn’t. This makes it hard to have conviction these dynamics exist, but the trends become clear as you collect more data.

Once you recognize these challenges, you have to assess how fixable they are and where you want to prioritize your energy. It’s much simpler to align your approach with these unspoken currents rather than reroute the river creating them. If you choose to address the causes of inequality, start by finding a senior sponsor who supports the cause. You can only change a system with sponsorship from within.

Should you try management?

Most folks who reach Staff-plus roles do not spend time in engineering management, but some do. It’s easy to view this as a critical, life-changing decision, but that’s probably overthinking it a bit. If you want to give management a try, you should. Most companies understand that management isn’t the right role for everyone and will be glad to let you rotate back into an engineering role.

Those that try management gain a broader perspective that helps them even when they move back into a software engineering role. This was Dan Na’s experience,

I still enjoy both shipping code and running teams, and I think the ability to do both at a high level is critical for long-term engineering success. Charity Majors has a fantastic blog post on this topic that I recommend reading: “The Engineer/Manager Pendulum”. Charity argues that “manager career path vs engineering career path” is a false dichotomy, and taking time to alternate between both roles makes you better at both. This maps to my own experience. I’m a better manager because I know how terrible it is to be an IC on a poorly planned project, and I’m a better IC because I know how and when to sound an alarm when a project is going poorly.

Ritu Vincent shared a similar perspective,

I do pendulum a decent amount because I’m interested in so many things on both sides of the career ladder. I’m interested in growing people, I really like working with recruiting, I’m one of those engineers that actually enjoy interviewing, I like understanding how teams grow. But I also really like writing code, and after I spend some time managing, I want to get back into the code and hack around a little bit.

Some folks try management and end up hating it. Joy Ebertz didn’t care for engineering management much,

I actually managed for about a year and a half in the middle of my time at Box and found that I hated it (you can find more about that in my blog post on that topic). That said, I found that there is actually a lot of overlap between management and staff+ roles in most companies.

Even though Joy hated her management experience, she felt it might have helped her longer-term career,

It’s possible that if I hadn’t taken a meander through management, I would have gotten to Staff sooner. That said, I don’t regret doing it, and I learned a lot about how people think, how organizations are run, and how larger projects are prioritized. All of these have continued to help me do my job on the IC track and likely helped me further get promoted to Senior Staff. While I do think it’s distinctly possible that it slowed down when I got to Staff, I’m actually less sure for the next level - I think there’s a real chance I would have hung out at Staff longer without it. All of this is to say that even though I didn’t take the most direct route, I still learned a lot that has helped me out long term.

The final caveat I’d give for someone considering this switch is that people management is bigger than simply maximizing your trajectory to a Staff engineer role. You’ll have a profound impact on the folks you support as a manager, and if you take it on with the wrong motivations, you’ll regret the experience, but not nearly as much as your team will. If you’re motivated to help your team grow and succeed, then go ahead and do it; if you’re only doing it for yourself, then don’t.

A semi-permeable boundary

As a final caveat, Staff-plus titles are leadership positions. It’s uniquely challenging to gain a leadership position if the existing leadership team doesn’t identify with you as a potential member. What that means is, unfortunately, folks with the privilege of seeming like they are already part of the existing leadership team have a much easier time making the transition.

If you read through this chapter and become increasingly frustrated that you’re already doing everything here, then it’s possible that you’re experiencing that structural disadvantage. Roughly half the women I spoke with had to change companies to attain the Staff title, whereas promotion friction come up less frequently during discussions with men.

Don’t ignore those experiences–they’re real and many folks feel stymied by them–but also take hope that there are many successful role models out there regardless of how you identify and how you want to plot your course towards Staff engineer.

Next chapter: Promotion packets

Previous chapter: Present to executives

Book

If you've enjoyed reading the stories and guides on staffeng.com, you might also enjoy Staff Engineer: Leadership beyond the management track, which features many of these guides and stories.