Staff Engineer: Leadership Beyond the Management Track

by Will Larson

Whatever it is, things that simply won’t happen if you don’t do them are your biggest opportunity to work on something that matters, and it’s a category that will get both narrower and deeper the further you get into your career.

Suppose you’re interviewing for a new role twenty years into your career. Will the folks interviewing you understand your real impact on any of your previous projects or companies? No, I guarantee they won’t. Instead, you’ll find yourself judged by a series of surprisingly subjective measures: your accumulated prestige, the titles you’ve had and companies you’ve worked at, your backchannel reputation, and how you present in your interview process. You can’t escape subjective interview practices, but you can deliberately accumulate expertise from doing valuable work. 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.

Write all of your best ideas in a giant document, delete it, and never mention any of them again.

Durably useful engineering strategy and vision are the output of iterative, bottom-up organizational learning.

Design documents describe the decisions and tradeoffs you’ve made in specific projects. Your company might call them RFCs or tech specs.

A good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details.

You should write a design document for any work taking more than a month of engineering time.

Gather and review together, write alone.

Good strategies guide tradeoffs and explain the rationale behind that guidance.

Some of the best strategies you write may at the time feel too obvious to bother writing. “When should we write design documents?” is a strategy worth writing.

As we leave behind the idea of strategy as demonstrations of brilliance, we can start to write far more of them, and we can write them more casually. If it ends up not being used, you can always deprecate it later.

Do write what you could accomplish if every project is finished on time and without major setbacks.

Keep it one to two pages long. The reality is that most people don’t read long documents. If you write something five or six pages long, readers will start dropping off without finishing it (or will skim it very rapidly without engaging with the details). Force yourself to write something compact, and reference extra context by linking to other documents for the subset of folks who want the full details.

So excited that it’s easy to get discouraged, then, when the response to your strategy will almost always be muted.

Second, a great vision is usually so obvious that it bores more than it excites.

Instead, measure it by reading a design document from two years ago and then one from last week; if there’s marked improvement, then your vision is good.

Still, like most narratives that move accountability towards the folks with the least power, it’s both unhelpful and wrong.

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. Rather than a failure, closing the gap between your current and target technical quality is a routine, essential part of effective engineering leadership.

There’s the old joke about Sarbannes-Oxley: it doesn’t reduce risk; it just makes it clear who to blame when things go wrong.

Selecting your next process sounds easy, but it’s often unclear which best practices are genuinely best practice and which are just familiar or famous.

Interfaces are contracts between systems. Effective interfaces decouple clients from the encapsulated implementation. Durable interfaces expose all the underlying essential complexity and none of the underlying accidental complexity.

State is the hardest part of any system to change, and that resistance to change makes stateful systems another critical leverage point. State gets complex faster than other systems and has an inertia that makes it relatively expensive to improve later.

Data models are the intersection of the interfaces and state, constraining your stateful system’s capabilities down to what your application considers legal. 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.

This works well but is challenging to scale, and the quality of an architect’s decisions degrade the further they get from doing real work on real code in the real process.

Deliberate tools create workflows that nurture habits far better than training and documentation.

Conway’s Law argues that organizations build software that reflects their structure.

My experience is that it is possible to usefully measure code quality, and it comes down to developing an extremely precise definition of quality. The more detailed you can get your definition of quality, the more useful it becomes to measure a codebase, and the more instructive it becomes to folks hoping to improve the quality of the area they’re working on.

Some representative components to consider including in your quality definition: What percentage of the code is statically typed? How many files have associated tests? What is test coverage within your codebase? How narrow are the public interfaces across modules? What percentage of files use the preferred HTTP library? Do endpoints respond to requests within 500ms after a cold start? How many functions have dangerous read-after-write behavior? Or perform unnecessary reads against the primary database instance? How many endpoints perform all state mutation within a single transaction? How many functions acquire low-granularity locks? How many hot files exist which are changed in more than half of pull requests?

The important thing is developing a precise, measurable definition.

Over time this team will accumulate systems to maintain that require scaling investment, Jenkins clusters are a common example of this, and you’ll want to size the team as a function of the broader engineering organization. Rules of thumb are tricky here, but maybe one engineer working on developer tooling for every fifteen product engineers, in addition to your infrastructure engineering investment.

Code and process change over time, and your intuition is going stale every week you’re away from building product features. Most folks find that team embedding and team rotations are the best way to keep your instincts relevant. Others monitor chat for problems, as well as a healthy schedule of 1:1 discussions with product developers.

Do fewer things, but do them better.

Although it’s almost always true that doing the few most important things will contribute more than many mediocre projects, this is even more true in cases where you’re trying to roll out tools and workflows to your entire organization (the organizational process-in-progress limits still apply here!).

workloads. One representative example is a company writing its backend servers in JavaScript and not allowing their machine learning engineers to use the Python ecosystem because they don’t want to support two ecosystems.

There’s no perfect answer here, but it’s important to establish a thoughtful approach that balances the benefits of exploration against the benefits of standardization.

Organizations behave the way they do because it’s the optimal solution to their current constraints, and you can’t shift those constraints without the advocacy of someone powerful.

A bad program is a lot like an inefficient non-profit: the goal is right, but few funds reach the intended goal.

Keep your program lean enough to cancel, and remain self-critical enough to cancel if it ceases driving quality creation.

If you find yourself struggling with technical quality–and we all do, frequently–then start with something small, and iterate on it until it works.

Slowly build towards something that genuinely works, even if it means weathering accusations of not moving fast enough. When it comes to complex systems and interdependencies, moving quickly is just optics. It’s methodical movement that gets the job done.

Titles come with the sort of power called organizational authority, and that variety of authority is loaned to you by a greater organizational authority. What’s bestowed can also be retracted, and retaining organizational authority depends on remaining deeply aligned with the bestowing sponsor, generally your direct manager.

Most mature technology companies succeed in creating a predictable promotion pipeline from folks joining early in their careers up through attaining the Senior engineer title.

After reaching a Staff role, your safety net will cease to exist, or at best, the safety net will be short enough that you’re quite capable of jumping past it and into the awaiting chasm.

Nothing destroys trust faster than surprising your manager.

Most folks have extremely high expectations of their managers, assuming, for example, that they will always remember to relay information relevant to your current work.

If the first step is avoiding surprising your manager with your own actions, the next step is to help your manager not get surprised by the wider organization.

Be clear that you’re not bringing them a problem to solve, rather conveying information you believe will be useful.

There are certainly destructive ways to manage up where someone controls information to hide problems or misrepresent circumstances, but at its core, managing up is about increasing bandwidth and reducing friction between you and your manager. Cultivating a deliberate partnership with your manager will go far further than practicing disappointment when they don’t meet your expectations.

Instead, I recommend sharpening your awareness of the distinctions between the values that you hold and those that the organization operates under and find a way to advocate for them without getting kicked out of the room.