How long does staff promotion take from senior?

3-5 years from the day you reach senior, on average. Faster (2-3 years) for engineers in slots that align with the four archetypes — Solver work after a major incident, Tech Lead emergence on a fast-growing team, Right Hand alignment with an executive search. Slower (5-7 years) for engineers in flat orgs or with limited slot availability. Many senior engineers don't reach staff at all; the rate at FAANG hovers around 25-35% of seniors promoting to staff over a 5-year window per Hello Interview's analysis.

Do staff engineers manage people?

Generally no. The IC and management tracks are parallel; staff is the IC equivalent of senior engineering manager. Some staff engineers do informal management (tech-lead-style with a small group); formal direct reports are rare. Engineers who want to manage typically transition to engineering manager rather than staff IC. Reference: Will Larson's 'An Elegant Puzzle' chapter 1 covers the IC vs manager track in depth.

Should I leave my company to make staff?

Sometimes. External staff hiring is more common than external senior+ hiring; companies often have more staff-level openings externally than internal-promotion slots. The trade-off: rebuilding context (~6 months), losing stacked refresher equity, restarting at year-1 vesting. Engineers who've been at senior for 3+ years without internal staff path should evaluate external moves seriously. Engineers in active staff-promotion conversations internally should usually stay through that cycle.

Which staff archetype should I aim for?

The one that matches your existing strengths and your team's needs. Tech Lead is the most common path and the lowest-friction transition from senior. Architect requires strong written communication and patience for cross-team coordination. Solver requires comfort with high-stakes technical work under pressure. Right Hand requires close partnership with an executive (and often emerges from existing relationships rather than a deliberate target). Don't try to force an archetype that doesn't match your team's structural needs.

Is staff really worth it given the comp delta from senior?

Sometimes yes, sometimes no. Senior with 5-10 years of stacked refresher RSU at FAANG can earn comparable total comp to a recent staff promote whose stock hasn't fully vested. The non-comp considerations are real: staff has more strategic involvement, more visibility, more influence on technical direction. But staff also has more political overhead, more meetings, less hands-on coding. Engineers who optimize purely for comp often find senior-and-stay viable; engineers who want broader influence and technical leadership find staff worthwhile.

How do I write RFCs that actually get adopted?

Three patterns from Will Larson and successful staff engineers: (1) start with a clearly-articulated problem the org agrees exists; nobody adopts an RFC for a problem they don't recognize. (2) Engage stakeholders early — share drafts, incorporate feedback, name reviewers in the doc. (3) Make the migration plan explicit and incremental; RFCs that require 'flag day' migrations across the org rarely succeed. Reference: Stripe's published RFC culture (stripe.com/blog), Will Larson's 'An Elegant Puzzle' ch. 3.

Do staff engineers still write code?

Yes, but less than senior, and on different work. Staff engineers code on the highest-leverage problems — system designs they architected, performance issues that nobody else can solve, foundational libraries others build on. The volume is lower; the criticality is higher. Engineers who reach staff and then stop coding entirely tend to lose technical credibility over time; the senior bar of hands-on technical fluency remains important. Reference: Tanya Reilly's 'The Staff Engineer's Path' (chapter 5 covers technical work at staff).

How do staff engineers participate in calibration and promotion decisions?

Heavily. Staff engineers often sit on calibration committees, review promotion packets for senior-and-below engineers, and influence leveling decisions across the org. The work is meaningful — calibration shapes who gets promoted and at what comp band. Engineers reaching staff should expect this responsibility; engineers who avoid it underperform on the social dimension of staff engineering. Reference: Larson's book chapter on 'How to Be Promoted to Staff' covers the calibration role.

Software Engineer Hub

Staff Software Engineer Guide (L6 / IC6) (2026)

By Blake Crosley · Last verified 2026-04-29

In short

Staff SWE (L6 / IC6 / E6) is the first level where the work expands beyond a single feature area or service to a product area, platform-wide system, or org-wide initiative. The four canonical staff archetypes — Tech Lead, Architect, Solver, Right Hand — describe distinct working patterns that all qualify as L6 (Will Larson, staffeng.com). FAANG-tier total comp clusters $560k-$870k including stock vesting (per <a href="https://www.levels.fyi/companies/google/salaries/software-engineer/levels/l6" rel="noopener" target="_blank">levels.fyi/companies/google/salaries/software-engineer/levels/l6</a>). The staff bar is structural: most senior engineers don't reach it, and the gap is usually scope of impact rather than individual capability.

