"How do I get promoted here?" When engineers ask this question frequently—and their managers can't give clear answers—you have a ladder problem.
A well-designed career ladder does more than define titles. It creates clarity about expectations, fairness in promotions, and a roadmap for growth. After helping over 50 companies design their engineering leveling systems at SmithSpektrum, I've seen what works, what fails, and why most ladders are more confusing than helpful[^1].
This is the complete framework.
Why Your Ladder Matters
The business case for career ladders is straightforward. Companies with clear growth paths see roughly 25% lower turnover—engineers leave when they can't see where they're going[^2]. Candidates evaluate leveling during offers, and the best ones walk away from companies with opaque or inconsistent systems. And without objective criteria, promotions become political, breeding resentment and bias.
Here's how to know your ladder is broken: Engineers frequently ask how to get promoted. The same people stay at the same level for four or more years. Pay varies widely within the same level. People leave for title bumps they should have gotten internally. Managers can't clearly explain the difference between levels. Promotions feel political rather than merit-based.
If more than two of these describe your organization, you need to fix your ladder.
The Standard Engineering Ladder
Most companies land on six levels, sometimes five or seven. Here's the framework I recommend:
| Level | Title | Scope | Autonomy |
|---|---|---|---|
| L1 | Junior Engineer | Tasks | Guided |
| L2 | Engineer | Features | General direction |
| L3 | Senior Engineer | Projects/Systems | Self-directed |
| L4 | Staff Engineer | Team/Org | Sets direction |
| L5 | Principal Engineer | Org/Company | Drives strategy |
| L6 | Distinguished Engineer | Company/Industry | Industry influence |
Years of experience are rough guides, not requirements. I've seen engineers reach Staff in five years; others never move past Senior despite a decade of tenure. What matters is operating scope, not time served.
The IC track should parallel the management track. Staff Engineer is equivalent to Engineering Manager. Principal is equivalent to Senior EM or Director. Distinguished is equivalent to VP Engineering. When you pay ICs less than managers at the same level—or give management more prestige—you force your best individual contributors into management they may not want and may not be good at.
What Each Level Actually Means
Junior Engineer (L1)
The junior engineer is learning the craft. They execute well-defined tasks with guidance, write working code with assistance, and are learning the team's language and tools.
Their scope is individual tasks within a feature. They work on problems with clear solutions. They need regular check-ins and code review. Their impact comes from contributing to team deliverables.
An example deliverable at this level: implement a form component matching specifications, with tests.
To reach L2, a junior engineer should consistently ship features with minimal rework, rarely need help debugging their own code, proactively ask questions and seek feedback, and show declining code review feedback over time.
Engineer (L2)
The mid-level engineer is a solid contributor. They own features end-to-end with general direction, are proficient in their primary language and stack, and write clean, tested code.
Their scope is complete features within a project. They handle some ambiguity in requirements or approach. They work independently day-to-day, syncing on approach for larger decisions. They communicate clearly, document their work, and flag blockers early.
An example deliverable: design and implement user authentication flow, including edge cases and tests.
To reach L3, they should own complex features with minimal oversight, influence technical decisions within the team, debug issues across system boundaries, mentor junior engineers informally, and identify and address technical debt proactively.
Senior Engineer (L3)
The senior engineer is a trusted expert. They own systems, make technical decisions, and elevate the team around them.
This is where most engineers plateau—and where the real distinctions become important. Senior engineers don't just execute well; they own outcomes, not just outputs. They make trade-off decisions independently. They elevate team members through mentoring and review. They anticipate problems before they occur. They communicate effectively with non-engineers.
Their scope is systems or significant product areas. They handle ambiguous problems requiring judgment. They're self-directed, seeking input only on major decisions. They write RFCs and design docs. They're key contributors to team success who multiply others.
An example deliverable: design and lead implementation of a new payment processing system, including vendor evaluation, architecture decisions, and rollout plan.
To reach L4, their impact must extend beyond the immediate team. They should drive technical strategy for multi-month projects, be recognized as the go-to expert in their domain, influence engineering practices org-wide, and mentor multiple engineers successfully.
Staff Engineer (L4)
The staff engineer is a force multiplier. They set technical direction for their team or org and solve the hardest problems—the ones no one else can solve.
This level is the hardest transition in the individual contributor path. The shift from Senior to Staff isn't about doing more of the same better; it's about changing what you do entirely. Staff engineers set direction rather than follow it. Their technical decisions have org-wide implications. They proactively identify what the company should be doing, not just what it's asked them to do.
Their scope is multiple teams or critical systems. They handle novel problems with significant organizational impact. They set their own direction aligned with company goals. They influence executives and drive cross-team alignment.
Staff engineers often specialize into archetypes:
| Archetype | Focus |
|---|---|
| Tech Lead | Deep involvement in one team's technical direction |
| Architect | Cross-team technical design and standards |
| Solver | Parachutes into hardest problems anywhere in the org |
| Right Hand | CTO's trusted partner on strategic initiatives |
An example deliverable: lead multi-quarter initiative to migrate monolith to microservices, including architecture design, team coordination, risk mitigation, and organizational change management.
Principal Engineer (L5)
The principal engineer is an organizational leader. They shape technical strategy for the entire company and often have industry-recognized expertise.
What distinguishes Principal from Staff: scope is organizational, not just multi-team. They have external visibility and influence. They think in multi-year horizons. They shape what the company becomes, not just what it builds. They could plausibly be CTO elsewhere.
Their scope is organization-wide or company-wide impact. They handle industry-level problems. They partner directly with executives. They represent the company externally and shape industry practices.
An example deliverable: define and drive the company's AI/ML strategy, including build vs. buy decisions, team structure, platform architecture, and three-year roadmap.
Distinguished Engineer (L6)
The distinguished engineer is an industry luminary. They create step-change impact and are equivalent to executive leadership.
Most companies under 1,000 engineers don't need this level. Only create it if you have genuine Distinguished-level work—shaping industry standards, defining new categories, transformational impact—and candidates who can operate at that scope.
Compensation Reality
Here are 2026 compensation bands for the US market. Adjust for location and company stage:
| Level | Title | Base Salary | Equity (Annual) | Total Comp |
|---|---|---|---|---|
| L1 | Junior | $90K-130K | $5K-20K | $95K-150K |
| L2 | Mid | $130K-170K | $20K-50K | $150K-220K |
| L3 | Senior | $160K-210K | $40K-100K | $200K-310K |
| L4 | Staff | $200K-260K | $80K-180K | $280K-440K |
| L5 | Principal | $250K-320K | $150K-350K | $400K-670K |
| L6 | Distinguished | $300K-400K | $250K-600K | $550K-1M |
These represent tech industry norms for well-funded companies. Enterprise and smaller companies typically pay 70-85% of these figures. FAANG and top unicorns pay 120-150% at senior levels[^3].
Band structure best practices: Keep 15-20% overlap between levels so there's room for growth within level. Use wider bands at senior levels where there's more variability in impact. Refresh bands annually against market data. If you use location-based pay, apply geographic adjustments consistently. Consider transparent bands—they reduce negotiation inequity and build trust.
The Promotion Process That Works
Promotions should be evidence-based, calibrated, and unsurprising. Here's the process I recommend:
The promotion packet should include a summary of the level change requested with key achievements, specific evidence for each ladder dimension, quantified scope and impact where possible, peer feedback quotes from collaborators, manager assessment of readiness and growth areas, and a development plan for the new level.
The calibration process:
| Step | Activity | Who |
|---|---|---|
| 1 | Manager prepares packet | Manager |
| 2 | Skip-level review | Skip-level manager |
| 3 | Calibration meeting | All managers at that level |
| 4 | Decision and feedback | Manager + HR |
| 5 | Communication | Manager to engineer |
The calibration meeting is where consistency happens. Managers discuss specific examples, not opinions. They compare candidates to others at the target level. The engineer should know the outcome is likely—there should be no surprises. Document the rationale in writing. Even promoted engineers get feedback on growth areas.
Common Mistakes to Avoid
Design mistakes:
Too many levels create meaningless distinctions. Five or six levels is enough for most companies. Only add more if you have genuine need to distinguish between them.
Vague criteria lead to subjective decisions. "Demonstrates leadership" means nothing. Specify observable behaviors: "Leads cross-team initiatives that deliver measurable outcomes."
Only technical criteria ignores collaboration and communication. Engineers who write great code but can't work with others shouldn't be senior.
No IC track above Senior forces management to advance. Create Staff+ IC paths.
Years of experience requirements penalize fast learners. Remove time-based requirements entirely.
Process mistakes:
Annual-only promotions are too slow. High performers become frustrated waiting a year. Run quarterly cycles.
Manager-only decisions introduce bias and limited perspective. Use calibration with peer managers.
No written criteria means different standards per manager. Publish the ladder document.
Promoting as reward—before someone is ready—sets them up to fail. Promote when they're already operating at the next level.
No "not yet" feedback leads to surprise rejections. Have ongoing growth conversations.
Implementation Roadmap
If you're building or rebuilding your ladder, here's the timeline:
Phase 1: Design (4-6 weeks)
Weeks 1-2: Research 5-10 public ladders from comparable companies. Weeks 2-3: Draft level definitions. Weeks 3-4: Review with senior engineers and managers. Weeks 4-5: Revise based on feedback. Weeks 5-6: Get leadership approval.
Phase 2: Calibration (4-8 weeks)
Weeks 1-2: Train managers on the ladder. Weeks 2-4: Managers level all current engineers. Weeks 4-6: Run calibration sessions level by level. Weeks 6-8: Adjust and finalize levels.
Phase 3: Rollout (2-4 weeks)
Week 1: All-hands announcement. Weeks 1-2: 1:1s to communicate individual levels. Weeks 2-3: Address questions and concerns. Weeks 3-4: Publish documentation.
Phase 4: Operation (Ongoing)
Quarterly promotion cycles. Semi-annual ladder review and refresh. Annual compensation band updates. Ongoing new hire leveling calibration.
Adapting for Your Context
Startups under 50 engineers should use 3-4 levels only—there's not enough differentiation needed. Keep the process light. Titles may be flexible ("Senior" at a startup might mean Staff elsewhere). Don't create Distinguished; you don't have anyone at that level yet.
Hyper-growth companies face specific challenges: levels inflate as people get promoted faster than they should, external hires come in at wrong levels, compression builds as market rates rise faster than internal adjustments. The solution is quarterly recalibration, heavy investment in leveling interviews, regular compensation adjustments, and extensive manager training on calibration.
Acqui-hires and mergers require deliberate level mapping. Don't default to the acquired company's titles—they may have been inflated. Over-communicate the rationale for leveling decisions. Expect friction and handle it with transparency.
Public Ladders to Study
Several companies have published their ladders publicly, and they're worth studying:
| Company | Notable Features |
|---|---|
| Dropbox | Clear scope definitions |
| Etsy | Strong IC track |
| CircleCI | Competency matrix format |
| GitLab | Everything public in handbook |
| Buffer | Transparent salaries included |
Borrow from Dropbox's scope-based level definitions. Study Etsy's Engineering Manager ladder parity. Use CircleCI's competency matrix format if it fits your culture. Adopt GitLab's transparent documentation style. Consider Buffer's salary band transparency.
The companies that retain their best engineers aren't necessarily the ones that pay the most. They're the ones where every engineer knows exactly where they stand, what they need to do to advance, and that the promotion process will be fair when they're ready.
Build that system, and you'll keep engineers who would otherwise leave for a title bump elsewhere. Fail to build it, and you'll lose them to companies that did.
References
[^1]: SmithSpektrum career ladder consulting, 50+ implementations analyzed, 2020-2026. [^2]: LinkedIn Talent Solutions, "Career Development and Retention Study," 2025. [^3]: Levels.fyi, "2026 Tech Compensation Report," verified against SmithSpektrum placement data. [^4]: Reilly, Tanya. "The Staff Engineer's Path." O'Reilly Media, 2022. [^5]: Larson, Will. "Staff Engineer: Leadership Beyond the Management Track." 2021.
Need help designing or implementing an engineering career ladder? Contact SmithSpektrum for customized leveling frameworks and implementation support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum