Staff Engineer: Leadership Beyond the Management Track

by Will Larson

an organization needs roughly one Tech Lead for every eight engineers,

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.

Influential architects dedicate their energy to maintaining an intimate understanding of the business’ needs, their users’ goals, and the relevant technical constraints. They use that insight to identify and advocate for effective approaches within their area of focus, and do it with organizational authority that they’ve earned by demonstrating consistently good judgment.

The Solver is most common in companies that think of individuals, rather than teams, as the atomic unit of planning and ownership.

Technology cannot speak for itself and requires effective advocates on its behalf. 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.

Assumes a Settler, Town Planner context. Doesn't necessarily hold for a Pioneer context.

You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics. The best way to grow those around you is by creating an active practice of mentorship and sponsorship.

If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want. Being a Staff-plus engineer, especially a broad-scoped Staff-plus engineer, is a very different job than being a Senior engineer.

If you have a problem and believe that your title is the only thing holding you back, I want to reassure you that focusing on developing your approach and skills will be far more impactful than the title.

I’ve taken to using the word “energized” over “impactful.” “Impactful” feels company-centric, and while that’s important, “energized” is more inwards-looking.

pacing yourself becomes the central challenge of a sustained, successful career: increasingly senior roles require that you accomplish more and more and do it in less and less time.

Preening is doing low-impact, high-visibility work.

If a company’s leadership consists entirely of folks who focus their energy on performative urgency or acts of fealty, don’t be surprised when your success in the company depends on those activities.

As a senior leader, you have to maintain a hold on your ego to avoid investing in meaningless work on a grand scale.

If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.

Existential issues are usually not the most efficient place to add your efforts, but efficiency isn’t a priority when the walls are crashing down around you.

You should swarm to existential problems, but if a problem isn’t existential, then you should be skeptical of adding your efforts where everyone’s already focused.

the most effective places to work are those that matter to your company but still have enough room to actually do work. What are priorities that will become critical in the future, where you can do great work ahead of time? Where are areas that are doing ok but could be doing great with your support?

Teaching a company to value something it doesn’t care about is the hardest sort of work you can do, and it often fails, so you should do as little of it as you can, but no less.

onboarding, mentoring, and coaching are wholly neglected at many companies despite being at least as impactful as hiring to your company’s engineering velocity.

If you start dedicating even a couple of hours a week to developing the team around you, it’s quite likely that will become your legacy long after your tech specs and pull requests are forgotten.

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.

Sure there’s work that you’re faster at or better at than some other folks, but much more important is the sort of work that simply won’t happen if you don’t do it.

Indeed, that’s the only viable long-term bet on your career: focus on work that matters, do projects that develop you, and steer towards companies that value genuine experience.

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 are tools of proactive alignment that empower teams to move quickly and with confidence. Strategies allow everyone–not just the empowered few–to make quick, confident decisions that might have otherwise cost them a week of discussion.

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.

It’s easy for two well-meaning engineers on the same team to interpret an abstract strategy in different ways, but it’s much harder to stay misaligned when you’re implementing a specific solution.

Overloaded templates discourage folks from writing design documents in the first place. Prefer minimal design document templates that allow authors to select the most useful sections and only insist on exhaustive details for the riskiest projects.

Gather perspectives widely but write alone.

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.

Take five of your recent strategies, extrapolate how their tradeoffs will play out over the next two to three years. As you edit through the contradictions and weave the threads together, you’ve written an engineering vision.

Visions should be ambitious, but they shouldn’t be audacious. They should be possible, but the best possible version if possible.

AKA Idealized Design

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.

As an engineering leadership team, your goal is to maintain an appropriate technical quality level while devoting as much energy as possible towards the core business.

retaining organizational authority depends on remaining deeply aligned with the bestowing sponsor, generally your direct manager.

Staff-plus roles are leadership roles, and in leadership roles, the support system that got you here will fade away. Often abruptly, you’re now expected to align the pieces around you for your own success.

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

Don’t let your sponsor surprise you.

If there’s something you disagree with but only in a minor way, let others take the lead figuring it out. A helpful question here is, “Will what we do here matter to me in six months?” If it won’t, take the opportunity to follow.

If you ever find yourself in a conversation with an unclear goal, then define the purpose.

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

longevity as a senior leader is just as much about maintaining your relationships as it is about standout successes.

One of the best measures of your long-term success as a Staff-plus engineer is that the organization around you increasingly benefits from, but doesn’t rely upon, your contributions.

When you’re focused on maximizing your personal impact, a good discussion is one that ends quickly with a reasonable answer, alignment among the participants, and positive feelings among the participants. When you start thinking about creating space, the definition of a good discussion expands quite a bit!

Shift your contribution towards asking questions.

If you see someone in the meeting who isn’t participating, pull them into the discussion.

Be the one to take notes.

If you realize someone’s missing from the discussion who should be there, be the person to pull them into the next occurrence of the meeting.