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

Most large tech companies use 5-7 levels for individual contributors, though they name and number them differently. Here is how the major ladders line up:

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

Titles and typical experience at each rung:

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. The work behind the number is easier to recognize than the number itself.

Entry and Mid-Level (L3-L5)

At entry level you own individual components inside a single service or feature area. Specifications arrive detailed, your tech lead reviews the approach before you start implementing, and the result lands on your immediate team. A task reads like this: “Fix the pagination bug in the user dashboard where the page counter displays incorrectly when filtering results.” You get the bug report, the surrounding code, and usually a hint about where to look.

Mid-level widens that to complete features across frontend and backend, sometimes touching several services. Now you write the technical specification yourself, product and design talk to you without a tech lead in the middle, and other engineers start depending on your APIs. A notification preferences system shows where the work has moved. The request arrives as an outcome: users choose which alerts reach them and through which channels. The data model, the API design, and the error handling come back as your decisions, worked out with the notifications service team.

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.

Reliability work shows the change most clearly. Moving a service from 99.5% to 99.9% uptime starts with failure-mode analysis and ends with monitoring, circuit breakers, and alerting. In between you decide what “done” means and how success gets measured, then bring several teams along to deploy against that definition.

Staff Level (L7/E6/L6)

Staff initiatives cross organizations and run for quarters, and nobody hands you a specification; you define what needs to be built. The architecture you choose enables or constrains what the rest of the company can build, which is why the leadership expectation travels with the scope: technical lead across multiple teams, owner of the standards those teams follow, a voice in hiring strategy and team structure.

Multi-region data replication for a global expansion is one of those initiatives. Active-active or active-passive is the first decision, and it drags consistency requirements and conflict resolution behind it. The RFC that follows is mostly a vehicle for consensus across infrastructure and product teams. Implementation then runs through 5+ teams over 2-3 quarters.

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

Above Staff the horizon becomes multi-year architecture for the whole company. You work with complete independence, set organizational priorities, and shape product roadmaps through technical constraints and openings. Decisions at this level reach 500+ engineers and often external communities through open source or standards work, and the technical vision usually becomes visible outside the company in conferences, papers, or code.

Nothing about that work fits in a quarter. A company’s transition from monolith to microservices needs the boundaries for service extraction drawn once and a migration strategy executives sign off on. Coordination across the entire engineering organization runs 2-3 years, and it leaves behind patterns that become company standards.

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, and the industry needs far more excellent Senior engineers than it needs Staff engineers. 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

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.

So if Senior is the target, Senior-level scope has to start now and hold long enough for a review cycle to see it.

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, and the bar rises faster at every step than it did at the last one.

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. The work that counts carries three marks: complexity past what a Senior engineer solves alone, reach across teams or organizations, and a roadmap measured in quarters.

Projects that clear the bar tend to look alike from company to company:

• 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

If your own team has none of this, the scope usually sits one step away. Infrastructure and platform teams run cross-cutting initiatives that need product-domain expertise, and volunteering to drive one of them through your area, in coordination with the other product teams, is real Staff work. Guilds and working groups are the second route: establishing GraphQL standards or security practices across a technical domain creates the scope that the org chart never assigned you.

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.

The Tech Lead guides one or two teams through the approach and execution of complex projects: owning the checkout team’s technical roadmap, making the architectural calls, reviewing designs, holding the quality line. It is the most common archetype and the most accessible one, because that scope already exists inside product teams. The Architect owns a technical domain across the whole company, such as API design, data storage, or infrastructure patterns. Chief architect for the GraphQL API strategy is the recognizable version: establish the patterns, review implementations, keep 50+ services consistent. The role emerges once a codebase is complex and mature enough that consistency stops happening on its own.

The other two are narrower. A Solver is parachuted into high-priority problems that need senior attention, which fits companies built around individual ownership such as Amazon; a revenue-affecting performance bottleneck goes to a Solver, who takes it from root cause to coordinated fix. A Right Hand extends executive capacity, acting as the CTO’s technical partner on company-wide initiatives and carrying the technical perspective into executive decisions. That one is rare, and only makes sense in organizations with hundreds of engineers.

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?

On the IC track your attention stays on technology: architecture, deep technical work, code review, technical guidance. Meetings pile up at Staff+ as well, but they are mostly technical, and your growth tracks your own execution closely enough that you keep much of the control over it. On the management track the subject changes to people and organizational health, and the day fills with 1:1s, hiring, performance reviews, team planning, and career development. Leverage comes through delegation, the calendar fragments, and growth depends on whether the team gets opportunities to grow.

Compensation Reality

At well-structured tech companies, Staff Engineer and Engineering Manager sit at the same level with identical compensation bands. Moving across is a lateral step.

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

Choosing, and Changing Your Mind

If deep technical problems are what pull you in, the IC track answers that; if it is watching people grow, management does. When neither pulls harder, a Tech Lead role carries some of both and settles the question faster than more deliberation will.

