Understanding Career Levels in Tech - From Entry to Distinguished Engineer

Career level systems differ enough between companies that titles stop being comparable. A Senior at Amazon is an L6 and a Senior at Google is an L5, and a Staff title at a 40-person startup rarely carries the scope a Staff title carries at Meta. The reliable comparison unit is scope, autonomy, and impact; the number and the label are only how each company records the result. Misreading your equivalent level has a price: you accept a lower band in a new role, or you spend a year building a promotion case for the wrong kind of work.

Mapping Amazon, Google, Meta, Microsoft, Spotify, and Zalando onto that common frame also settles the decisions that follow: whether to push for Staff or treat Senior as a destination, when the IC versus management fork actually arrives, and how to find Staff-level scope on a team that only has feature work.

How Major Companies Structure Levels

The Standard Framework

Most large tech companies use 5-7 levels for individual contributors, though they name and number them differently. Here’s how the major companies map to each other:

Level Names by Company:

Level	Amazon	Google	Meta	Microsoft
Entry	L4	L3	E3	59-60
Mid-Level	L5	L4	E4	61-62
Senior	L6	L5	E5	63-64
Staff	L7	L6	E6	65-67
Sr Staff	L8	L7	E7	68-69
Principal	L10*	L8	E8	70+

*Amazon skips L9

Level Equivalency Table

Experience	Amazon	Google	Meta	Microsoft	Typical Years
Entry	L4 (SDE I)	L3 (SWE II)	E3 (SWE II)	59-60 (SDE I)	0-2 years
Mid-Level	L5 (SDE II)	L4 (SWE III)	E4 (SWE III)	61-62 (SDE II)	2-5 years
Senior	L6 (Senior)	L5 (Senior)	E5 (Senior)	63-64 (Senior)	5-8 years
Staff	L7 (Principal)	L6 (Staff)	E6 (Staff)	65-67 (Principal)	8-12 years
Sr Staff	L8 (Sr Principal)	L7 (Sr Staff)	E7 (Sr Staff)	68-69 (Partner)	12-15 years
Principal	L10 (Distinguished)*	L8 (Principal)	E8 (Principal)	70+ (Distinguished)	15+ years
Distinguished	-	L9 (Distinguished)	E9 (Distinguished)	-	20+ years
Fellow	-	L10 (Google Fellow)	E10 (Fellow)**	-	Rare
Sr Fellow	-	L11 (Sr Google Fellow)	-	-	Extremely Rare

*Amazon deliberately skips L9, progressing L4→L5→L6→L7→L8→L10

**Meta E10 is exceptionally rare

Important Note: These mappings are approximations. Companies calibrate differently, and your actual level depends on demonstrated scope and impact during interviews, not just your current title.

Spotify’s Alternative: Steps Framework

Spotify takes a different approach with their “Steps” framework, focusing on impact rather than hierarchical levels:

1. Individual Step: Impact within your immediate team
2. Squad/Chapter Step: Impact across multiple squads or technical domains
3. Tribe/Guild Step: Impact across larger organizational units
4. Technology/Company Step: Impact across the entire company or industry

The key difference: Steps remain private, and compensation bands can overlap between steps. This reduces title obsession and focuses on actual contribution. An engineer at Squad Step might earn more than someone at Tribe Step if their impact justifies it.

What Each Level Actually Means

A level number tells you where an engineer sits on a ladder. What follows is what each rung demands in scope, autonomy, and impact.

Entry Level (L4/E3/L3)

Scope: Individual components within a single service or feature area.

Autonomy: You receive detailed specifications and work with close mentorship. Your tech lead or senior engineer reviews your approach before you start implementing.

Impact: Your work affects a single feature or component, impacting your immediate team.

Example Task: “Fix the pagination bug in the user dashboard where the page counter displays incorrectly when filtering results.”

You’re given the bug report, existing code context, and often specific guidance on where to look. Your focus is executing well-defined tasks and learning the codebase.

Mid-Level (L5/E4/L4)

