Staff Engineer: Leadership Beyond the Management Track

by Will Larson

Success will often mean interpreting business needs, communicating a clear direction, defusing a looming crisis, convincing teams to agree on tradeoffs, or just being a good influence.

Engineers promoted beyond “senior software engineer” can find themselves alone as they navigate an under-defined new role, grappling with the mysterious notion of “impact” to understand whether they’re working on the right things, and struggling to adjust to feedback loops that come in quarters or years instead of sprints.

This isn’t intentional neglect: managers just don’t always know how to support their most senior engineers.

It’s horrifying to watch folks pursue a Staff engineer role for a decade or more, and then find that they despise the work or feel unequipped to succeed.

Being a Staff-engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.

Architects are responsible for the success of a specific technical domain within their company, for example, the company’s API design, frontend stack, storage strategy, or cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company’s success.

setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue

It can be helpful to think of this as being a part-time product manager for technology.

One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you’re accountable to the business and organization first and yourself second.

You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics.

longer timeframes can feel surprisingly demoralizing when you first take on a Staff-plus role. It’s normal to end some days as a Staff-plus engineer feeling like you haven’t accomplished anything–keep at it!

When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable.

Even if you love the privileges and perks of a Staff-plus title, it’s important to recognize that they come on the back of a very different job.

However, many folks find that their Staff role’s heightened expectations eliminate the work that used to excite them. In your career, there are few choices without consequences, and this isn’t one of them.

One of the best pieces of advice that someone gave me, and that I make sure to pass on to other staff engineers, is that there’s a misconception that you become a Staff engineer and then you’ll be in control of the work you do, and everyone will listen to you and do what you want them to do. That’s absolutely the opposite of what happens! - Katie Sylor-Miller

Create space for others so that your team grows stronger than your contribution.

I’ve taken to using the word “energized” over “impactful.” “Impactful” feels company-centric, and while that’s important, “energized” is more inwards-looking. Finding energizing work is what has kept me at Stripe for so long, pursuing impactful work. - Michelle Bu

It’s ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself honest about how much time you’re spending on high-impact work versus low-impact work.

We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent.

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineering time.

Good strategies are opinionated. If they aren’t opinionated, then they won’t provide any clarity on decision making.

I feel particularly impactful when I can help improve a proposal that’s well-intentioned and solves a real need, but the team that drafted it lacks either experience or context to write a good plan to capture the opportunity. In such cases, having a well-structured plan can help substantially reduce the scope while getting to most of the value, and thus demonstrate impact sooner. - Dmitry Petrashko

If there’s one thing that engineers, engineering managers, and technology executives are likely to agree on, it’s that there’s a crisis of technical quality. One diagnosis and cure is easy to identify: our engineers aren’t prioritizing quality, and we need to hire better engineers or retrain the ones we have.

Rather than a failure, closing the gap between your current and target technical quality is a routine, essential part of effective engineering leadership.

On the other extreme, you can allow every team to make independent decisions. But an organization that allows any tool is an organization with uniformly unsupported tooling.

Never surprise your manager. Nothing destroys trust faster than surprising your manager.

This is someone who hasn’t learned that their career depends more on being easy to involve than being technically correct.

The only way to remain a long-term leader of a genuinely successful company is to continually create space for others to take the recognition, reward, and work that got you to where you’re currently sitting. It can be surprisingly uncomfortable, but don’t worry: there will always be new work for you anyway.

Successful folks look at informing executives as absolution: once it’s on the table, you can move towards solving it rather than hiding it.

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.

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.

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.

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.

manager career path vs engineering career path” is a false dichotomy, and taking time to alternate between both roles makes you better at both.

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.

Whether your company does ad-hoc promotions or uses a calibration process, promotions are a team activity

Your project might start with only the assertion that your company’s aging monolith is crippling product development.

Speak clearly and concisely. Learn to speak concisely: as you develop an economy of speech, you’ll be able to contribute more ideas with less time. Learn to speak clearly: if folks don’t understand your proposal, then it doesn’t matter how good it is.

Effective groups are formed from individuals who are willing to disagree and commit

For better or for worse, you can’t get to Staff without a good reputation.

A big part of being promoted to Staff is making sure that your work is visible, that people know your name and you have a good reputation.

folks who took six-month-plus sabbaticals who felt reborn by the experience. Folks taking shorter stints have appreciated them but often come back only partially restored.

Well-run organizations value you for what you’re good at. Less well-run companies value you for your identity.

One line that many folks in Staff-plus roles draw is they’re unwilling to practice interview programming. This often means they are slower or make more mistakes in the sort of algorithmic questions that many companies use to evaluate early career candidates.

To maintain context in my new role, I spend a good amount of time in one-on-ones with engineers and PMs working directly on execution. This week alone, I had 12 30-minute 1-1s. I also follow every incident that’s reported at Stripe.

I expect any sufficiently-ambitious design project to continue even when I am no longer on the team. An important part of making this work was writing everything down.

I think that’s an important criteria for Staff-plus Engineers in product: not to just build something that ships, but for it to roll out smoothly and continue to succeed and grow over time with as few regrettable choices as possible.

I was a member of the Eng Tech Lead Cohort. It’s a formal group of all of the tech leads across the Engineering department meant to share context, talk through ideas, and help advance the Engineering–wide technical roadmap.