Engineers say they don't know what it takes to be promoted. What do you introduce?

A shared career ladder with a few dimensions (scope, technical, delivery, people) and observable behaviours per level, used in every growth conversation and calibrated across managers.

How do you use a ladder in a growth conversation?

Place the engineer on each dimension with concrete examples, describe the next level, and agree an opportunity that exercises the gap, reviewing progress regularly.

What is the risk of a ladder used as a checklist?

People optimise for ticking boxes instead of real impact and judgement; ladders should describe impact and behaviours, interpreted with evidence.

Career Ladders and Clear Expectations — The Engineering Manager Handbook (Development Manager)

Scenario

Example organisation: in the 40-engineer organisation, "senior" means different things in different teams. One manager promotes for technical depth, another for project leadership. Engineers can't say what they need to do to progress; two leave citing "no clear growth path".

What you see on the team

Engineers asking "what do I need to do to get promoted?" and getting vague answers.
Inconsistent levels across teams for similar work.
Promotions perceived as favouritism.
Growth conversations that don't connect to anything concrete.

The common mistake

Leaving expectations implicit — in managers' heads — instead of writing them down in a shared ladder that describes impact and behaviours at each level.

Why it happens

Ladders take effort to write and agree. Small organisations rely on shared understanding, which breaks down as they grow and managers change. Without written expectations, evaluation defaults to visibility and personal relationships.

The playbook

Adopt or write a ladder with a few dimensions and observable behaviours per level. Open examples like career-ladders.dev are good starting points. A typical structure:

Dimension	Mid-level engineer	Senior engineer	Staff engineer
Scope	Well-defined features within a team	Projects across a team's area	Problems spanning several teams
Technical	Writes solid, tested code; good design within components	Designs systems; anticipates failure modes	Sets technical direction for an area
Delivery	Delivers own work predictably	Leads projects; manages risk and dependencies	Unblocks multiple teams
People	Helps teammates; good reviews	Mentors; raises the team's bar	Grows senior engineers; shapes culture

Use it in every growth conversation: "Here's where you are on each dimension, with examples; here's what the next level looks like; here's a project that would exercise it."

Write evidence down throughout the year (in your notes per report), mapped to ladder dimensions.

Calibrate across managers so levels mean the same thing everywhere.

Keep it alive: review the ladder yearly with engineers' input.

What to say

Growth conversation:

"On delivery and technical skills you're already working at senior level — the migration design is a good example. The gap is scope: senior engineers lead work across the team's area. The pipeline project next quarter would be a good test. Want to take it on, and we'll review progress monthly against the ladder?"

Trade-offs

Ladders can become checklists; emphasise impact and judgement over ticking boxes.
Too many dimensions become unmanageable; four to six is usually enough.
One ladder for all roles misses specialisations; consider variants (e.g. platform, mobile) sharing core dimensions.

Signals it's working

Engineers can describe what the next level requires for them, specifically.
Promotion cases cite ladder dimensions with evidence.
Level consistency improves across teams.
"No clear growth path" disappears from exit interviews.

Key points

Write expectations per level in a shared ladder with a few dimensions and observable behaviours.
Use it in every growth conversation, with concrete examples and opportunities.
Collect evidence through the year; calibrate across managers.
Review the ladder yearly with engineers' input.