Scope: Complete features spanning frontend and backend, sometimes touching multiple services.

Autonomy: You create technical specifications independently and collaborate with PM/design without constant oversight. You make implementation decisions within your feature area.

Impact: Cross-functional features affecting multiple teams. Other engineers depend on your APIs or components.

Example Task: “Build the notification preferences system allowing users to customize what alerts they receive and through which channels.”

You work with product to understand requirements, design the API, implement both frontend and backend, and coordinate with the notifications service team. You make decisions about data models, API design, and error handling.

Senior Level (L6/E5/L5)

Scope: System-wide improvements affecting multiple services and teams. Technical debt reduction, reliability improvements, or architectural changes.

Autonomy: You define problem spaces, propose solutions, and drive implementation with minimal direction. You set technical standards for your area.

Impact: Organizational impact affecting all engineering teams. Your decisions influence how other engineers build systems.

Leadership: You mentor 2-3 engineers and participate in hiring. You review designs from other teams and provide architectural guidance.

Example Task: “Improve service reliability from 99.5% to 99.9% uptime.”

You analyze the current system, identify failure modes, propose monitoring improvements, implement circuit breakers, set up alerting, and coordinate with multiple teams to deploy changes. You define what “done” looks like and measure success.

Staff Level (L7/E6/L6)

Scope: Cross-organizational technical initiatives spanning multiple teams and quarters.

Autonomy: You set technical direction for large initiatives. No one gives you specifications - you define what needs to be built.

Impact: Company-wide infrastructure affecting 50+ engineers. Your architectural decisions enable or constrain what the organization can build.

Leadership: Technical lead for multiple teams. You establish technical standards and best practices. You influence hiring strategy and team structure.

Example Task: “Design and implement the multi-region data replication strategy to support global expansion.”

You evaluate options (active-active vs active-passive, consistency requirements, conflict resolution), create an RFC, build consensus across infrastructure and product teams, coordinate implementation across 5+ teams over 2-3 quarters, and ensure successful rollout.

Principal and Beyond (L8+/E7+/L7+)

Scope: Multi-year strategic technical direction affecting the entire company’s architecture.

Autonomy: Complete independence. You set organizational priorities and influence product roadmaps based on technical constraints and opportunities.

Impact: Industry-level influence. Your decisions affect 500+ engineers and possibly external communities through open source or standards work.

Leadership: Technical vision for the organization. External thought leadership through conferences, papers, or open source contributions.

Example Task: “Define the company’s transition from monolith to microservices architecture.”

You analyze the current monolith, identify boundaries for service extraction, create migration strategy, build consensus with executive leadership, coordinate implementation across the entire engineering organization over 2-3 years, and establish patterns that become company standards.

Understanding Terminal Levels

Most companies design specific levels where an engineer is expected to stay for the rest of their career. These are called “terminal levels.”

• Google: L5 (Senior) is terminal; below it, promotion is expected
• Meta: E5 (Senior) is the “core level” everyone must reach
• Amazon: L6 (Senior SDE) is where most engineers plateau

At Google, many engineers spend a decade or more at L5 and have successful, impactful careers. The ladder is built to accommodate exactly that. Meta treats E5 as the level everyone is expected to reach, and comparatively few engineers go past it.

Staying at Senior your entire career is a perfectly valid and successful path. The industry needs far more excellent Senior engineers than it needs Staff engineers. A team of strong Seniors can accomplish more than a team with one Staff engineer and mediocre Seniors.

The pressure to “level up or you’re stagnating” is usually self-imposed, or it comes from misreading how these systems work. Recognize what you want from your career: deep technical expertise at Senior level can be more fulfilling than cross-organizational politics at Staff level.

Promotion Expectations and Timeline

The Lagging Indicator Principle

All major tech companies promote on demonstrated performance, not potential. You must already be operating at the next level for 6-12 months before the promotion arrives. A promotion is a receipt for work you have already delivered.