Key takeaways

Staff is rare — most senior SWEs don't promote to staff; the bar is structural rigor of impact and slot scarcity, not just individual readiness (per Hello Interview's leveling analysis).
Will Larson's four staff archetypes (Tech Lead, Architect, Solver, Right Hand) at staffeng.com/guides/staff-archetypes describe distinct work patterns; promotion rate, scope, and visibility differ across them.
FAANG-tier staff total comp: Google L6 $560k-$780k, Meta E6 $640k-$870k, Stripe L4 $560k-$780k per levels.fyi (verified 2026-04-27).
Staff scope is platform-wide or product-area-wide, not feature-level. The structural shift from senior: senior owns a service; staff owns a pattern, a system, or an initiative spanning multiple services.
Many large tech companies use the same external title 'Software Engineer' for IC3 through IC7; staff is internally tracked. Hello Interview's FAANG levels guide details the per-company mapping.
Design docs and RFCs are the load-bearing artifacts at staff. Staff engineers ship influence through writing as much as through code; staff who don't write design docs typically stall.

What staff SWE actually does — by archetype

From Will Larson's StaffEng (staffeng.com/guides/staff-archetypes) and the StaffEng book (staffeng.com/book), the four canonical archetypes:

1. Tech Lead. Most common. Owns technical direction for a team without managing the team. Sets architectural direction, drives the team's technical roadmap, mentors mid and senior engineers, partners with the engineering manager. Real examples Larson cites: Tech Leads on Stripe's Connect team, Pinterest's discovery infrastructure team. The day-to-day: design reviews, mentoring, technical strategy doc writing, occasional senior-bar coding contributions on hard problems.

2. Architect. Owns technical direction across multiple teams or platforms. Doesn't run a single team's technical work; instead, drives standards, patterns, and architectural decisions that cross team boundaries. Real examples: cross-team architects at Meta, Google, Stripe, who own platform-pattern decisions. The day-to-day: cross-team design reviews, RFC authorship, standards setting, mediating disagreements between teams. Less hands-on coding; heavy writing and meetings.

3. Solver. Tackles the org's hardest technical problems — typically incident-bound or migration-bound work that nobody else can drive. Real examples: senior engineers brought in to lead a multi-quarter database migration, a security-incident remediation, a performance-critical rewrite. The day-to-day: deep technical work, intense focus, often time-boxed. Less mentorship; more individual problem-solving.

4. Right Hand. Operates as a technical extension of an engineering executive (VP, CTO, sometimes Director). Strategic involvement in org-level decisions; hands-on for the highest-leverage problems. Real examples: principal engineers reporting directly to a CTO, technical leads embedded in an executive's office. Smaller archetype; high-influence, high-visibility.

What's common across all four:

Work spans multiple teams or sets technical direction beyond a single team's scope.
Influence ships through written artifacts (design docs, RFCs, technical strategy memos) more than through code.
Mentorship of senior engineers, not just mid/junior.
Involvement in hiring decisions, leveling rubrics, technical strategy at the org level.

The structural shift from senior to staff

The single most-common reason senior engineers don't promote to staff: scope. Engineers who execute brilliantly on senior-bar work for years can stall because they don't expand scope beyond the immediate team.

Senior scope: own a feature area or service. Drive technical direction for that area. Coordinate with adjacent teams when needed.

Staff scope: own a platform pattern, an org-wide initiative, a multi-team migration, or a strategic technical direction. Drive technical decisions that affect engineers outside your immediate team.

Concrete examples of senior vs staff scope:

Senior scope	Staff scope
Lead the migration of one team's service to a new framework	Lead the migration of three teams' services; establish the migration pattern others adopt
Improve checkout latency on the consumer flow	Establish company-wide latency-budget standards and the tooling to enforce them
Design and ship a new feature for the team's product	Architect the platform that multiple product teams build features on
Mentor 2-3 mid-level engineers on the team	Mentor 5+ senior engineers across teams; influence promotion decisions in calibration
Write design docs for the team's projects	Author RFCs that establish company-wide engineering patterns

The path from senior to staff isn't 'do senior work better'. It's expanding the surface of impact while maintaining the depth of individual contribution.

RFCs and design docs: the staff artifact

The single most under-appreciated truth about staff engineering: most of the leverage ships through writing, not coding. A well-written RFC that gets adopted across teams has more impact than 5,000 lines of code shipped solo.

