Career growth
Engineering career ladders: how to build and use one
A career ladder describes what is expected of engineers at each level and how people move between them. Without one, promotions feel arbitrary and growth conversations drift. This guide explains how ladders are structured, where to find public examples, and what to update now that engineers work with AI tools.
What a ladder is for
- Clarity: engineers know what "good" looks like at their level and the next.
- Fairness: promotions and pay decisions rest on shared criteria, not on who argues loudest.
- Hiring: interviewers level candidates against the same descriptions.
- Growth conversations: one-on-ones have a concrete reference. See one-on-ones for engineering leads.
How ladders are usually structured
Two tracks
Most ladders split after a senior level into an individual contributor track (staff, principal and beyond) and a management track (engineering manager, senior manager, director). The two tracks run in parallel so engineers do not have to manage people to keep progressing. Engineering lead roles often sit near the split; where they fit is covered in engineering lead vs engineering manager.
Levels and dimensions
Each level is described across a few dimensions. Common ones:
| Dimension | What changes as people progress |
|---|---|
| Scope | From tasks, to features, to systems, to multiple teams or the organization |
| Technical skill | From applying patterns, to choosing them, to setting them for others |
| Autonomy and ambiguity | From well-defined work, to shaping undefined problems |
| Impact | From own output, to the team's results, to the organization's direction |
| Collaboration and communication | From within the team, to across teams and with leadership |
| Growing others | From learning, to mentoring, to building the next generation of leaders |
Behaviors, not tasks
Good ladders describe observable behavior ("breaks ambiguous problems into plans others can execute") rather than activities ("attends planning meetings"). Behavior can be evidenced; activity only shows presence.
Public examples to learn from
Several companies publish their ladders. progression.fyi collects many public and open-source career frameworks in one place, and GitLab publishes its engineering job families, including management levels, in its public handbook. Reading three or four side by side is a quick way to see common structure and where companies differ. Adapt rather than copy: a ladder written for a large company can overwhelm a small team.
What to update for the AI era
Many ladders were written when producing working code was the main measure of skill. With AI tools producing first drafts, some expectations need sharper wording:
- Judgment over volume. Remove or soften anything that rewards quantity of output. Describe the ability to evaluate, simplify and reject work.
- Review as a core skill. At every level, describe what good review looks like, including review of AI-assisted changes. See reviewing AI-generated code.
- Understanding what you ship. Make explicit that engineers explain and support the code they merge, whatever produced it.
- Specification and decomposition. Writing clear problem statements and acceptance criteria, for people and for tools, becomes a visible skill at mid and senior levels.
- Responsible tool use. Following data and security rules, and at senior levels helping shape them. See writing an AI coding assistant policy.
- Early-career learning. Describe how junior engineers show growing understanding, such as debugging and explaining changes, not just delivering tickets.
Building or revising a ladder
- Gather input. Ask engineers and managers what is unclear or unfair about current expectations.
- Draft levels and dimensions. Start with fewer levels than you think you need; it is easier to add than remove.
- Test against real people. Place current engineers anonymously and see whether the descriptions match your judgment. Where they do not, fix the wording.
- Review with HR. Levels usually connect to compensation bands and legal requirements.
- Publish and explain. Walk the team through it, and say how promotions will work.
- Revisit regularly. Tooling and team needs change; set a review date.
Using the ladder day to day
- Agree on one or two development goals per engineer, tied to the next level's descriptions.
- Choose work that gives people a chance to show those behaviors.
- Collect evidence throughout the year, not only at review time.
- Calibrate with other leads so the same level means the same thing across teams.
Common ladder problems
| Problem | What it causes | Fix |
|---|---|---|
| Vague wording ("has strong impact") | Promotions decided by whoever argues best | Describe observable behavior with examples |
| Checklists of activities | People collect tasks instead of growing | Describe outcomes and scope instead |
| Management as the only path up | Strong engineers become reluctant managers | A parallel individual contributor track with equal standing |
| Levels that require visible "big projects" | Maintenance and reliability work is undervalued | Recognize impact from operations, debt reduction and mentoring |
| Ladder never discussed | Surprises at review time | Refer to it in regular growth conversations |
The fourth problem matters more as AI tools speed up feature work. Engineers who keep systems reliable, pay down technical debt or run strong incident reviews need a clear route to recognition too.
A promotion case outline
Engineer and target level.
Summary: why they are operating at the next level now.
Evidence by dimension: two or three concrete examples for each, with links to designs,
reviews, incidents or results.
Feedback: from peers and partners who saw the work.
Growth areas: what they will develop next.
Common questions
How many levels should a ladder have?
Enough that each step is meaningful and distinguishable, and few enough that people can describe the difference between neighboring levels. Small companies often start with fewer and add levels as they grow.
Can someone move from the management track back to individual contributor?
In healthy organizations, yes. Make the path explicit so it is not seen as a demotion.
Should the ladder mention specific AI tools?
No. Tools change faster than ladders. Describe skills and behaviors, and keep tool guidance in your policy.
How does a ladder help with hiring?
It gives interviewers a shared description to level candidates against. See hiring an engineering lead.
Last reviewed 2026-09-17