This means if you want to be promoted to Senior, you need to start taking on Senior-level scope and demonstrating Senior-level impact now, then sustain it long enough for the promotion cycle to recognize it.

Typical Promotion Timelines

L4 → L5 (Entry to Mid-Level)

• Amazon: 9 months to 2 years for high performers
• Google: Average 2+ years
• Key shift: From needing guidance to working independently

L5 → L6 (Mid to Senior)

• Amazon: 2-4 years typical
• Google: Average 3+ years
• Key shift: From executing to leading. Many engineers describe this as the hardest mental transition.

L6 → L7 (Senior to Staff)

• Amazon: External L7 hiring often easier than internal L6 → L7 promotion
• Google: Average 4+ years, requires demonstrable Staff-level scope
• Key shift: From reactive problem-solving to proactive problem-finding

Each transition takes longer than the one before it, by design: the scope and impact bar rises faster at each step than it did at the last.

Finding Staff-Level Scope

The most common complaint from Senior engineers pursuing Staff: “My team doesn’t have Staff-level work.”

Staff engineers do not wait for scope to be assigned. They find it, or they create it.

What Qualifies as Staff-Level Scope

Three characteristics define Staff-level work:

1. Complexity: Problems that Senior engineers cannot solve individually
2. Impact: Affects multiple teams or organizations
3. Timeline: Multi-quarter roadmap involving many engineers

Practical Strategies

If your immediate team lacks cross-organizational projects:

Look for organization-wide technical problems:

• Build system improvements affecting all engineers
• Observability infrastructure serving multiple teams
• API standardization across services
• Developer productivity tooling
• Migration projects (databases, cloud platforms, frameworks)

Partner with platform/infrastructure teams:

Even if you work on product features, infrastructure teams often have cross-cutting initiatives that need domain expertise. Volunteer to drive the adoption of new infrastructure in your product area, and coordinate with other product teams.

Lead technical initiatives in guilds or working groups:

Many companies have guilds (Spotify) or working groups for specific technical domains. Leading initiatives here - like establishing GraphQL standards or security best practices - creates Staff-level scope.

Common Staff-Level Projects:

These projects are consistently recognized as Staff-level scope:

• Migration projects: Moving from REST to GraphQL across 20 services
• Developer productivity: Reducing CI/CD pipeline time from 45 minutes to 10 minutes
• System reliability: Implementing distributed tracing and SLO monitoring
• Technical standards: Creating API design guidelines adopted by 50+ engineers
• Cross-team debt reduction: Coordinating deprecation of legacy authentication system

Staff Engineer Archetypes

Not all Staff engineers do the same type of work. Will Larson’s StaffEng interviews name four archetypes that recur across companies:

Tech Lead

Scope: Guides 1-2 teams through approach and execution of complex projects

Prevalence: The most common Staff archetype

Example: Leading the checkout team’s technical roadmap, making architectural decisions, reviewing designs, and ensuring engineering quality

This is the most accessible Staff path because the scope exists within product teams.

Architect

Scope: Owns specific technical domain across the entire company (API design, data storage, infrastructure patterns)

Prevalence: Emerges in companies with complex, mature codebases

Example: Chief architect for the company’s GraphQL API strategy, establishing patterns, reviewing implementations, and maintaining consistency across 50+ services

Solver

Scope: Parachuted into high-priority, complex problems that need senior attention

Prevalence: More common in companies valuing individual ownership (like Amazon)

Example: Brought in to fix critical performance bottleneck affecting revenue, investigates root cause, proposes solution, coordinates implementation

Right Hand

Scope: Extends executive capacity across large organizations (CTO’s technical partner)

Prevalence: Rare - only makes sense in companies with hundreds of engineers

Example: Executing company-wide initiatives on behalf of CTO, representing technical perspective in executive decisions

Understanding these archetypes helps you identify which Staff path aligns with your strengths and interests.

The IC vs Management Decision

Around Senior level (L6/E5), engineers face a common decision point: continue as an individual contributor on the Staff track, or transition to engineering management?

