Staff Engineer: Career Framework with Real Metrics
Will Larson's 2021 survey of 14 staff engineers at large tech companies produced a finding most ladders still ignore: only one in three senior engineers wants the Staff title, and of those, fewer than half make it in five years. The promotion is not a natural continuation of Senior. It's a role change — different work, different signals, different failure modes. Engineering ladders that treat it as "Senior+" produce stalled careers and a pile of ICs who quit for an EM job at another company.
This framework is what actually predicts readiness, drawn from a mix of Larson's research, Tanya Reilly's The Staff Engineer's Path, and the patterns we see in delivery data across 100+ B2B engineering organizations.
{/* truncate */}
Why the Staff promotion breaks most ladders
Senior engineers get promoted on output. Staff engineers get promoted on leverage. The signals are different, the measurements are different, and most performance-review processes aren't calibrated for either.
A Senior engineer ships more code than a mid-level engineer, mentors one or two people, and owns a medium-sized component end to end. A Staff engineer might commit less code than when they were Senior — but the code their influence produces (via spec reviews, architecture calls, mentorship, unblocking) dwarfs their individual output.
This is the core measurement trap: promotion panels keep looking at the commit graph. It goes flat, and the promotion stalls.
The four Staff archetypes (Larson)
Most ladders assume "Staff Engineer" is one role. It isn't. Larson's research names four distinct shapes:
| Archetype | Primary contribution | Where they fit |
|---|---|---|
| Tech Lead | Coordinates a team's technical direction | Team-focused; every team usually has one |
| Architect | Cross-cutting technical design, 3+ teams | Platform, infra, or complex-domain orgs |
| Solver | Parachutes into hard, under-owned problems | Companies with lots of legacy or unique tech debt |
| Right Hand | Force-multiplier for a VP/senior EM | Fast-growing orgs, CTO office |
A promotion committee that doesn't ask "which archetype?" often rejects a qualified Solver for not doing Tech Lead work. All four are valid Staff paths. A candidate should know which they're on before their promotion packet is written.
The progression isn't linear — it's a widening scope. Each box is a different center of gravity.
The real signals (what to track)
Commit-based metrics don't predict Staff readiness. These seven do. Some are qualitative; some show up in delivery data; all are observable.
| Signal | What "ready" looks like | How to observe |
|---|---|---|
| Cross-team influence | 3+ teams cite this engineer as shaping their roadmap | Spec co-author / comment graph |
| Spec authorship | 4-6 published specs in last 12 months, 2+ adopted beyond their team | Design-doc repo |
| Incident resolution leverage | Engineer named as lead resolver on 2+ multi-team incidents | Post-mortem records |
| Mentorship footprint | 2-3 engineers in 18 months promoted to Senior with them as named mentor | Promotion packets |
| Review throughput | Reviews code for 2+ teams regularly; comments change architecture, not just style | PR-review graph |
| Technical narrative | Can tell the "what we bet on and why" story of a major initiative in a 15-min exec conversation | Observation in reviews / meetings |
| Self-directed scope | Initiates 1-2 significant projects per year that weren't assigned | Project ownership records |
Notice the pattern: six of the seven are outputs of influence, not outputs of keyboards. A Senior engineer with 40% more commits than the team average and none of these signals is a strong Senior, not an almost-Staff. The most common promotion mistake is confusing the two.
The specific metrics we see in our data
PanDev Metrics tracks IDE heartbeat data across 100+ B2B companies. Looking at engineers who were promoted to Staff in 2024-2025 vs comparable Seniors who weren't, the signal that consistently shows up in data:
- Coding time drops 18-32% in the year before Staff promotion. Not because they're working less — because the work shifted. Meeting time, review time, spec-writing time all go up.
- Commit concentration drops. Pre-promotion Seniors commit to 3-5 repos on average. Post-promotion Staff commit to 2-3, but comment on / review 8-12.
- Project switches per day increase. Not context-switching chaos — deliberate switching between mentorship, architecture, and focused coding.
The honest limit of our data: we see activity, not the quality of the activity. A Staff engineer's review might unblock 4 teams; our signal just shows "comment added." The signals above are directional, not sufficient. Pair with qualitative signals from the table above.
The 5 questions a promotion packet should answer
Most Staff promotion packets are narrative essays. They fail on the promotion committee's real read: "can I point to evidence?" Structure the packet around five questions with concrete artifacts behind each.
1. Which archetype are you?
One sentence. Tech Lead / Architect / Solver / Right Hand. With the single project that exemplifies it.
2. What cross-team impact have you had in the last 12 months?
Name 2-3 projects that touched 2+ teams, and the engineer's specific contribution. Adopted specs beat deployed code here.
3. Who got better because of you?
Named engineers, named promotions, named projects they now lead. If the list is empty, the engineer is a strong Senior, not a Staff candidate.
4. What's a technical decision you changed that was counter to the initial direction?
This is the Staff signal. A Senior advocates inside the decision frame. A Staff redefines the frame. Be specific: decision, what you argued, outcome.
5. What's your next 12-month bet?
If the engineer can name a specific technical area they intend to move forward regardless of whether they get promoted, that's Staff-ready agency. If the answer is "whatever the company needs," they're not ready yet — they've mistaken compliance for leadership.
Common promotion failure modes
- The "heads-down great Senior" trap. Consistently exceeds quarterly goals, but every impact is inside their team's boundary. No cross-team evidence. Panel rejects. Fix: start with one small cross-team initiative 18 months before the target date.
- The "wannabe architect with no receipts" trap. Writes lots of RFCs, few get adopted. Panel asks "what shipped?" and the candidate can't answer. Fix: fewer RFCs, more follow-through. An adopted 3-page doc beats 10 ignored 20-page ones.
- The "lost in meetings" trap. Stopped coding, hasn't yet built the narrative muscle for Staff work. Produces no artifacts. Panel sees a drop in output with no replacement. Fix: treat every important meeting as producing one artifact — a doc, a decision log, a follow-up PR. No artifact, the meeting didn't happen.
- The "wrong manager" trap. Staff promotions fail without an EM who writes strong promotion cases. If the engineer's EM has never promoted a Staff, seek a co-sponsor early.
How to measure progress as the candidate
Quarterly, for the 4-6 quarters before a target promotion date:
- Number of cross-team specs co-authored or reviewed (target: 2-3/quarter)
- Number of engineers actively mentored (target: 2-3 ongoing)
- Number of incidents where you were named resolver beyond your team (target: 1/quarter)
- Number of executive-level technical conversations where you represented the team (target: 1-2/quarter)
- Coding time change (expect gradual decline, 10-25% over 4 quarters — if it stays flat, you're not shifting yet)
Teams running PanDev Metrics can pull the coding-time trend automatically; the rest require self-tracking or a good EM. The CTO dashboard article covers one way to surface these at the org level.
When this framework doesn't fit
Startups under 20 engineers often don't need Staff roles yet — the CTO or VP Engineering absorbs the function. Promoting into Staff prematurely creates a role without the structural scope that justifies it. In those companies, "Senior 3" or "Principal Engineer as second-in-command" is usually a better fit.
Very large companies (1000+ engineers) often split Staff into Staff 1 / Staff 2 / Senior Staff / Principal, with its own scope definitions. The archetypes still apply; the scope per level changes. Use your company's ladder, but anchor each level to the archetypes.
Related reading
- Tech Lead vs Engineering Manager: The Decision Framework
- VP Engineering: The First 90 Days
- Performance Reviews Based on Data: Templates and Anti-Patterns
- External: Will Larson — Staff Engineer: Leadership beyond the management track
- External: Tanya Reilly — The Staff Engineer's Path
The sharpest version of the rule: Senior engineers make their team better; Staff engineers make other teams better even when they're not in the room. If you can't describe the last time that happened, you're not yet on the path.