Multiply,
don't add.

A senior engineer is, roughly, someone who independently delivers complex projects well — they're measured by their own output, and they're very good at it. The staff engineer (and staff-plus: principal, distinguished) is measured by something different: leverage, the impact created through others and across the organization, beyond what any individual could personally ship. This is why the promotion trips people up — they double down on the thing that got them to senior (more, better personal output) when the next level rewards a different thing entirely.

Think of it as a change in the multiplication. A senior adds their output to the team's total. A staff engineer multiplies the team's output — a good architecture makes ten engineers meaningfully faster, a clear standard removes friction for everyone, a mentored engineer levels up permanently. The value isn't in the artifact with your name on it; it's in the amplification of everyone else. The clearest single signal that someone is operating at staff level is that impact through others has come to dominate their personal output — a threshold you can literally compute, and the spine of this handbook. Get this reframe and the rest follows; miss it and you'll be the best senior engineer who never quite makes staff.

"Staff engineer" isn't one job — it's several. Will Larson's widely-cited framing names four archetypes, and knowing which one a moment calls for keeps you applying leverage instead of defaulting to writing code:

Most staff engineers lean into one archetype at a time depending on what the organization needs, and many rotate through several over a career. The point of the taxonomy isn't to label yourself — it's to recognize that these are genuinely different modes of applying leverage, and that a role or a moment usually calls for one in particular. A team drifting without technical direction needs a Tech Lead or Architect; a critical system on fire needs a Solver; an executive who needs a technical partner needs a Right Hand. A common failure is bringing the wrong archetype to the situation — trying to Solver your way through a problem that actually needs Architect-style alignment, or hands-on-coding when the org needs you facilitating a cross-team decision. Match your mode to the need, and your leverage lands where it counts.

A huge share of staff leverage takes the form of glue work — the essential, often invisible activity that holds a project or organization together but never shows up as a shipped feature. Unblocking someone stuck. Aligning two teams heading for a collision. Writing the design doc everyone ends up referencing. Noticing the thing falling through the cracks that no one owns. Mentoring, reviewing, facilitating the decision that had been stuck for weeks. None of it has your name on a commit, and all of it can be worth more than any feature you'd have built instead.

Glue work is high-leverage almost by definition — a single well-run alignment or one clarifying document can save many people many weeks — which is exactly why staff engineers do so much of it: multiplying others is this kind of connective work. But there's a real tension, made famous by Tanya Reilly's talk on the subject: glue work is often under-credited because it isn't a visible artifact, so if organizations don't see and reward it, people rationally avoid it and it falls to whoever cares most (frequently, and unfairly, along demographic lines). Two lessons follow. As a staff engineer, do the glue work and make it visible — write it down, name it in updates, so the leverage is legible. And as an organization, count glue work as real work, because it's frequently where the highest leverage in the whole system quietly lives. The connective tissue isn't overhead; at staff scope, it's the job.

Total impact is your own output plus the added output you create in others; the leverage is that second term, and a team-wide improvement is worth the whole team times the per-person boost:

A decision that makes 10 engineers 20% more effective = 10 × 0.2 = 2 "engineer-equivalents" of added output — more than most individuals ship personally.

Staff level is the threshold where leverage — impact through others — dominates your own hands-on output:

Own output 1, multipliers [3,4] → leverage 7 dominates → staff-level. Own 5, multipliers [1,1] → 2 < 5 → not yet. The runnable version below computes total impact, leverage, the ratio, and the staff threshold.

Knowing leverage is the goal, here's how staff engineers actually generate it day to day:

Two of these deserve emphasis because they're the biggest surprises for new staff engineers. First, writing is the job: at a scope that spans teams and quarters, you can't be in every room, so your ideas propagate as documents — a crisp design doc or technical strategy is how a single person aligns dozens and outlives their own attention. Engineers who neglect writing cap their leverage no matter how strong their code. Second, influence without authority: a staff engineer commands almost no one, so every bit of impact is earned through persuasion, credibility, and trust rather than a title — which means being consistently right, communicating clearly, and building relationships is not politics, it's the actual mechanism of the role. Combine these — pick the highest-leverage problem, propagate your thinking in writing, persuade with earned trust, multiply others through mentoring and standards, and stay technically sharp — and you're doing the job the leverage math describes: turning one person's effort into an organization's output.

The first is staying a hero individual contributor — hoarding the hardest coding and out-shipping everyone. It feels productive and it got you to senior, but it caps your impact at one person's throughput and, worse, deprives the people around you of the growth and the space you're supposed to be creating. The staff move is often to hand off the work you're best at so you can do the multiplying only you can do. The second is the mirror image: floating up into pure abstraction — becoming an "architecture astronaut" who pronounces on strategy while losing touch with the code and the real constraints. Leverage rests on credibility, and credibility rests on being close enough to the details to be right; a staff engineer who can't get their hands dirty stops being trusted, and untrusted influence is no influence.

Two more. Doing invisible glue work with no visibility: the connective work is high-leverage but easy to leave uncredited — do it and make it legible (write it down, name it), or you'll be quietly essential and never recognized. And bringing the wrong archetype: Solver-ing a problem that needs Architect-style alignment, or hands-on-coding when the org needs facilitation — match your mode to the moment. The unifying idea is that staff engineering is a genuine phase change, not a continuation: you stop being measured by the excellent thing you personally build and start being measured by how much you multiply everyone around you. Internalize "leverage over output," pick the highest-leverage problem, propagate through writing and trust, make your glue work visible, and stay technically grounded — and you cross the gap that the best senior engineers so often stall at, from adding to a team's output to multiplying it.