Staff Engineer: Leadership Beyond the Management Track

by Will Larson

career ladders are a tool that applies better against populations than people.

The four common archetypes of Staff-plus roles I encountered are:

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.

The Architect role tends to evolve in relatively large companies, companies with exceptionally complex or coupled codebases, and companies that are struggling to repay the technical debt they created in their initial sprint to product-market fit.

The Solver is a trusted agent of the organization who goes deep into knotty problems, continuing to work on them until they’re resolved. Folks in this role are moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high degree of execution risk.

And I would argue that so far this is the way I have seen Staff Engineer used within Alerts

The Right Hand is the least common of the archetypes, showing up as an organization reaches hundreds of engineers and is akin to operating as a senior organizational leader without direct managerial responsibilities.

Their daily schedule varies a bit by archetype, but there’s a shared foundation across all archetypes: setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue.

Folks who successfully advance technology are pragmatic, deliberate, and focus more on the long-term trend of progress than viewing each individual decision as a make-or-break crisis. 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.

another core element of successful Staff engineers: doing the needed, but often invisible, tasks to keep the team moving forward and shipping its work.

A potential fourth advantage is that some folks find that the title grants more agency to select the projects you work on, but others find that increase in agency is swallowed by a commensurate increase in accountability to the business.

Learn to never be wrong shift away from being right and towards understanding and communication.

Ah yes my old mantra -- we meet again

First, a discussion on a few common ways to get tripped up: snacking, preening, and chasing ghosts. Then we’ll get into the good stuff: how do you work on what really matters?

The reality is that good engineering strategy is boring and that it’s easier to write an effective strategy than a bad one.

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.

Strategies allow everyone–not just the empowered few–to make quick, confident decisions that might have otherwise cost them a week of discussion.

If you realize that you’ve rehashed the same discussion three or four times, it’s time to write a strategy.

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.

Focus on pushing designs to be good, rather than fixating on your own best as the relevant quality bar.

Look for controversial decisions that came up in multiple designs, particularly those that were hard to agree on.

Good strategies guide tradeoffs and explain the rationale behind that guidance. Bad strategies state a policy without explanation, which decouples them from the context they were made.

The final version will give you what Tanya Reilly calls a robust belief in the future, which makes it easier to understand how your existing strategies relate to each other and simplifies writing new strategies that stand the test of time.

RE: an engineering/technical vision

Details in visions are often illustrative rather than declarative, giving a taste of the future’s flavor rather than offering a binding commitment.

having a well-structured plan can help substantially reduce the scope while getting to most of the value, and thus demonstrate impact sooner.

In most cases, low technical quality isn’t a crisis; it’s the expected, normal state. Engineers generally make reasonable quality decisions when they make them, and successful companies raise their quality bar over time as they scale, pivot, or shift up-market towards enterprise users. At a well-run and successful company, most of your previous technical decisions won’t meet your current quality threshold.

Technical quality is a long-term game. There’s no such thing as winning, only learning and earning the chance to keep playing.

Even if it doesn’t work, you’ll learn more and more quickly from failing to roll out the easy stuff than failing to roll out the hard stuff.

Don’t abandon the ease, joy, and innocence of early organizations for the perils of enterprise-scale coordination without proper need.

If something isn’t working, try for a bit to make it work, and then celebrate its demise.

Process rollout requires humans to change how they work, which you shouldn’t undertake lightly.

BOOM! Yes! Behavioral change is hard and so shouldn’t be the first thing you reach for.

Sure, you can roll out a new training program to teach your team how to write better tests, but alternatively, maybe you can just delete the one test file where 98% of test failures happen.

Sounds like sacrilege but so true.

Of course, no one started to use Scrum. Everyone kept doing what they’d done before.

“…but now with stand-ups!”

A rushed process is a failed process.

Channel all your energy towards making one practice a success rather than splitting resources across a handful.

I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.

Durable interfaces expose all the underlying essential complexity and none of the underlying accidental complexity.

State gets complex faster than other systems and has an inertia that makes it relatively expensive to improve later.

A good data model is rigid: it only exposes what it genuinely supports and prevents invalid states’ expression. A good data model is tolerant of evolution over time. Effective data models are not even slightly clever.

When it comes to complex systems and interdependencies, moving quickly is just optics. It’s methodical movement that gets the job done.

The way I think about leadership has evolved a bit over the last few years, though, coming to focus on two specific attributes. First, leaders have a sufficiently refined view of how things ought to work such that they can rely on their distinction between how things are and how they ought to be to identify proactive, congruent actions to narrow that gap. Second, they care enough about the gap to actually attempt those narrowing actions.

I think this is the most important lesson I’ve learned over the past few years: the most effective leaders spend more time following than they do leading. This idea also comes up in the idea of the “the first follower creates a leader,” but effective leaders don’t split the world into a leader and follower dichotomy, rather they move in and out of leadership and follower roles with the folks around them.

The most effective engineers go into each meeting with the goal of agreeing on the problem at hand, understanding the needs and perspectives within the room, and identifying what needs to happen to align on an approach. They approach each meeting as one round within the broader context of the project and their relationships with the folks in the room.

To get good at this, you need to master three approaches: listen through questions, define the purpose, and know how to read the room.

The act of asking good questions with good intent opens up a conversation, creating space and safety for others to ask their own questions. Good questions are asked with the desire to learn, and they are specific. They sharpen the conversation. They free the answerer from the obligation to defend their position.

If you ever find yourself in a conversation with an unclear goal, then define the purpose. Take a moment to ask if your understanding of what the group hopes to accomplish is correct.

Meetings with multiple failed reframings almost always end with scheduling another meeting.

Start each week by picking one of these skills you want to explicitly use in the meetings you head into.

This transition requires learning to deliberately create space for the team around you and comes down to actively involving them in discussions, decisions, and ultimately substituting sponsorship for repeating the successes that got you to Staff in the first place.

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.