The Engineering Ladder Nobody Follows (And How to Fix It)

The Document Nobody Reads

Every engineering org past 15 people has a career ladder document. It's usually a Google Doc or Notion page with vague descriptions like "demonstrates technical leadership" for senior engineers and "drives architectural decisions" for staff engineers.

Nobody uses it. Promotion decisions are made based on gut feel, recency bias, and who's loudest in meetings. The ladder exists to satisfy HR, not to actually develop engineers.

Here's how to fix it.

Why Career Ladders Fail

Problem 1: Vague Competencies

Bad:
  Senior Engineer: "Demonstrates technical leadership"

What does that mean? Leading a team? Making architecture decisions?
Mentoring juniors? Writing documentation? All of the above?

Good:
  Senior Engineer — Technical Leadership:
  - Owns technical decisions for their team's domain
  - Has made at least 2 architectural decisions documented in RFCs
  - Other engineers seek their input on design reviews
  - Can articulate tradeoffs to non-technical stakeholders

Problem 2: No Observable Behaviors

Bad:
  Staff Engineer: "Has broad impact across the organization"

Good:
  Staff Engineer — Organizational Impact:
  - Has improved a process or system used by 3+ teams
  - Has written documentation or tooling adopted org-wide
  - Has mentored at least 2 engineers to promotion
  - Is consulted on cross-team technical decisions

Problem 3: Only Measures Output, Not Behaviors

Bad ladder measures:
  ✗ Lines of code
  ✗ Number of PRs merged
  ✗ Features shipped

Good ladder measures:
  ✓ Quality of technical decisions
  ✓ How they handle ambiguity
  ✓ Impact on team velocity (not just personal velocity)
  ✓ Knowledge sharing and documentation

The Ladder That Works

Level 1: Junior Engineer (IC1)

Scope: Individual tasks within a well-defined feature
Autonomy: Needs regular guidance on approach
Impact: Completes assigned work reliably

Observable behaviors:
  □ Completes tickets with clear requirements independently
  □ Asks for help within 30 minutes of being stuck
  □ Writes code that passes review with < 3 rounds
  □ Writes basic tests for their own code
  □ Participates in code reviews (reading, not just writing)

Promotion signal: Consistently delivers without surprises.

Level 2: Mid-Level Engineer (IC2)

Scope: Features end-to-end within their team's domain
Autonomy: Needs guidance on priorities, not approach
Impact: Improves the codebase they work in

Observable behaviors:
  □ Breaks down ambiguous requirements into tasks
  □ Identifies edge cases before they're found in review
  □ Proposes improvements to existing code during feature work
  □ Gives substantive code review feedback to peers
  □ Can debug production issues in their domain

Promotion signal: Other engineers want them on their project.

Level 3: Senior Engineer (IC3)

Scope: Their team's technical domain
Autonomy: Sets technical direction within their area
Impact: Makes their entire team more effective

Observable behaviors:
  □ Owns technical decisions — writes RFCs, evaluates tradeoffs
  □ Identifies systemic problems, not just symptoms
  □ Mentors 1-2 junior/mid engineers effectively
  □ Reduces technical debt while shipping features
  □ Communicates technical tradeoffs to product/business

Promotion signal: They operate independently. Their manager
  doesn't worry about their area — it just works.

Level 4: Staff Engineer (IC4)

Scope: Multiple teams or an entire technical domain
Autonomy: Defines problems, not just solutions
Impact: Changes how the organization builds software

Observable behaviors:
  □ Identifies and solves problems that span multiple teams
  □ Creates tools, libraries, or patterns adopted org-wide
  □ Mentors senior engineers toward technical leadership
  □ Influences technical strategy and roadmap
  □ Writes proposals that change how teams work

Promotion signal: The org would notice immediately if they left.

The Calibration Process

Quarterly Calibration (Not Annual)

Every quarter, managers meet to calibrate:

For each engineer:
  1. Current level: IC2
  2. Evidence of next-level behaviors:
     - [Specific example 1]
     - [Specific example 2]
  3. Gaps to address:
     - [Specific gap]
  4. Assessment: On track / Needs development / Ready

Duration: 5 minutes per engineer
Frequency: Quarterly

The Evidence Rule

No promotion without evidence. For each competency at the target level, the engineer must have at least 2 concrete examples from the last 6 months.

The Anti-Patterns

❌ Promoting for tenure ("They've been here 3 years")
❌ Promoting to retain ("They'll leave if we don't")
❌ Promoting for output ("They ship a lot of code")
❌ Title inflation ("Everyone at competitors is a senior")

✅ Promoting for demonstrated, sustained next-level work

Making It Real

Step 1: Audit your current ladder. Look at your last 5 promotions — can you point to specific behaviors that justified each one?

Step 2: Rewrite with observable behaviors. For each level, define 5-7 behaviors that two managers would agree on.

Step 3: Share with engineers. They should know exactly what's expected at their current level and the next.

Step 4: Calibrate quarterly. Five minutes per person. Evidence-based, not vibes-based.

Step 5: Tie to compensation. If your ladder doesn't connect to comp bands, it's just words.

A career ladder that works gives you retention, fair promotions, self-directed growth, and better hiring. The ladder isn't a document — it's a system. Build it like one.