The Staff+ Engineer Track: Tech Lead, Architect, Solver, Right Hand — and How HR Should Support Each

60-Second Summary

Staff+ is not 'a really good senior engineer'. It is a distinct job with its own scope, deliverables, and failure modes.
Will Larson's four archetypes — Tech Lead, Architect, Solver, Right Hand — are not interchangeable; promoting one shape into another's slot is a frequent and expensive mistake.
Most dual ladders collapse because companies define Staff+ as 'manager work without people management'. It isn't.
Promotion to Staff requires evidence of multi-team impact, written artefacts, and named sponsors — not just years served.
HR's job is to defend the IC ladder in compensation, calibration, and visibility — not to mirror the manager ladder.

Most engineering organisations claim to have a dual ladder — one path for managers, one for senior individual contributors (ICs) — and most of them are lying. They have a manager ladder and a polite fiction. The fiction collapses for a predictable reason: 'Staff+' is treated as a single job, and the company has no language for the four very different shapes the job actually takes. Will Larson's book Staff Engineer (2021) named these shapes; the framing has since been adopted by Stripe, Slack, Shopify, GitHub, Datadog, and most others. This article is for the HR partner and engineering leader who needs to make the ladder real.

Why a Staff+ track exists

Beyond a certain seniority, the most valuable engineers are usually worse, not better, when forced to manage people. They are also a flight risk if the only path 'up' requires they stop coding. The dual ladder solves both problems: it creates a senior career path that pays manager-equivalent compensation, carries comparable scope and authority, but produces technical artefacts instead of headcount.

Plain-English definition

An Individual Contributor (IC) is an engineer with no direct reports. A 'Staff+ engineer' is an IC at the equivalent level of a senior manager, director, or higher — measured by scope of impact, not headcount.

The four archetypes (Larson)

Will Larson's four Staff+ archetypes

Archetype	Day looks like	Typical artefacts	Reports to	Who needs this
Tech Lead	Embedded in one team, owns technical direction, partners closely with an EM	Quarterly tech plan, design docs, mentorship	Engineering manager of that team	Every team with 4+ engineers
Architect	Owns the long-arc technical strategy of a domain across multiple teams	Reference architectures, ADRs, multi-quarter roadmaps	Director or VP of engineering	Companies past ~50 engineers with cross-team technical debt
Solver	Parachuted into the org's most painful problem of the quarter — performance regression, scaling crisis, ambiguous greenfield	Crisis post-mortems, prototype that proves the path, hand-off doc	VP eng / CTO, lightweight reporting	Mid-large orgs (>100 eng) with recurring crises or step-change projects
Right Hand	Force-multiplier for an executive — usually the CTO. Owns whatever the CTO cannot personally hold	Strategy memos, exec-level decision frameworks, sometimes M&A diligence	CTO / VP eng directly	Rare; appears at >150 engineers

The crucial point: these are not levels of seniority. They are distinct jobs. A great Solver may be a poor Architect; an excellent Tech Lead may flounder as a Right Hand. The work, the audiences, the artefacts, and the success metrics all differ.

Matching archetype to org need

Diagnosing which archetype the role actually wants

1
Does the work span one team or many?
One team → Tech Lead. Many teams in one domain → Architect. The whole company → Solver or Right Hand.
2
Is the time horizon a quarter or a year+?
Quarter-to-quarter delivery → Tech Lead. Year-plus → Architect. Crisis-paced → Solver. Open-ended → Right Hand.
3
Who is the primary audience for their writing?
Team engineers → Tech Lead. Engineering directors and partner teams → Architect. Exec staff → Solver or Right Hand.
4
What ends their week well?
A shipped feature → Tech Lead. A signed-off ADR → Architect. A defused incident or proven prototype → Solver. An aligned exec → Right Hand.

Scope, impact, and the 'multi-team' bar

Every Staff+ rubric eventually arrives at the phrase 'multi-team impact', and every promotion debate fights about what it means. A working definition: the engineer's work substantively changes the technical direction, productivity, or capability of two or more teams beyond their own, in a way at least one director can name and defend in writing.

The 'glue work' trap

Tanya Reilly's essay 'Being Glue' (2019) named the problem: a lot of Staff-level work — running incidents, mentoring, drafting docs, coordinating across teams — is invisible to performance reviews built for IC4. Companies that don't explicitly credit glue work end up with Staff+ titles that go disproportionately to those who refuse to do it.

Hiring at Staff+