The Core Difference

Staff Engineer (IC Track):

• Primary focus: Technology and technical systems
• Day-to-day: Deep technical work, architecture design, code reviews, technical guidance
• Leverage: Scale through technology and influence
• Meeting load: High at Staff+ level, but mostly technical discussions
• Career control: High - your growth ties directly to your technical execution

Engineering Manager (EM Track):

• Primary focus: People and organizational health
• Day-to-day: 1:1s, hiring, performance reviews, team planning, career development
• Leverage: Scale through people and delegation
• Meeting load: Very high with calendar fragmentation
• Career control: Lower - your growth depends on team growth opportunities

Compensation Reality

At well-structured tech companies, Staff Engineer and Engineering Manager sit at the same level with identical compensation bands. This is a lateral move, not a promotion.

If someone tells you “become a manager to advance your career,” that’s a red flag about their engineering ladder design.

Making the Decision

The choice usually comes down to where you want your attention to go:

• Love solving deep technical problems → IC track
• Love helping people grow and succeed → Management track
• Unsure → Try Tech Lead role first (hybrid responsibilities)
• Remember: The decision is reversible

Many engineers switch between tracks multiple times in their career. People go from Staff → EM → Sr Staff → Director → Principal Engineer. Companies that support this flexibility retain stronger talent.

Prerequisites for Management

Some companies gate the move into management behind a seniority bar, usually Senior or above. The logic: a manager needs enough technical judgment to evaluate the team’s decisions and mentor engineers credibly.

Management Track Level Equivalencies

While IC levels get most of the attention, the management track has its own hierarchy that maps across companies. Understanding this helps if you’re considering management or want to know where your manager sits in the broader landscape.

Management Levels Across Companies

Management Titles by Company:

Level	Amazon	Google	Meta	Microsoft
Manager	M1	M1	M1	M1
Sr Manager	M2	M2	M2	Principal Mgr
Director	Director	Director	Director	Director
Sr Director	Sr Director	Sr Director	Sr Director	Partner
VP	VP	VP	VP	VP/CVP
SVP	SVP	SVP	SVP	EVP

Management Level Equivalency Table

Level	Amazon	Google	Meta	Microsoft	IC Equivalent	Typical Scope
Manager	M1 (L6)	M1 (L6)	M1 (E6)	M1 (65-67)	Staff	5-10 engineers
Sr Manager	M2 (L7)	M2 (L7)	M2 (E7)	M2 (68-69)	Sr Staff	15-30 engineers
Director	Director (L8)	Director (L8)	Director (E8)	Director (70+)	Principal	30-80 engineers
Sr Director	Sr Director	Sr Director	Sr Director	Partner	Distinguished	80-200 engineers
VP	VP	VP	VP	VP/CVP	Fellow	200-1000+ engineers
SVP	SVP	SVP	SVP	EVP	-	Organization-wide

Key Insight: At each level, the IC and management tracks are designed to be equivalent in terms of compensation and organizational influence. An L7 Principal Engineer at Amazon has similar impact expectations to an M2 Sr Manager - they just achieve that impact through different means.

The Scope Progression

Engineering Manager (M1):

• Manages a single team of 5-10 engineers
• Responsible for team execution and individual career growth
• First-line people management with some technical involvement
• IC equivalent: Staff Engineer leading technical direction for the same team

Senior Manager (M2):

• Manages multiple teams or a larger team of 15-30 engineers
• Owns a product area or technical domain
• Coordinates across teams for larger initiatives
• IC equivalent: Senior Staff Engineer with cross-team technical influence

Director:

• Manages managers (2-4 direct report managers)
• Owns organizational strategy for 30-80 engineers
• Drives multi-quarter roadmaps and organizational health
• IC equivalent: Principal Engineer setting technical direction across multiple teams

Senior Director:

• Manages directors and large organizations (80-200 engineers)
• Sets organizational vision and long-term strategy
• Partners with executive leadership on company priorities
• IC equivalent: Distinguished Engineer with company-wide technical influence

