DEEP READING · READ 912
Staff Engineer: Leadership Beyond the Management Track · Will Larson · 2021
Every engineer eventually hits a fork: move into management, or stay technical — and most people assume the next stop on the technical road is "an even more senior senior engineer." This book says otherwise: Staff and above is a different kind of job, measured not by how much you build but by how much wasted motion you spare the organisation. It also says something less comfortable: getting the title is half about how well you work and half about whether your company has the slot at all — and whether anyone can see you in it.
Larson led engineering at Digg, Uber and Stripe before becoming a CTO; his blog, lethain.com, is among the most-read writing in the field. His previous book, An Elegant Puzzle, was about running an engineering organisation; this one turns to the path that doesn't go through management. It comes in two halves: his own argument, then interviews with more than a dozen engineers who reached Staff+ at different companies — which makes it a field report rather than a theory. Its weight comes from timing: before it, "what exists above senior engineer" had almost no public text. Management had a whole shelf; the technical track had company-internal folklore. The first thing this book does is give that path a vocabulary you can argue with.
Staff+ is the umbrella term for Staff, Senior Staff, Principal and Distinguished — the technical levels above Senior Engineer. Larson insists on a distinction that is easy to miss: going from engineer to senior engineer is an increase in quantity — harder problems, bigger surfaces, less rework. Going from senior to Staff is a change in kind.
How so? At senior, someone hands you a problem and you solve it beautifully. At Staff, the problem itself becomes your object of work: is this a real problem? is it a symptom of another one? is now the time? who maintains this in three years? And your output is often no longer code but a conversation that changed someone's mind, a document, a project you talked the company out of. Larson's formulation is solid: a senior engineer is expected to get things done; a Staff engineer is expected to get a group of people doing the right things.
This creates the psychological hurdle that stops a lot of people: the feeling of completion disappears. Shipping code has a moment of doneness; "prevented a bad architectural decision" never gets a congratulatory email, because the disaster didn't happen. Accepting that your largest contributions are frequently invisible and unprovable is the price of admission. It also explains why people at this level are unusually prone to self-doubt: a manager at least has headcount and delivery cadence as feedback, while for long stretches all you hold is a pile of bad things that didn't occur.
This is the book's most widely circulated section, and its most useful — because it replaces the unanswerable question ("what is a Staff engineer supposed to do?") with an answerable one ("which of these four are you?").
| Archetype | Scope | What the days look like |
| Tech Lead | One team (or a few) | Paired with a manager: breaking down the work, setting the approach, holding quality. The most common one |
| Architect | One critical area | Holding direction and quality where complexity or business risk is highest (payments, storage, auth), on the strength of accumulated domain depth |
| Solver | Whatever is on fire now | Parachuted into the hardest current problem, then the next one; never owns an area for long |
| Right Hand | The whole org | Working alongside an engineering executive on borrowed authority: leadership meetings, org-scale messes. The rarest |
These are not rungs on a ladder but different shapes of the job — which ones exist at all depends on your company's size and culture.
Why the table earns its keep: most Staff-level misery comes from holding the expectations of one archetype while doing the work of another. You think you're an Architect (accumulate depth, set standards); the company actually wants a Solver (go where the fire is). So you feel you've done nothing but firefight and learned nothing, while the company feels you're clinging to your patch instead of going to the front. Naming the mismatch dissolves a surprising amount of "am I even doing this right" anxiety on the spot. Larson also warns that Solver and Right Hand depend heavily on one specific person and are nearly impossible to replicate, which makes them draining over time; Tech Lead and Architect are more sustainable.
He sorts the work into four buckets. ① Setting technical direction: note the counterintuitive emphasis — the hard part is not technical, it's hearing what the business actually needs and translating that into a technical judgment. "I like this technology" is the least important input. ② Growing people. ③ Providing an engineering perspective: being in the rooms where no engineer is present and stating, in a sentence or two, the technical cost of a decision — a great many disasters are agreed to in exactly those meetings. ④ Exploration: taking on the ambiguous, high-risk work no one else will touch, and burning down a layer of uncertainty for the company. The classic case is "should we adopt this new architecture" — nobody wants to call it, and one senior person spending two months on a credible answer is far cheaper than three teams guessing for six.
Inside the second bucket sits the book's most immediately usable distinction: mentorship and sponsorship are not the same thing. Mentorship is advice — you buy me a coffee, I tell you what I'd do. It costs me little and ends when the conversation does. Sponsorship is spending your own credibility on someone else: naming them for the project in a room they aren't in, handing them the opportunity that will make them visible, and absorbing part of the hit if it goes badly.
The difference is who carries the risk: in mentorship it's them, in sponsorship it's you. Which is why sponsorship is so much rarer and so much more effective — almost nobody's career jumps because someone gave them good advice; careers jump because someone put them in a room they couldn't get into on their own. If you want to test whether you're really developing people, ask one question: in the last six months, whom have I spent my own credibility on? If nothing comes to mind, what you've been doing is mentorship.
The term comes from engineer Tanya Reilly's widely circulated talk of that name: the work that holds a project together yet appears on no performance form — writing the doc nobody wrote, aligning teams, catching the requirement that fell between two groups, running the meeting that unsticks the thing, being the living map for new joiners.
Larson's position: at Staff level glue work isn't chores, it is the job — because the larger an organisation gets, the more of its value is created in the seams between teams, and seams have no owner.
But the other half of Reilly's point has to be said too, or this becomes an exhortation to unpaid labour. Half of her original talk is a warning: glue work often goes uncredited, and it lands disproportionately on women and underrepresented engineers — someone can spend three years holding a team together and then be told at promotion review that their technical output is thin, and be pushed off the technical track altogether. So the real rule is conditional: glue work is leverage once you have the standing to narrate it, and a trap before you do. There are only two practical defences: write it down, turning "what I coordinated, what I prevented" into a recorded result; and make sure someone (your manager, your sponsor) explicitly counts it. Glue that nobody books is just time absorbed.
This is the most honest chapter and the easiest to skim past. Larson's claim is that virtually every company effectively requires a "Staff project" — something big enough, important enough, and easy enough for other people to retell that whoever sits on the review committee can say in one sentence why you should be promoted. It has to satisfy three conditions at once: the company genuinely cares, leadership can see it, and you can actually land it. Two out of three is nothing — a beautiful piece of work the company doesn't care about counts for zero, and so does important work nobody knows you did.
Then the unflattering part: the Staff title is more a function of your company than of you. Three senses. ① The slots are finite — a company needs enough scale and complexity to want this layer at all, so the best engineer at a small company may never get the title, and that is not a verdict on ability. ② You need to be somewhere that values the thing you're good at; someone excellent at hardening infrastructure inside an org that only rewards shipping features will be judged as under-contributing indefinitely. ③ Fast-growing companies have more openings and more chances — the single largest structural variable.
Out of this comes the least anxious sentence in the book: you don't need the title to do the job. The title ratifies an accomplished fact; it isn't a licence. And seeing clearly how much is structure and how much is you keeps a missed promotion from turning into a wrong verdict on yourself — while also getting you to the real decision sooner: wait here for a slot, or go somewhere with more of them.
At this level the main risk is no longer doing the work badly; it is pouring effort into work that doesn't matter. Larson names three familiar forms of self-deception. Snacking: picking small, easy, immediately satisfying tasks — pleasant to finish, and nothing is different afterwards. Preening: picking high-visibility, low-impact work that looks impressive while the company would run fine without it. Chasing ghosts: spending months on a problem you believe exists but which is long gone or which nobody cares about, usually because your model of the organisation has gone stale. What the three share is that they all make you feel busy and productive while the organisation's situation is unchanged.
What to do instead is to move toward whatever will constrain the company next — and he gives a wonderfully crude method for writing that down. Don't sit down to "devise a strategy"; that only produces correct-sounding nothing:
The elegance is in the direction of travel: strategy stops being something announced from nowhere and becomes something induced from decisions already made. What you write is therefore evidence-backed by construction, and people accept it — because it is what they were already doing, and you are simply the first person to say it plainly.
One last practical rule: when presenting to executives, lead with the conclusion. Don't use the order of a paper — background, analysis, findings, conclusion. Executive time runs in minutes, and they will interrupt and take the conversation anywhere they like. State the answer and the decision you need first, then work backwards through the reasons — if you get interrupted, the sentence that mattered has already been said.
Two halves, and the logic is straightforward:
So what does the book establish? Not "do this and you'll be promoted," but that a chronically vague role can be made discussable: it supplies the vocabulary (four archetypes, Staff project, sponsorship, glue), separates what your effort governs from what your company's structure governs, and puts the problem of invisible contribution squarely on the table for the first time. Its value is not the answers — it's that you can finally ask the right question.
① Engineer to senior is a change in quantity; senior to Staff is a change in kind — the problem itself becomes the object of your work.
② A senior engineer is expected to get things done; a Staff engineer is expected to get a group of people doing the right things.
③ The price of admission is accepting that your biggest contributions are often invisible and unprovable — nobody remembers the disaster you prevented.
④ Four archetypes: Tech Lead (one team), Architect (one critical area), Solver (wherever it's burning), Right Hand (org-scale work beside an executive). Most of the pain comes from holding one archetype's expectations while doing another's work.
⑤ The hardest part of setting technical direction isn't technical — it's hearing what the business actually needs and translating it into a technical judgment; "I like this technology" is the least important input.
⑥ Mentorship spends advice; sponsorship spends your credibility. Self-test: in the last six months, whom did I spend mine on? No answer means you've been mentoring.
⑦ At this level glue work is the job — but glue that nobody books is just time absorbed; it's leverage once you have standing, and a trap before you do.
⑧ Promotion generally requires a "Staff project": the company genuinely cares, leadership can see it, and you can land it — two out of three counts for nothing.
⑨ The title is more a function of your company than of you — the slots are finite and the criteria have to match your strengths. Seeing that clearly is how you avoid the wrong verdict on yourself.
⑩ Don't snack (satisfying, useless), don't preen (visible, low impact), don't chase ghosts (solving problems that no longer exist); the crude way to write strategy is induce it from five design docs, then induce a vision from five strategies — and with executives, always lead with the conclusion.