Engineering Career Ladder: How to Build One That Actually Works

2026-07-21 · 8 min read · Career & Promotions

A career ladder is the most referenced document in any engineering organisation and often the least trusted. Engineers learn quickly whether the ladder reflects how promotions actually happen, or whether it's a compliance artefact that gets mentioned in reviews and otherwise ignored.

When a ladder works, it gives engineers a clear picture of what growth looks like and where they stand. It makes performance reviews honest and promotion documents concrete. When it doesn't work, it creates cynicism, arguments about definitions, and promotions that feel arbitrary.

Here's how to build — or fix — one that engineers actually trust.

What a Career Ladder Is For

Before designing anything, be clear about what you need the ladder to do:

Clarify expectations at each level so engineers know what's required of them today and what earning the next level looks like. This reduces the most common complaint in engineering performance conversations: "I didn't know that was what you were looking for."

Create consistency across the team so two engineers at the same level are held to the same standard. Without a ladder, promotion decisions drift toward whoever advocates loudest or is most visible.

Enable honest career conversations in 1:1s. When the expectations are written down, you can say "here's where you're strong at this level and here's the gap" rather than speaking in vague terms that don't guide action.

Provide a framework for promotion documents. The promo doc is essentially the ladder applied to a specific person — the ladder is the rubric; the impact stories are the evidence.

The Common Failure Modes

Too vague: "Senior Engineers demonstrate leadership" — what does that mean? A ladder full of adjectives ("strong", "independent", "impactful") gives no guidance because everyone interprets those words differently.

Too granular: A ladder with 40 criteria per level creates its own problem — engineers optimise for criteria-checking rather than genuine growth. Nobody can hold 40 things in their head.

Too focused on technical skills only: Engineering at senior levels and above is mostly about scope, influence, and judgment — not raw technical ability. A ladder that doesn't describe those dimensions will mislabel most of your senior engineers.

Never calibrated against reality: A ladder that's aspirational but disconnected from how promotions actually happen will be dismissed within a quarter. Engineers are good at noticing when the official story doesn't match what they observe.

The Right Structure

A good engineering ladder has three parts for each level:

1. The Core Dimensions (4–6 max)

These are the categories of behaviour the ladder assesses. Common dimensions:

Pick the dimensions that match your organisation's values. Keep them to five or fewer — beyond that, the ladder becomes unwieldy.

2. Behavioural Descriptions Per Level

For each dimension at each level, write 2–3 observable behaviours. The test: could you recognise this behaviour in a code review, a design doc, a 1:1, or a project outcome? If you can only recognise it in a vibe, rewrite it.

Example for the "Scope" dimension:

Level What scope looks like
Engineer I Completes well-scoped tasks within a single feature or component.
Engineer II Delivers full features end-to-end with minimal guidance. Identifies and raises scope risks before they become delivery failures.
Senior Engineer Owns complex projects that span multiple components. Coordinates dependencies across the team. Technical decisions affect the team's work for months.
Staff Engineer Sets technical direction for the team or a major system. Identifies problems the team should be solving that aren't in the current roadmap. Decisions affect multiple teams.

Notice the progression: it's not about being "better" at the same thing — it's about the radius of the work expanding. This is the key insight most ladders miss.

3. The Promotion Signal

For each level transition, write one paragraph that describes what the promotion signal looks like in practice — not just the criteria, but the gestalt. What does it feel like when someone is clearly at the next level?

The signal for Senior Engineer is that you've stopped needing the EM or Tech Lead to scope the problem for you. You scope it yourself, you identify the risks yourself, and you're right about the estimate most of the time. The rest of the team is starting to look to you when they're stuck.

This kind of description can't be gamed, and it gives engineers (and EMs) a gut-check that the criterion-level detail doesn't.

The Right Number of Levels

There's no universal answer, but here's a practical guide:

Team size Levels that make sense
Startup (< 20 eng) 3–4: Junior, Mid, Senior, (optional) Staff
Growth (20–100 eng) 4–5: adds distinction between L3/L4
Scale (100+ eng) 5–6: adds Principal/Distinguished

Avoid creating levels you can't fill. If you have 8 engineers and a 7-level ladder, most of those levels will never have anyone in them and the ladder will feel theoretical.

Also avoid conflating IC and management tracks in the same ladder. Once engineers reach the Staff level, the IC and EM paths are genuinely different and need separate descriptions.

How to Roll It Out

The biggest mistake in ladder rollouts is handing engineers a finished document and calling it done.

Co-create it with your team. Involve senior engineers in the definition of their own level and above. Their perspective on what "good" looks like at senior level is sharper than yours in many respects. Involvement also creates buy-in — engineers are far more likely to trust a ladder they helped write.

Pilot it before publishing it. Apply the draft ladder to your current team in private. Does it produce assessments you'd stand behind? Are the level boundaries landing in the right places? If your current L4 engineer maps to L3 under the new ladder, either your engineer was mislabelled or the ladder is miscalibrated.

Calibrate across EMs. If multiple EMs apply the same ladder to their teams independently and the results look wildly different, the ladder is too vague. Get in a room and talk through the specific cases where you disagree. The disagreement is the signal that the ladder needs sharpening.

Revisit annually. A ladder written in 2022 may not reflect what the company needs in 2026. Technology changes, business needs change, and what "impact" means changes with them. Build in a review cycle.

Using the Ladder Day-to-Day

A ladder that lives in a doc nobody opens isn't a ladder — it's a ritual. To make it useful:

Reference it in every 1:1 conversation about growth. When an engineer says "I want to get to Senior," pull out the ladder. "Here are the Senior criteria. Here's where you're already demonstrating them. Here's where the gap is." That specificity is more valuable than any amount of general encouragement.

Use it to prepare promotion documents. Structure the document around the ladder criteria. If you've been collecting impact stories throughout the year, they map directly onto the criteria. The promo doc writes itself.

Use it to set individual OKRs. If the ladder says "Senior Engineers lead complex cross-team projects," make that an OKR for the engineer targeting that level. Goals and growth criteria become the same thing.

Be transparent when someone isn't meeting their level. The ladder makes these conversations less personal: "Here are the criteria for your current level. Here are the areas where you're not yet consistently meeting them." The criteria are the standard; you're not the standard.

The engineers who trust the ladder are the ones whose managers use it consistently — in 1:1s, in reviews, in promotion conversations. A ladder that only appears at review time is just a form to fill in. A ladder that's a living reference tool shapes the team's growth.


Emtricks lets you track each engineer's goals and career development alongside their GitHub activity and 1:1 notes — so the gap between where they are and where the ladder says they should be is always visible. Try it free for 30 days.