VP of Engineering:

• Owns an entire engineering organization (200-1000+ engineers)
• Executive team member influencing company direction
• Responsible for engineering culture, hiring strategy, and technical excellence
• IC equivalent: Fellow-level engineers (very rare at this level)

When Management Levels Emerge

Not all companies need every management level. Here’s when each level typically becomes necessary:

Level	Company Size	Why It Emerges
Engineering Manager	15+ engineers	First teams need dedicated people leadership
Senior Manager	50+ engineers	Multiple teams need coordination
Director	100+ engineers	Managers need management and organizational strategy
Senior Director	300+ engineers	Complex organizational structures need senior leadership
VP	500+ engineers	Executive representation for engineering
SVP	2000+ engineers	Multiple VPs need coordination

When to Create Staff and Principal Positions

One of the most common questions from engineering leaders: “When should we create Staff/Principal positions at our company?”

Creating these roles too early wastes budget and creates title inflation. Creating them too late causes retention problems as senior engineers leave for companies with growth paths.

Signals You Need Staff Engineers

Organizational signals:

• Cross-team technical debt is accumulating with no owner
• Technical decisions are inconsistent across teams
• Senior engineers are leaving for “Staff” titles elsewhere
• Complex technical initiatives lack clear technical leadership
• Architecture discussions happen in silos without coordination

Size signals:

• 30-50+ engineers typically creates enough cross-team complexity
• 3-5+ engineering teams need technical coordination
• Multiple product areas need architectural consistency

Project signals:

• Multi-quarter technical initiatives spanning multiple teams
• Infrastructure or platform work serving multiple product teams
• Technical standards needed across the organization

The Staff Engineer Threshold

Recommended ratios:

• Small companies (30-100 engineers): 1 Staff per 15-25 engineers
• Medium companies (100-500 engineers): 1 Staff per 10-15 engineers
• Large companies (500+ engineers): 1 Staff per 8-12 engineers

Signals You Need Principal Engineers

Principal engineers emerge when Staff engineers aren’t senior enough to own certain problems:

Organizational signals:

• Multi-year technical strategies lack ownership
• Architecture decisions affect the entire company
• External technical representation is needed (standards bodies, open source)
• Technical due diligence for acquisitions or major partnerships
• Staff engineers need mentorship and calibration

Size signals:

• 200+ engineers typically creates Principal-level scope
• 10+ engineering teams needing architectural coordination
• Multiple business units with shared technical infrastructure

Project signals:

• Company-wide platform migrations (monolith to microservices)
• Multi-year infrastructure investments
• Technical strategies affecting product roadmaps

The Principal Engineer Threshold

Most companies under 200 engineers don’t need Principal engineers. Here’s a framework:

Company Size	Staff Engineers	Principal Engineers	Distinguished
30-100	1-3	0	0
100-300	4-10	0-1	0
300-1000	15-40	2-5	0-1
1000+	50+	10+	1-3

Common Mistakes

Creating roles too early:

• Hiring a Principal Engineer at a 50-person startup where there’s no Principal-level scope
• The engineer gets bored or creates unnecessary complexity

Creating roles too late:

• Losing Senior engineers who want growth but see no path
• Accumulating technical debt because no one owns cross-team problems

Not defining scope clearly:

• Staff title without Staff-level expectations leads to confusion
• Engineers wonder why someone is “Staff” when they do the same work as Seniors

One-size-fits-all approach:

• Applying FAANG ratios to a startup context
• Creating Distinguished Engineer role at a 200-person company

The Right Approach

1. Define the scope first: What cross-organizational problems need ownership?
2. Check if the scope exists: Is there actually multi-team, multi-quarter work?
3. Consider alternatives: Can a Senior engineer take this on with expanded scope?
4. Create the role when needed: Don’t preemptively create levels
5. Review annually: As the organization grows, reassess the ladder