Anatomy of a staff-bar RFC (anonymized but real-shape):

# RFC: Standardized Request Tracing Across All Services
## Author: [Name], Staff Engineer, Platform
## Status: Draft → Under Review → Approved → Implemented

## Summary (1 paragraph)
We lack consistent request tracing across our 47 backend services.
Incidents take 30+ minutes to root-cause because traces fragment
at service boundaries. This RFC proposes standardizing on
OpenTelemetry with W3C trace-context propagation, plus an
org-wide deployment plan.

## Background (the why)
- Current state: 12 services use Datadog APM, 18 use Honeycomb,
  17 have no tracing.
- Incident retro analysis: 8 of 11 P0/P1 incidents in Q3 cited
  'tracing gap' as a contributing factor.
- Cost of fragmentation: estimated 200+ engineer-hours/quarter
  on incident triage that better tracing would avoid.

## Proposal
- Adopt OpenTelemetry as the SDK across all services.
- Standardize on W3C trace-context for cross-service propagation.
- Single backend (Honeycomb) for traces; per-team migration plan.
- Migration framework: SDK adoption phase (3 mo), enable-and-verify
  phase (1 mo), legacy decommission (2 mo).

## Trade-offs analyzed
- OTel vs Datadog APM: OTel wins on portability + open standard;
  Datadog wins on first-class integrations. We've negotiated
  Datadog OTel-ingestion to mitigate.
- Single backend vs multi-backend: single wins on operational
  simplicity; multi wins on flexibility. We pick single.
- Per-team opt-in vs org-mandated: org-mandated; opt-in patterns
  fail to converge.

## Migration plan
[Detailed per-quarter plan with team-level milestones.]

## Open questions
- Sampling strategy across services (head vs tail).
- Cost projection for full Honeycomb adoption at our volume.
- Hand-off plan to the Observability team post-migration.

## Reviewers
- Eng Director: [Name] (approved)
- Staff Engineers: [3 names] (approved with comments)
- Observability Team Lead: [Name] (approved)

What makes this a staff-bar artifact:

Cross-team scope (47 services, 3 different vendors).
Quantified cost (200+ engineer-hours/quarter).
Trade-off analysis with explicit alternatives ruled out.
Migration plan with phases and time estimates.
Multiple senior reviewers including Eng Director.
Honest open questions (didn't pretend everything is solved).

Two RFCs of this caliber per year, with adoption visible across the org, is the empirical pattern that gets engineers promoted to staff. One per year is borderline; zero is structurally insufficient.

Staff compensation: cited specifics

From levels.fyi self-reports (verified 2026-04-27):

Company	Level	Base	Total comp range
Google	L6	~$300k	$560k-$780k (levels.fyi/companies/google/salaries/software-engineer/levels/l6)
Meta	E6	~$300k	$640k-$870k
Apple	ICT5	~$280k	$480k-$680k
Stripe	L4	~$280k	$560k-$780k
Airbnb	L6	~$280k	$530k-$760k
Anthropic	MTS L5	~$380k	$700k-$1.1M+
Databricks	L6	~$300k	$580k-$830k

The staff comp dynamic: stock vesting is the dominant component. Base typically $260k-$340k; stock + bonus comprise the rest. At companies with strong stock performance (Meta, Nvidia in recent years), staff total comp can spike materially in a given vesting cycle; at companies with flat or declining stock, the high-end of the range is rarely realized.

External staff hiring is more common than external senior+ hiring at most companies — staff slots are scarce internally, and external candidates with proven cross-team scope at peer companies are attractive. levels.fyi's job-history data shows staff-level external hires receiving 20-30% bumps over internal-promote staff comp.

Staff vs management: the parallel-track question

At most large tech companies, staff IC and senior engineering manager are roughly comp-equivalent. The choice between them is about work, not compensation.

Staff IC work:

Deep technical problems; less people-management overhead.
Influence ships through technical artifacts (RFCs, design docs, code).
Mentorship is part of the job but not the primary surface.
Career growth at staff+ is via scope expansion (staff → senior staff → principal).

Engineering manager work:

People management — hiring, performance reviews, career conversations.
Influence ships through team building and people decisions.
Less hands-on technical work over time; more strategic conversations.
Career growth via management ladder (manager → director → VP).

Charity Majors's 'Engineer/Manager Pendulum' (charity.wtf/2017/05/11) argues most engineers benefit from oscillating between the two over a career. The IC-only staff track is viable; the manager-only path is viable; the pendulum lets engineers transfer skills and avoid local-maximum traps.

Compensation parity: at most FAANG-tier, staff IC and senior engineering manager have roughly equivalent total comp. Some divergence at higher levels: senior staff (L7) and Director are roughly equivalent; principal (L8) and Senior Director / VP have more variation. The wrong basis for choosing track: 'managers earn more' (they don't, at most companies); 'IC earns more' (also wrong). Right basis: which work energizes you over a 5-10 year horizon.

Frequently asked questions

How long does staff promotion take from senior?: 3-5 years from the day you reach senior, on average. Faster (2-3 years) for engineers in slots that align with the four archetypes — Solver work after a major incident, Tech Lead emergence on a fast-growing team, Right Hand alignment with an executive search. Slower (5-7 years) for engineers in flat orgs or with limited slot availability. Many senior engineers don't reach staff at all; the rate at FAANG hovers around 25-35% of seniors promoting to staff over a 5-year window per Hello Interview's analysis.
Do staff engineers manage people?: Generally no. The IC and management tracks are parallel; staff is the IC equivalent of senior engineering manager. Some staff engineers do informal management (tech-lead-style with a small group); formal direct reports are rare. Engineers who want to manage typically transition to engineering manager rather than staff IC. Reference: Will Larson's 'An Elegant Puzzle' chapter 1 covers the IC vs manager track in depth.
Should I leave my company to make staff?: Sometimes. External staff hiring is more common than external senior+ hiring; companies often have more staff-level openings externally than internal-promotion slots. The trade-off: rebuilding context (~6 months), losing stacked refresher equity, restarting at year-1 vesting. Engineers who've been at senior for 3+ years without internal staff path should evaluate external moves seriously. Engineers in active staff-promotion conversations internally should usually stay through that cycle.
Which staff archetype should I aim for?: The one that matches your existing strengths and your team's needs. Tech Lead is the most common path and the lowest-friction transition from senior. Architect requires strong written communication and patience for cross-team coordination. Solver requires comfort with high-stakes technical work under pressure. Right Hand requires close partnership with an executive (and often emerges from existing relationships rather than a deliberate target). Don't try to force an archetype that doesn't match your team's structural needs.
Is staff really worth it given the comp delta from senior?: Sometimes yes, sometimes no. Senior with 5-10 years of stacked refresher RSU at FAANG can earn comparable total comp to a recent staff promote whose stock hasn't fully vested. The non-comp considerations are real: staff has more strategic involvement, more visibility, more influence on technical direction. But staff also has more political overhead, more meetings, less hands-on coding. Engineers who optimize purely for comp often find senior-and-stay viable; engineers who want broader influence and technical leadership find staff worthwhile.
How do I write RFCs that actually get adopted?: Three patterns from Will Larson and successful staff engineers: (1) start with a clearly-articulated problem the org agrees exists; nobody adopts an RFC for a problem they don't recognize. (2) Engage stakeholders early — share drafts, incorporate feedback, name reviewers in the doc. (3) Make the migration plan explicit and incremental; RFCs that require 'flag day' migrations across the org rarely succeed. Reference: Stripe's published RFC culture (stripe.com/blog), Will Larson's 'An Elegant Puzzle' ch. 3.
Do staff engineers still write code?: Yes, but less than senior, and on different work. Staff engineers code on the highest-leverage problems — system designs they architected, performance issues that nobody else can solve, foundational libraries others build on. The volume is lower; the criticality is higher. Engineers who reach staff and then stop coding entirely tend to lose technical credibility over time; the senior bar of hands-on technical fluency remains important. Reference: Tanya Reilly's 'The Staff Engineer's Path' (chapter 5 covers technical work at staff).
How do staff engineers participate in calibration and promotion decisions?: Heavily. Staff engineers often sit on calibration committees, review promotion packets for senior-and-below engineers, and influence leveling decisions across the org. The work is meaningful — calibration shapes who gets promoted and at what comp band. Engineers reaching staff should expect this responsibility; engineers who avoid it underperform on the social dimension of staff engineering. Reference: Larson's book chapter on 'How to Be Promoted to Staff' covers the calibration role.

Sources

About the author. Blake Crosley founded ResumeGeni and writes about product design, hiring technology, and ATS optimization. More writing at blakecrosley.com.