Creating an Engineering Career Ladder That Actually Works

A senior engineer on my team once asked me a question I couldn't answer: "What do I need to do to get promoted to staff?" I stumbled through some vague language about "broader impact" and "technical leadership." She pressed: "Can you be more specific?" I couldn't. And in that moment, I realized our career ladder was broken—or more accurately, it didn't exist beyond some informal manager intuition.

That conversation started a six-month project to build a proper engineering career ladder. The process was messy, iterative, and occasionally contentious. But the result transformed how our team thinks about growth, how managers make promotion decisions, and how engineers plan their careers.

Why Career Ladders Fail

Most engineering career ladders I've encountered fail for predictable reasons. Understanding these failure modes helped me avoid them in our design:

Failure Mode	What It Looks Like	Root Cause
Too vague	"Demonstrates leadership" with no examples	Designed by HR without engineering input
Too prescriptive	Checklist of specific tasks to complete	Confuses activities with capabilities
Title inflation	Everyone's a "senior" by year two	No calibration or consistency
IC ceiling	Individual contributors max out at Staff	Organization only values management
Moving goalposts	Criteria change when someone is ready	Lack of documented, stable standards
Manager gatekeeping	Promotions depend on manager's advocacy	No transparent evaluation process

The career ladder I built addresses each of these specifically. It's detailed enough to be actionable, broad enough to accommodate different specializations, and transparent enough that engineers can self-assess.

Our Level Structure

After benchmarking against 15 companies and extensive team discussion, we landed on this structure:

IC Track:

• L3: Software Engineer (0-2 years typical experience)
• L4: Senior Software Engineer (2-5 years)
• L5: Staff Software Engineer (5-10 years)
• L6: Principal Software Engineer (10+ years)
• L7: Distinguished Engineer (rare, org-wide impact)

Management Track:

• M4: Engineering Manager (manages 4-8 ICs)
• M5: Senior Engineering Manager (manages managers or large team)
• M6: Director of Engineering

The IC and management tracks share the same level numbers, meaning a Staff Engineer and a Senior Engineering Manager are organizationally equivalent. This isn't symbolic—it affects compensation, influence, and organizational decision-making equally.

The Four Dimensions

Each level is defined across four dimensions. The dimensions are the same at every level; what changes is the expected scope and depth.

Technical Execution: The complexity of problems you solve and the quality of your solutions. At L3, this means writing correct, tested code with guidance. At L5, this means designing systems that serve the organization for years. At L6, this means defining the technical strategy that shapes the company's architecture.

Scope of Impact: How many people and systems are affected by your work. L3 impacts their own tickets. L4 impacts their team's success. L5 impacts multiple teams. L6 impacts the engineering organization. L7 impacts the industry.

Communication and Influence: How effectively you communicate ideas and shape decisions. L3 communicates clearly within their team. L5 writes influential RFCs and persuades across teams. L6 shapes industry conversations and represents the company externally.

Mentorship and Culture: How you elevate others and improve the team environment. L3 helps new team members onboard. L4 actively mentors juniors. L5 creates systems that scale mentorship beyond their personal involvement.

Making It Concrete With Examples

Abstract dimensions aren't enough. For each level and dimension, we provide three things:

1. Description: What capability looks like at this level
2. Examples: Specific behaviors or accomplishments that demonstrate the capability
3. Anti-patterns: What this level is NOT (to prevent confusion with adjacent levels)

For example, at L5 Staff Engineer, Technical Execution:

Description: Designs and implements systems that set architectural direction for the organization. Makes technology decisions with multi-year implications. Navigates extreme ambiguity in problem definition.

Examples: Led the migration from monolith to services, designing the service decomposition strategy and shared infrastructure. Identified and resolved a fundamental scalability bottleneck that would have blocked the company at 10x growth.

Anti-pattern: Simply being the best coder on the team. Staff requires design influence across teams, not just individual contribution excellence.

The Promotion Process

Having clear levels means nothing without a fair promotion process. Here's how ours works:

Self-nomination: Engineers can nominate themselves for promotion at any time. They submit a "promotion packet" documenting their work against the next level's criteria.

Manager endorsement: The manager reviews the packet and either endorses it (proceeds to committee) or provides specific feedback on what's missing. If a manager blocks a self-nomination, they must provide written reasoning.

Promotion committee: A rotating group of senior engineers and managers (never the nominee's direct manager) reviews packets and makes decisions. This reduces the dependency on a single manager's advocacy.

Feedback loop: Whether approved or not, the nominee receives specific written feedback. If denied, the feedback includes exactly what's needed and a suggested timeline for re-nomination.

This process takes the promotion decision out of a single manager's hands while still involving managers as the primary coach. It's more work than a manager simply deciding, but it's dramatically more fair and transparent.

Handling the Hardest Cases

Some situations aren't covered by a standard rubric:

The specialist vs. generalist tension: Our ladder accommodates both. A database specialist at L5 might have deep expertise in one area rather than broad systems thinking. We evaluate based on the impact of their specialization, not breadth for its own sake.

The prolific IC who doesn't mentor: At L5+, mentorship becomes non-optional. An engineer doing incredible technical work but not elevating others is a strong L4, not an L5. This is the most common feedback point, and it's the one engineers push back on most.

The late-career engineer who's content at their level: Not everyone wants promotion. We normalize this by separating "growth" from "advancement." Every engineer should grow (new skills, deeper expertise, broader perspective), but not everyone needs to advance to the next title.

The management-to-IC transition: Engineers who try management and return to IC don't go back to their pre-management level. They keep whatever level they've demonstrated capability for.

Common Questions

"How long should I be at a level before being promoted?" There's no minimum time. We've promoted people in 8 months and had people happily stay at a level for 5 years. Time is not a criterion—demonstrated capability is.

"What if my work doesn't map to the examples?" Examples are illustrative, not exhaustive. The dimensions are what matter. If your impact is at a certain level but expressed differently than the examples, that's fine.

"Can I be at different levels on different dimensions?" Yes, and most people are. You're promoted when you're consistently operating at the next level across all four dimensions. One dimension lagging slightly is normal and addressable; two or more dimensions lagging means you're not ready yet.

Key Takeaways

• Career ladders fail when they're too vague, too prescriptive, or subject to manager gatekeeping
• Define levels across consistent dimensions: technical execution, scope, communication, and mentorship
• Make each level concrete with descriptions, examples, and anti-patterns—not just abstract criteria
• Allow self-nomination and use a promotion committee rather than relying solely on manager advocacy
• Normalize staying at a level and distinguish between growth and advancement
• Ensure the IC track has genuine parity with management in compensation and organizational influence
• Provide written feedback for every promotion decision, whether approved or denied
• At senior levels, mentorship and culture impact become non-optional—technical excellence alone isn't sufficient

A career ladder isn't just an HR document—it's a statement about what your organization values. Design it intentionally, apply it consistently, and evolve it based on feedback. Your best engineers will stay because they can see a clear path forward rather than relying on political navigation to advance.