The goal is a ladder that matches your own organizational complexity and gives engineers meaningful growth. FAANG’s structure is only a reference point.

Company Size Considerations

Career ladders that work at Google (150,000+ employees) don’t make sense at a 50-person startup.

Small Companies (Under 200 Engineers)

Recommended levels: 3-4 levels total

• Junior/Mid-Level Engineer
• Senior Engineer
• Staff Engineer (rare - maybe 1-2 people)
• CTO/VP Engineering

Why: You don’t have organizational complexity to justify 8 levels. Focus on clear progression without artificial subdivisions.

Mid-Size Companies (200-1000 Engineers)

Recommended levels: 5-6 levels

• Entry (L3/L4 equivalent)
• Mid-Level (L5 equivalent)
• Senior (L6 equivalent)
• Staff (L7 equivalent)
• Principal (L8 equivalent)
• CTO/VP/Distinguished

Why: Organizational complexity emerges. Multiple teams need coordination. Cross-organizational scope exists for Staff+ engineers.

Large Companies (1000+ Engineers)

Recommended levels: 7-8 levels

Full ladder similar to FAANG companies makes sense here. You have enough organizational complexity for Distinguished Engineer and Fellow roles.

Don’t Copy-Paste FAANG Ladders

The biggest common mistake: startups adopting Google’s L3-L10 system when they have 30 engineers. Levels should match organizational complexity. Add levels as you grow, don’t create them preemptively.

European vs US Tech Companies

Compensation Differences

The compensation gap between US and European tech roles is significant:

US Tech Hubs - FAANG/Top-tier (Senior Engineer level):

• San Francisco/Seattle: $350K - $500K total comp at top companies
• Significant equity component (40-60% of total comp)
• Note: Average US Senior comp is lower outside FAANG/top-tier companies

European Tech Hubs (Senior Engineer level):

• London: £125K - £150K (~$160K - $190K)
• Berlin: €90K - €120K (~$95K - $130K)
• Amsterdam: €85K - €110K (~$90K - $115K)

European companies typically offer:

• Lower base salaries (30-40% less than US)
• Smaller equity grants at the same level
• Stronger benefits mandated by law (healthcare, pension, vacation)

European Company Examples: Zalando

Zalando, Europe’s largest fashion platform, uses C (Contributor) and SC (Senior Contributor) levels:

• C4-C6: €62K - €78K (Mid-level engineers)
• C7: ~€100K (Engineering Manager entry level)
• SC1: €135K - €175K (Senior/Staff equivalent)

Comparing to FAANG levels:

• Zalando C6 ≈ Amazon L5 (in scope, not compensation)
• Zalando SC1 ≈ Amazon L6/Google L5 (Senior level)

European companies compete on different dimensions:

• Work-life balance (30+ days vacation standard)
• Job security and labor protections
• City quality of life and cost of living
• Less intense performance culture

Building Your Promotion Portfolio

When promotion time comes, you need evidence of your impact in a form a review committee can read quickly.

Document Structure

Create a 10-15 page document with 3-4 major case studies demonstrating scope expansion:

For each case study:

1. Problem context: What technical problem existed, why it mattered
2. Your role: What specific scope you owned, who you collaborated with
3. Technical solution: Architecture, key decisions, trade-offs
4. Measurable impact: Quantified outcomes (latency improvement, cost reduction, reliability gains)
5. Leadership aspects: Mentorship, cross-team influence, technical standards

Quantifying Impact

Use concrete metrics:

• “Reduced API latency from 450ms p95 to 120ms p95”
• “Decreased deployment time from 45 minutes to 12 minutes, enabling 3x more deployments per day”
• “Improved service uptime from 99.5% to 99.9%, eliminating $200K annual revenue loss”
• “Mentored 3 engineers, 2 promoted to Senior within 18 months”

Avoid vague claims:

• “Made the system faster” → How much faster?
• “Improved reliability” → What specific metrics improved?
• “Led the team” → What decisions did you make? What outcomes resulted?

Gathering Peer Testimonials

