From Senior to Staff Engineer

By Michael Samuel Naeem · December 28, 2025 · 5 min read

The promotion conversation stalled with "you're a strong senior" — which usually means you're executing well inside one team's boundary, and the calibration committee cannot point to org-level impact on the rubric. Staff engineer is not senior-plus-years; it is a scope change from "ships hard features reliably" to "changes how multiple teams ship." That shift confuses high performers who keep taking the hardest JIRA tickets while someone else writes the RFC that retires three microservices. Understanding what staff actually means — and building evidence for it deliberately — beats waiting for a manager to notice.

How scope changes

Staff work often looks like documentation, alignment meetings, and unglamorous migrations — not the flashiest feature launch.

Finding staff-level problems

Look for:

• Recurring incidents spanning team ownership boundaries
• Platform gaps causing every product team to rebuild the same wheel
• Strategy voids — no clear answer on mobile offline sync, observability standard, or data retention
• Execution traps — everyone agrees what to build; nobody can sequence dependencies

Volunteer to write the one-pager that names the problem, lists options, and recommends a path. Staff promotions often follow the person who made the ambiguous tractable.

Influence without authority

Staff engineers lead through:

1. Written clarity — RFCs, ADRs, runbooks that survive your vacation
2. Working prototypes — spike that proves latency budget is achievable beats theoretical debate
3. Sponsorship — connect junior engineers to visible work; credit flows outward
4. Executive translation — explain technical debt in revenue/risk terms leadership acts on

Avoid the failure mode of staff-as-gatekeeper: blocking teams pending your review without enabling them to succeed independently.

Promotion packet structure

What calibration committees need:

## Initiative: Unified observability schema
**Problem:** Three teams, incompatible metrics; MTTR averaged 90 min on cross-service incidents.
**Role:** DRI for RFC, pilot with payments team, rollout playbook.
**Outcome:** P95 incident triage down to 35 min; 4 teams adopted; on-call toil tickets -40% QoQ.
**Evidence:** Grafana dashboard links, incident retros, EM + PM peer feedback.

Quantify where honest. Qualitative impact from credible peers fills gaps metrics miss.

Collect feedback proactively after cross-team projects — calibration may not allow managers to solicit at the last minute.

Common stalls and fixes

Staff is not the only success path

Principal, architect, EM, or expert senior on a high-leverage team are valid careers. Staff adds meetings and ambiguity. If joy comes from deep individual craft, principal/deep IC tracks at some companies fit better — know your company's ladder names.

The transition is intentional: choose cross-cutting problems, make your influence legible on paper, and measure yourself by how many engineers ship better because of work you did not personally commit.

Building a staff promotion packet

Staff promotion requires evidence of cross-team impact, not just strong execution:

Technical leadership evidence:

• RFC or design doc that changed how 3+ teams build (link to doc, list teams affected)
• System you designed that others operate without your involvement
• Incident you led that prevented recurrence org-wide

Influence evidence:

• Engineers who cite your design review feedback as improving their work
• Cross-team project you drove to completion without formal authority
• Internal talk or blog post referenced by other teams

Scope evidence:

• Problem space spanning 2+ teams or product areas
• Decision you made that affected roadmap beyond your squad
• Metric improvement attributable to your technical direction

## Promotion packet: [Name] → Staff Engineer

### Scope
Led migration of 4 teams to event-driven architecture, reducing 
cross-service coupling incidents by 60% over 6 months.

### Technical leadership
- Auth RFC adopted by Platform, Payments, and Identity teams
- Designed outbox pattern now standard for all new services

### Influence
- 12 engineers across 3 teams implemented pattern without my direct involvement
- Design review feedback cited in 8 PR descriptions this quarter

Staff vs principal vs architect

Titles vary by company — understand your ladder:

Staff is the first level where your job is primarily enabling others — not writing the most code.

The staff engineer's weekly rhythm

A sustainable staff week balances depth and breadth:

• 40% — Design reviews, RFC feedback, architecture discussions
• 30% — Hands-on work on highest-leverage technical problem
• 20% — Cross-team coordination, stakeholder communication
• 10% — Mentoring, internal talks, documentation

If you're spending >60% on hands-on coding, you're operating as a senior. If >60% on meetings, you're operating as a manager without the title.

Failure modes

• Strong executor, no cross-team scope — "best senior on the team" not staff
• Influence without documentation — impact invisible to calibration committee
• Waiting to be asked — staff engineers identify and claim problems proactively
• Avoiding ambiguity — staff work is inherently ambiguous; comfort with uncertainty required
• Promotion packet written at review time — collect evidence throughout the year

Production checklist

• Cross-team problem identified and sponsored by EM/director
• RFC or design doc with adoption beyond your team
• Promotion packet updated quarterly with new evidence
• Internal visibility: talks, blog posts, design review participation
• Mentoring relationship with 2+ engineers outside your team
• Metric or outcome attributable to your technical direction

Resources

• Staff Engineer book (Will Larson)
• StaffEng Guides — stories from staff+ engineers
• Engineering levels at Carta (example ladder)
• Lethain on reaching staff engineer
• Building a promotion packet (Charity Majors)