The decision is also reversible. Engineers move Staff → EM → Sr Staff → Director → Principal Engineer, and companies that support traffic in both directions retain stronger talent. Some of them gate the move into management behind a seniority bar, usually Senior or above, on the logic that 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 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

How the management rungs line up with the IC ladder:

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

At each level the two tracks are designed to match on compensation and organizational influence. An L7 Principal Engineer at Amazon carries impact expectations close to an M2 Sr Manager’s; only the means differ. The middle of the management ladder is where managers begin managing managers, and a Director’s 30-80 engineers demand organizational strategy in the same way a Principal Engineer’s remit demands technical strategy.

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

The organizational tells come first: cross-team technical debt accumulating with no owner, technical decisions drifting apart between teams, architecture discussions happening in silos, complex initiatives running without clear technical leadership, and Senior engineers leaving for “Staff” titles elsewhere.

Size and project shape usually confirm what those tells suggest. Around 30-50 engineers spread over 3-5 teams, there is enough cross-team complexity that multiple product areas need architectural consistency, and multi-quarter initiatives start spanning teams that do not report to each other. Infrastructure or platform work serving several product teams points the same way.

When Principal Becomes a Real Level

Principal engineers emerge when Staff engineers aren’t senior enough to own certain problems: multi-year technical strategies with no owner, architecture decisions that reach the entire company, external technical representation in standards bodies or open source, technical due diligence for acquisitions and major partnerships, and Staff engineers who themselves need mentorship and calibration.

That situation tends to arrive past 200 engineers and ten teams needing architectural coordination, or when several business units share the same technical infrastructure. Company-wide platform migrations, multi-year infrastructure investments, and technical strategies that reshape product roadmaps are the projects that justify the level. Most companies under 200 engineers have none of them.

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

Define the scope before the title. If no multi-team, multi-quarter problem is waiting for an owner, a Senior engineer with expanded scope is the cheaper answer, and the rung can wait until the organization grows into it. A title without matching expectations does its own damage: nobody around it can tell why the label exists, least of all the Seniors doing similar work. Reassess the ladder as the organization grows.

Company Size Considerations

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

Under 200 engineers, three or four levels are enough: junior/mid, senior, a rare Staff engineer or two, then CTO or VP of Engineering. There is no organizational complexity to justify eight rungs, and subdividing anyway only adds names to memorize.

Between 200 and 1000 engineers the complexity shows up on its own. Five or six levels (entry, mid, senior, staff, principal, then CTO/VP/Distinguished) map onto teams that genuinely need coordination and cross-organizational scope that genuinely exists. Past 1000 engineers, a full seven or eight rung ladder in the FAANG shape earns its keep, Distinguished and Fellow included.

The failure runs in one direction: a 30-engineer startup adopting Google’s L3-L10 system. Add levels as the organization grows into them.

European vs US Tech Companies

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)

Zalando’s C and SC Bands

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.

What Goes in the Packet

Ten to fifteen pages, three or four case studies, each one showing scope you did not hold before. For every case study: the technical problem and why it mattered, the piece you owned and who you worked with, the architecture and the trade-offs behind it, the quantified outcome, and the leadership visible around it (mentorship, cross-team influence, standards other teams picked up).

Concrete numbers carry the case:

• “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”

Their vague cousins do not. “Made the system faster” invites the question how much. “Improved reliability” invites which metric. “Led the team” invites which decisions and what came of them.

Testimonials cover the part you cannot claim yourself. Ask the Staff engineers you partnered with on cross-team initiatives, the engineers you mentored, the product managers you worked with closely, and the teams that adopted your technical standards. Point them at something specific: “Can you share how the observability improvements affected your team’s incident response time?”

Keeping the Record Current

Document wins as they happen, so promotion season is not an archaeology project: a “wins” document updated monthly, project outcomes shared in team meetings, technical work presented at engineering all-hands, documentation and internal tech talks that leave a trace. Promotion committees decide on evidence, and they cannot weigh impact they never heard about.

Mistakes That Keep Repeating

Some of these belong to engineers, some to the companies they work for, and the two feed each other.

Optimizing for the title. Jumping to another company for a Staff title without actual Staff-level scope leads to performance problems on arrival. Read what cross-organizational work the role carries before the label makes the offer look good.

Chasing interesting over impactful. Promotion committees weigh business impact above technical complexity, so absorbing work with a small blast radius builds a thin case.

Too many rungs. Ladders with 10+ levels turn progression into box-checking, and every promotion lands smaller than it should. 5-7 levels works for most organizations.

Treating the framework as a scorecard. When engineers arrive with “I did all 10 items, where’s my promotion?”, the ladder has stopped working as a conversation guide. The bullets exist to give that conversation a shared vocabulary, so the more useful thing to bring a manager is which parts of the next level’s scope you are already carrying.

Limits of the Mapping

The tables above are 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. They break 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.