Reach out to engineers on different teams you’ve collaborated with:

• Staff engineers you’ve partnered with on cross-team initiatives
• Engineers you’ve mentored
• Product managers you’ve worked closely with
• Engineers on other teams who adopted your technical standards

Ask them to speak to specific impact: “Can you share how the observability improvements affected your team’s incident response time?”

Self-Advocacy

Document your wins throughout the year, don’t scramble during promotion cycles:

• Keep a “wins” document updated monthly
• Share project outcomes in team meetings
• Present technical work at engineering all-hands
• Write technical blog posts or documentation
• Give internal tech talks

Self-advocacy isn’t bragging. Promotion committees need data to support decisions. If they don’t know about your impact, they can’t help you.

Common Career Pitfalls

Individual Mistakes

Waiting for scope to be assigned

Many Senior engineers say “my team doesn’t have Staff-level work” and wait. Staff engineers create scope - they identify cross-organizational problems and drive solutions.

Optimizing for title instead of growth

Jumping to another company for a Staff title without actual Staff-level scope leads to performance issues. Ensure the role has real cross-organizational work.

Not building visibility

Great work that nobody knows about doesn’t lead to promotion. Share your wins through tech talks, documentation, demos, and design docs.

Ignoring business context

Pursuing technically interesting but low-impact work won’t get you promoted. Promotion committees weigh business impact above technical complexity.

Organizational Mistakes

Too many levels

Companies with 10+ levels make progression feel like checking boxes. Each promotion feels meaningless. 5-7 levels works for most organizations.

Copy-pasting FAANG ladders

Small companies adopting Google’s 8-level system creates artificial complexity. Scale your ladder to your organizational size.

Promoting on potential

Promoting engineers based on what they might do (rather than what they’ve demonstrated) leads to performance problems. Use “lagging indicator” promotion - promote only when they’ve already been operating at the next level.

Using framework as checklist

When engineers say “I did all 10 items, where’s my promotion?” your framework has become a scorecard instead of a conversation guide. Levels should focus on scope and impact, not checkbox completion.

Limits of the Mapping

Scope, autonomy, and impact are the comparison unit, and the tables above are a translation layer on top of them. That translation is dependable inside companies large enough to calibrate a ladder, where levels.fyi and progression.fyi give you a defensible starting number for a negotiation or a promotion case. It breaks in two places. Below roughly 200 engineers, titles track hiring pressure more than calibration, so a Staff offer from a 60-person company deserves to be judged on the scope written into the job description alone. And frameworks that deliberately decouple title from pay, like Spotify’s Steps or Zalando’s C/SC bands, tell you about responsibility and almost nothing about compensation.

The one habit worth starting this week: write down the scope you owned this quarter while the trade-offs are still fresh. Promotion committees decide on evidence of work already delivered at the next level, and that evidence is hard to reconstruct a year later.

References

• Levels.fyi Standard SWE Level Framework - Community-aggregated level definitions compiled from hundreds of companies, and the source of the cross-company mapping used in the tables above.
• Levels.fyi Salary and Career Data - Crowdsourced compensation data by company, level, and location; the benchmark set behind the US and European salary ranges.
• progression.fyi - Open Source Career Frameworks - A collection of publicly published engineering career ladders, useful for comparing how companies define each level.
• StaffEng: Staff Engineer Archetypes - Will Larson’s four Staff archetypes (Tech Lead, Architect, Solver, Right Hand), with interviews describing how each one operates day to day.
• DORA Accelerate State of DevOps Report 2024 - Annual research on what separates high-performing engineering organizations, including the cross-team practices Staff-and-above engineers are usually asked to drive.
• What Is Psychological Safety? - Harvard Business Review - Amy Edmondson on the conditions that let teams take risks and speak up, a core part of the leadership expectation at Staff level and above.
• Drive: The Surprising Truth About What Motivates Us - Daniel Pink - Pink’s autonomy-mastery-purpose model, useful background when weighing the IC and management tracks against each other.