Staff engineer scope
A senior IC level whose scope spans teams: sets technical direction, de-risks big bets, and multiplies others, mostly through writing and influence.
A staff engineer is a senior individual contributor (not a manager) whose impact reaches beyond their own team. They pick and shape the hard technical problems, write the design docs others build from, spot risks early, and help other engineers grow. In interviews, staff-level answers are judged less on whether you can build the thing and more on whether you can decide what should be built, across teams, and get it adopted.
A senior architect on a building project: they don't lay every brick, but they decide where the load-bearing walls go and make sure every crew builds to the same plan.
Equating staff with 'the best coder on the team'. At staff level, the measure is whether multiple teams make better decisions because of you; heroic individual delivery without that reach is a senior profile.
Will Larson's Staff Engineer (2021) describes four archetypes: Tech Lead (guides one team's execution), Architect (owns direction for a critical area), Solver (parachutes into the hardest problems), and Right Hand (extends an executive's reach). Common work across them: setting technical direction (strategy docs, ADRs), reviewing and shaping designs across teams, sponsoring and mentoring, and doing 'glue work' that no team owns. In an AI org, staff-level problems look like: one LLM gateway and eval harness shared by eight teams instead of eight, a model-migration plan with shadow, canary and rollback across products, a cost model that tells finance what 10× traffic will cost, and the security posture for agents (trifecta reviews, least-privilege tooling). Staff interviews probe scope (how many teams), ambiguity (who defined the problem), influence without authority (who disagreed and how they were persuaded), and judgement (trade-offs with numbers and reversibility). The common gap: describing excellent execution inside one team, which reads as senior, not staff.
In interviews: open with org scope (teams, owners), then build vs buy, rollout plan across teams, success metrics with numbers, risks and how you'd de-risk them, and what you personally do. On the job: written strategy and ADRs, a small number of cross-team bets, sponsorship of 2–4 engineers.
Staff-level framing of 'build a RAG assistant for support': 'Three product teams are each building retrieval. I'd propose one ingestion and retrieval platform with per-team configs, a shared golden-set harness, and an LLM gateway with per-tenant quotas. Build vs buy: buy the vector DB and observability, build the eval harness because our quality definition is domain-specific. Rollout: platform team of 4 for one quarter, migrate the team with the worst recall first as proof, then the other two. Success: recall@10 ≥0.85 on each team's golden set, cost per resolved ticket down 30%, and two of three teams migrated in two quarters. Biggest risk: teams resisting migration, so I'd co-own their first migration.'
Staff answers start from the org problem, not the component: who owns it, which teams are affected, build vs buy, how it rolls out, how success is measured, and what you'd do personally vs delegate. Expect: 'a senior team lead disagrees with your platform proposal — what do you do?' Answer with data (cost and quality per team), a pilot that de-risks their concern, and a decision record, not authority.
Numbers worth knowing
- Teams influenced
- typically 2+ teamsstaff scope; principal is usually org-wide
- Interview answer structure
- ~5 min scope, 25 min design, 10 min rollout/risks45-minute staff system-design round
- Concurrent cross-team bets
- 1–3more and none get finished
How to decide
| When | Do this |
|---|---|
| Several teams solving the same problem | Propose a shared platform with a pilot team, not a mandate. |
| Problem is undefined | Write the problem statement and success metrics first; get owners to agree. |
| A peer disagrees | Pilot to test their concern, decide with data, record the decision. |
| Asked a component-level design question in a staff loop | Answer it, then zoom out to ownership, rollout and org cost. |
Operating it
- Your design decisions are adopted by teams you don't sit in
- You spend more time writing direction and reviewing than coding, and teams move faster as a result
- Interview feedback says 'strong execution, limited scope': practise org-level framing
- In a role: count of decisions adopted outside your team per half
- Sponsored engineers promoted or leading projects
- Interview practice: every design answer covers ownership, build vs buy, rollout and metrics
When it goes wrong
A staff candidate with deep LLM-serving expertise was down-levelled to senior.
Debrief: excellent design for one service, but no mention of ownership, rollout across teams or cost to the org.
Answers stayed at component depth; the candidate never framed who would own the platform, build vs buy, or how other teams would adopt it.
Practised opening each design with scope and owners, closing with rollout and success metrics; prepared STAR stories with cross-team influence. Next loop: staff offer.
Where it shows up
Sources
- Staff Engineer: Leadership beyond the management track — Will Larson, 2021book
- Staff archetypes — Will Larson, StaffEng, 2020blog
- An Elegant Puzzle: Systems of Engineering Management — Will Larson, 2019book
Check yourself
Three questions. Every option is explained once you answer.