Decide the archetype before you write the JD. 'Senior staff engineer' as a generic posting attracts the wrong candidates.
Replace live whiteboard coding with code review of a real PR, plus design review of a system the candidate has built.
Add a 60-minute 'past projects deep dive' interview that pressure-tests scope claims with 'what did you personally do?' follow-ups.
Include at least one partner from a function the candidate must influence (PM, security, infra). If the candidate cannot collaborate with that function in 45 minutes, they cannot do the job.
Have a current Staff+ engineer of the matching archetype on the loop. Like recognises like.

Promotion to Staff+

The single largest source of perceived unfairness in engineering organisations is the Senior-to-Staff jump. The work is genuinely different, the rubric is genuinely vague, and the politics are genuinely real. Three practices make it survivable:

What a credible Senior→Staff promotion requires

1
A written promotion packet
5–10 pages: scope, named projects, named impact, named partners, written artefacts. See the dedicated promotion packets article in this playbook.
2
Two named sponsors at Staff+ or above
Sponsors are not just supportive — they have read the packet, defended it in calibration, and put their own credibility behind it.
3
Evidence of operating-at-level for 2+ quarters
Staff is promoted to the work already happening, not as an aspiration. If the candidate hasn't been operating at Staff scope for at least 6 months, the answer is 'not yet'.

Performance evaluation that doesn't punish ICs

Stack-ranking and forced distributions are particularly poisonous to a Staff+ track because the rubric for each archetype is different, comparisons are not commensurate, and the visible deliverables of a Solver (a defused incident) look much smaller than those of a Tech Lead (a launched feature). Use archetype-specific success criteria and calibrate within archetype where possible.

Success signals by archetype

Archetype	Primary signal	Secondary signal	Lagging signal
Tech Lead	Team's DORA / SPACE metrics	Team's engagement and retention	Quality of engineers grown into senior roles
Architect	Adoption of reference architectures	Reduction in cross-team duplication / incidents	Technical strategy that survives 2 years
Solver	Time-to-defuse named crises	Quality of prototype and hand-off	Crises that did not recur
Right Hand	Decision throughput at exec layer	Quality of strategy memos	Org changes successfully made

Retention and the title-vs-money trap

Staff+ engineers are usually the most marketable people in the company. The market for Staff at a top-tier US firm pays $400k–$700k+ total comp; for Principal/Distinguished, $700k–$1.5M+ (Levels.fyi 2026 data). If your bands are stale, you will lose them quietly. Equally important: title carries real psychological weight, especially for engineers who chose IC because they wanted recognition without management. Refusing to use the title 'Principal' to save a 'tier' is one of the most common and expensive mistakes.

Anti-patterns that kill the dual ladder

Staff is a consolation prize for engineers who 'didn't want to manage'.
Compensation bands cap Staff below first-line Manager.
Calibration meetings dominated by managers; no Staff+ engineers in the room.
Promotion to Staff requires being assigned a project the candidate has no power to choose.
No public examples of recent Staff promotions; the path is rumoured rather than visible.
Architect title given to someone with no implementation experience in the domain.

Monday-morning checklist

Write down the archetype of every Staff+ engineer in your org. If you can't, the ladder isn't real.
Confirm compensation bands for Staff ≥ first-line Manager; for Senior Staff ≥ Director.
Add Staff+ engineers to calibration meetings for IC promotions.
Publish 2 recent promotion stories with redacted packets internally.
Audit last year's Staff promotions for glue-work credit and demographic spread.

FAQ

Frequently asked questions

We're 30 engineers. Do we need a Staff+ track?

Usually not yet. Below ~40 engineers, a strong Senior IC track is enough. A premature Staff title creates expectations the org cannot support.

Can someone move between archetypes?

Yes, but treat it as a role change, not a promotion. Some companies (Stripe) explicitly rotate Solvers into Architect roles after 18 months.

Should Staff+ engineers attend leadership offsites?

Yes, at least the technical ones. Excluding them re-creates the very status gap the ladder is supposed to close.

How does this work in smaller markets without inflated comp?

The archetypes are universal; the comp ratio matters more than the absolute number. As long as Staff IC ≥ first-line Manager locally, the ladder functions.

References

Will Larson — Staff Engineer: Leadership Beyond the Management Track (2021) — StaffEng
Tanya Reilly — Being Glue (2019) — Tanya Reilly
Levels.fyi — Compensation data — Levels.fyi
Lara Hogan — Career-cold-cases for Staff+ — Lara Hogan

Written by Pawan Joshi.Sources cited inline.

First published 15 Jun 2026See site changelog →