Design engineering career ladders that provide clear growth paths, consistent performance evaluation, and retention through career development. Covers IC and management tracks, level definitions, promotion criteria, and compensation frameworks.
Engineering Career Ladders define the expected progression of technical and leadership capabilities across an engineering organisation. They align expectations, guide promotions, and structure growth from individual contributor to senior leadership. A career ladder matters most when a team needs to assess readiness for promotion, decide on compensation, or clarify expectations during onboarding and performance reviews. It becomes a shared language across engineering, product, and leadership, ensuring that "senior" means the same thing whether in mobile, backend, or infrastructure.
A career ladder is a hierarchical framework of levels, each with a set of expectations for skills, responsibilities, and impact. The core of a ladder is a list of *competency domains*, each describing the breadth and depth of work expected at a level. These domains are not abstract categories but concrete, observable behaviours.
Each level is described by a set of *anchors*—specific, measurable outcomes that signal mastery. For example, a Level 3 engineer might be expected to:
The ladder is not a static document. It is a living artifact, versioned alongside engineering practices. Changes are tracked via git, with each revision linked to a release note and a discussion in a dedicated #career-ladders Slack channel.
To evaluate a candidate for promotion, teams follow a consistent process: they collect evidence from real work and map it to the ladder’s expectations. The process begins with identifying *artifacts*—real, executable outputs from an engineer’s work.
An engineer’s promotion packet includes:
.md file in docs/decisions/, with a decision key in the frontmatter and a status field of approved, review, or proposed.Each artifact must be linked to one or more *ladder dimensions*. For example, a service deployment may satisfy expectations in *System Design*, *Ownership*, and *Communication*.
The promotion committee meets to assess a candidate. They use a shared spreadsheet with columns for each level, and each row corresponds to a ladder dimension. The committee marks each expectation as *exceeded*, *met*, or *not met*, with supporting evidence in the adjacent cell.
For instance, under *Technical Depth*, a Level 4 engineer must:
The committee evaluates based on the candidate’s artifacts. A pull request with a complex refactoring, including a performance benchmark and a migration script, supports a claim that the engineer meets the *Technical Depth* expectation.
Each level in the ladder is defined by a set of *expected outcomes*, not just lists of responsibilities. These outcomes are derived from real engineering work and are observable in day-to-day practice.
At Level 1, an engineer is expected to:
The level is confirmed when an engineer has shipped three independent features, each with a deployment note and a post-mortem.
A Level 2 engineer is expected to:
The level is validated by a *feature review*, a 30-minute session where the engineer presents their work to peers, demonstrating their ability to explain trade-offs and defend design decisions.
A Level 3 engineer must:
The decision record is stored in docs/decisions/, with a decision.md file that includes:
---
title: "Integrate Redis for Session Caching"
status: "approved"
created: "2024-01-15"
author: "[email protected]"
reviewers:
- "[email protected]"
- "[email protected]"
tags:
- "caching"
- "performance"
- "scalability"
---The record must be reviewed and approved by at least two senior engineers before being marked as *final*.
A Level 4 engineer is expected to:
The initiative is documented in a initiative.md file, with a status field and a timeline array of milestones.
A Level 5 engineer must:
The domain definition is published as a domain.md file in a docs/engineering-domains/ directory, with a vision, principles, and metrics section.
The promotion process begins with a self-nomination. The candidate submits a *promotion packet*, which includes:
The packet is reviewed by a *promotion committee*, composed of at least three engineers from different teams and levels. The committee evaluates the packet against the ladder, using a *rubric* with scores for each domain.
The meeting is conducted via Zoom, with a shared document that includes:
docs/promotions/.The committee discusses each artifact, asking clarifying questions. For example:
> "You said you led the migration to Kubernetes. Can you walk us through the rollout strategy and the key decisions made?"
They use a shared document to take notes and assign scores. The meeting concludes with a vote: *approved*, *conditional*, or *not yet ready*.
A conditional promotion requires the candidate to complete a set of *action items* within three months. These items are documented in a promotion-2024-02-15.md file, with a status field and a deadline field.
---
title: "Promotion to Level 4: Jane Doe"
status: "conditional"
deadline: "2024-05-15"
actions:
- description: "Lead a cross-team initiative to improve CI/CD pipeline performance"
due: "2024-04-10"
owner: "[email protected]"
status: "in-progress"
- description: "Write a decision record on adopting a new monitoring stack"
due: "2024-05-01"
owner: "[email protected]"
status: "pending-review"
---The candidate is expected to update the document weekly and present progress at a biweekly engineering sync.
The ladder is not a document but a *practice*—a way of working. Teams embed it into their workflows.
New engineers receive a *ladder guide*, a PDF that walks them through the expectations for each level. The guide includes:
The guide is versioned and updated quarterly, with each version tagged in git.
Performance reviews are structured around the ladder. The review form includes:
The review is conducted in a *ladder review meeting*, where the engineer presents their work and receives feedback.
Feedback is collected through a *ladder feedback form*, a simple form.md file that includes:
---
title: "Feedback on Career Ladder"
author: "[email protected]"
date: "2024-01-20"
targets:
- "Level 2"
- "Level 3"
- "Level 4"
feedback:
- type: "positive"
content: "The level 3 expectations are clear and actionable."
- type: "suggestion"
content: "Include a sample decision record in the level 2 guide."
- type: "issue"
content: "The level 4 engineer should be expected to lead a cross-team initiative, but it's not in the rubric."
---The form is shared via email and collected in a feedback/ directory in the engineering repository.
The ladder fails silently when expectations are assumed but not made explicit.
A common failure is *level confusion*: a Level 2 engineer is expected to do Level 3 work, but the expectation is never documented. The ladder must clarify the *threshold* between levels.
For example, a Level 2 engineer is expected to *own* a feature, but a Level 3 engineer is expected to *define* a feature from scratch, including market research and user validation. The difference is subtle but critical.
Many engineers submit pull requests without linking to documentation. The ladder expects that every significant change is documented, but teams often forget to require a *documentation check* as part of the code review.
The *documentation check* is a simple workflow: after a pull request is merged, a CI job runs make docs and uploads the updated documentation to docs/. A docs/ directory is required at the root of every repository.
Artifacts are often incomplete. A decision record may be missing a problem statement or a performance benchmark. The ladder requires that each artifact be *self-contained*—a reader should understand the work without extra context.
A common failure is *artifact drift*: the format of artifacts changes over time, but the ladder does not reflect the current standard. The ladder is updated only when a major promotion occurs, but new teams adopt different formats.
The promotion packet is often submitted late, with missing artifacts. The committee expects that every artifact is linked to a specific level expectation, but many are not.
The *promotion packet checklist* is a shared document with a list of required items:
The checklist is updated in real time, and the committee uses it to verify completeness.
The ladder is iterated via a *ladder review cycle*, a biannual process that includes:
Changes are proposed as a pull request to the ladders/ directory in the engineering repository. The PR includes:
The change is reviewed by a *ladder working group*, and the final version is merged and published.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy