Engineering Career Ladder Template (IC and Manager Tracks)
IC and manager tracks, L1 to L7 levels, six competency areas, behaviour descriptors, expectations matrix, promotion evidence, calibration, fairness checks
사용법: Use it when you define or overhaul how engineers and managers are levelled, promoted and hired at a level. Fill the level summary and the six competency areas first, then the descriptors and the expectations matrix, and pilot them on real anonymised cases. The main pitfall is vague, escalating adjectives instead of visible changes in scope.
미리보기
Engineering Career Ladder: [Organisation name]
Career framework for software engineers and engineering managers: the individual contributor (IC) and manager tracks, the levels and their scope, six competency areas with behaviour descriptors per level, the expectations matrix, the promotion process and evidence rules, calibration, level-change rules, fairness and bias checks, and the review cadence for the ladder itself. There is no formal standard for engineering ladders; the structure draws on common industry practice and on open reference ladders, and every descriptor is original text. Replace every
[bracketed]value and every row marked Example. Employment, pay-equity and anti-discrimination rules differ by country: this is a documentation format, not legal advice.
Document control
| Field | Value |
|---|---|
| Document ID | [LAD-001] |
| Version | [1.0] |
| Status | [Draft / In consultation / Approved / Superseded] |
| Owner | [@head-of-engineering] |
| Co-owner (people process) | [@people-partner] |
| Approvers/reviewers | [@cto], [@people-director], [@staff-engineer-council], [@employee-representative] |
| Effective from (promotion cycle) | [YYYY-H1 / YYYY-MM-DD] |
| Applies to | [Software, platform, data, security and quality engineering; engineering managers] |
| Does not apply to | [Product management, design, support engineering (own ladders)] |
| Number of levels | [IC: L1 to L7; Manager: M3 to M7] |
| Compensation bands document | [Link to pay band document, owned by People] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Chief Technology Officer | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| People Director | [@name] | [Decision] | YYYY-MM-DD |
| Staff+ engineer council | [@name] | [Decision] | YYYY-MM-DD |
| Employee representative or works council (where required) | [@name] | [Consulted / Agreed] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for consultation |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved after two calibration pilots at Corvid Commerce |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added operational and security ownership descriptors for L3 and L4 after review feedback |
Contents
- Purpose, principles and scope
- Roles and responsibilities
- Tracks and levels
- Competency areas
- Behaviour descriptors per level
- Expectations matrix
- Promotion process and evidence
- Calibration
- Level-change rules
- Fairness and bias checks
- Using the ladder day to day
- Review cadence and change control
- Glossary and references
1. Purpose, principles and scope
1.1 Purpose
This ladder gives every engineer and manager at [Organisation name] a shared, written answer to three questions: what is expected at my level, what does the next level look like, and how is a level decision made. It is the single reference for hiring levels, promotion decisions, development conversations and the mapping to pay bands.
1.2 Principles
| ID | Principle | What it means in practice |
|---|---|---|
| PRN-01 | Scope over activity | Levels differ by the size and ambiguity of the problems a person owns, not by hours worked or number of tickets closed |
| PRN-02 | Sustained evidence | A level is shown in several pieces of work over the evidence period (section 7.3), not by one heroic project |
| PRN-03 | Two equal tracks | The IC and manager tracks are parallel; moving to management is a change of role, not a promotion |
| PRN-04 | Holistic judgement | Descriptors guide judgement; a person does not need to show every behaviour in every area to hold a level |
| PRN-05 | Transparency | The ladder, the process and the aggregate outcomes are published to everyone in scope |
| PRN-06 | Fairness by design | Decisions use written evidence, structured criteria and calibration, and outcomes are monitored for bias (section 10) |
| PRN-07 | Security and operations are engineering | Owning what you ship in production, including its security, is part of every level, not a specialist add-on |
1.3 Scope
The ladder applies to the roles listed in Document control. Specialist families (for example data engineering, site reliability, security engineering) use the same levels and competency areas and may add a short family supplement with domain examples. A supplement may add examples; it must not change level definitions.
1.4 What the ladder does not do
- It does not set pay. Each level maps to a pay band owned by People; the band document is linked in Document control.
- It does not rate annual performance. Performance is rated against the expectations of the current level (section 11.2).
- It does not guarantee a promotion timetable. Time in level is an observation, never a criterion (section 9.1).
2. Roles and responsibilities
| Activity | Engineer | Manager | Promotion committee | Calibration facilitator | People partner | Head of Engineering |
|---|---|---|---|---|---|---|
| Maintain the ladder text | C | C | C | C | R | A |
| Self-assessment and brag document | R | C | I | I | I | I |
| Growth plan against next level | R | A | I | I | C | I |
| Nomination for promotion | C | R | I | I | I | I |
| Promotion packet | R | A | I | I | C | I |
| Level decision | I | C | R | C | C | A |
| Calibration session | I | R | C | A | C | I |
| Fairness analysis of outcomes | I | I | C | C | R | A |
| Appeal | R (raises) | C | C | I | R (runs) | A |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Promotion committee. Three to five people at least one level above the target level (for L6 and L7 cases: at the target level or above, including the CTO or M6 and above leaders), from at least two teams, with at most one person from the candidate's reporting line. At least one member has completed the bias-awareness briefing in the current year.
Calibration facilitator. A trained manager or People partner who does not manage anyone being calibrated in that session. The facilitator owns the timebox, the evidence rules and the decision log.
3. Tracks and levels
3.1 Track structure
The manager track starts at M3, aligned in scope and pay band with L3. A switch between tracks keeps the same level number where scope matches (section 9.4).
3.2 Level summary, IC track
| Level | Title (Example) | Scope of impact | Autonomy | Typical time horizon |
|---|---|---|---|---|
| L1 | Associate Engineer | Well-defined tasks within one component | Works with close guidance and frequent review | Days to one sprint |
| L2 | Engineer | Features within one service or component | Independent on defined work; asks for help early on ambiguity | One sprint to one month |
| L3 | Senior Engineer | A service or a significant feature area for one team | Fully independent; shapes how the team works | One quarter |
| L4 | Staff Engineer | Several services or a cross-team technical problem | Sets direction for a group of teams; finds the right problems | Two to four quarters |
| L5 | Senior Staff Engineer | An organisation-wide technical area | Defines strategy for an area; aligns directors | One to two years |
| L6 | Principal Engineer | Engineering-wide technical direction | Shapes company technical strategy with the CTO | Two to three years |
| L7 | Distinguished Engineer | Company and industry-level impact | Sets multi-year bets; recognised externally | Three years or more |
Career level. L3 is the career level: an engineer may stay at L3 for their whole career with full performance ratings. Promotion beyond L3 depends on business need for larger scope as well as on the person's growth.
3.3 Level summary, manager track
| Level | Title (Example) | Scope | Typical span |
|---|---|---|---|
| M3 | Engineering Manager | One team: people, delivery and operational health | 4 to 8 direct reports |
| M4 | Senior Engineering Manager | Two or three teams, or one large team with sub-leads | 8 to 20 people in the group |
| M5 | Director of Engineering | A product or platform area of several teams with managers reporting in | 20 to 60 people |
| M6 | Senior Director | Several areas; owns an organisation-wide outcome | 60 to 150 people |
| M7 | VP of Engineering | The engineering organisation or a major division | 150 people or more |
Span figures are Example values for orientation; level depends on scope and complexity, not headcount alone.
3.4 Worked example: Corvid Commerce level distribution
| Level | Engineers (Example) | Share |
|---|---|---|
| L1 | 6 | 5% |
| L2 | 34 | 28% |
| L3 | 48 | 40% |
| L4 | 18 | 15% |
| L5 | 9 | 8% |
| L6 | 4 | 3% |
| L7 | 1 | 1% |
| Total | 120 | 100% |
Example for the fictional SaaS company Corvid Commerce, IC track only. Use your own distribution as a health signal (a pyramid that is very top-heavy often means level inflation), never as a quota.
4. Competency areas
| ID | Competency area | Definition | Typical evidence sources |
|---|---|---|---|
| CMP-01 | Technical skill | Depth and breadth of engineering knowledge applied to design, code, data and tests; quality of technical judgement | Design documents, code reviews, architecture decision records, incident fixes |
| CMP-02 | Delivery | Turning goals into working, maintainable software predictably: planning, breaking down work, managing risk, finishing | Delivered milestones, change history, delivery reports, retrospectives |
| CMP-03 | Impact and scope | The size, ambiguity and business value of the problems owned, and the outcomes achieved | Product or customer metrics, strategy documents, cost or reliability results |
| CMP-04 | Collaboration and communication | Working effectively with others: clear writing and speaking, constructive review, managing disagreement, stakeholder alignment | Design discussions, RFC feedback, peer feedback, stakeholder notes |
| CMP-05 | Leadership and mentoring | Growing others and raising the standard of the group: mentoring, onboarding, hiring, setting technical or people direction | Mentee outcomes, interview participation, talks, guides written, feedback |
| CMP-06 | Operational and security ownership | Owning software in production: reliability, observability, on-call, incident response, secure design and remediation of vulnerabilities | On-call records, postmortems, SLO reports, threat models, security findings closed |
Weighting by track. All six areas apply to both tracks. For the manager track, CMP-05 expands to include people management (hiring, performance, career growth, team health) and becomes the primary area; CMP-01 shifts from personal output to the quality of technical decisions the team makes.
5. Behaviour descriptors per level
Descriptors are cumulative: a person at L4 also shows the L3 behaviours. Read each row as "consistently, over the review period".
5.1 CMP-01 Technical skill
| Level | Behaviour descriptor |
|---|---|
| L1 | Writes correct, readable code for well-specified tasks with tests; learns the team's tools, conventions and codebase; asks focused questions after attempting a problem |
| L2 | Designs and implements features within a service; chooses suitable data structures and patterns; writes tests that catch real defects; reviews peers' code for correctness |
| L3 | Designs a service or feature area end to end, including data model, interfaces and failure modes; weighs trade-offs in writing; leaves code easier to change than they found it |
| L4 | Solves technical problems that span several services or teams; produces designs other teams adopt; identifies systemic weaknesses (coupling, scaling limits) before they cause harm |
| L5 | Owns the technical direction of an organisation-wide area; defines standards and reference architectures; makes reversible and irreversible decisions at the right level of rigour |
| L6 | Shapes engineering-wide architecture and technology choices; anticipates technology shifts and positions the company for them; resolves the hardest cross-cutting technical disputes |
| L7 | Creates technical approaches that change what the company can do; recognised as an authority beyond the company through standards work, open source or publications |
5.2 CMP-02 Delivery
| Level | Behaviour descriptor |
|---|---|
| L1 | Completes assigned tasks to the agreed definition of done; raises blockers within a day; estimates own tasks with guidance |
| L2 | Breaks a feature into incremental, shippable changes; estimates reliably; delivers small changes behind flags or in safe steps; communicates progress without prompting |
| L3 | Plans and leads delivery of a multi-person project; identifies risks and dependencies early; makes scope trade-offs with product partners; ships predictably quarter to quarter |
| L4 | Leads delivery across several teams; sequences work to reduce risk; unblocks teams by resolving technical dependencies; improves delivery practices measured in the delivery performance report |
| L5 | Ensures an area delivers its multi-quarter roadmap; designs migration and rollout strategies at organisation scale; stops or reshapes work that no longer pays off |
| L6 | Aligns engineering-wide delivery with company strategy; drives programmes that no single organisation could deliver; sets delivery standards that others follow |
| L7 | Delivers outcomes that redefine the company's capabilities or market position over multiple years |
5.3 CMP-03 Impact and scope
| Level | Behaviour descriptor |
|---|---|
| L1 | Impact is on own tasks; work is chosen by others |
| L2 | Impact is on features within the team; understands why the feature matters to users |
| L3 | Impact is on the team's goals; proposes work that improves product or engineering outcomes; measures results after shipping |
| L4 | Impact is on a group of teams; finds and frames problems that nobody owns; the organisation's results are measurably different because of their work |
| L5 | Impact is on an organisation; owns an outcome tied to company objectives (revenue, cost, reliability, compliance) |
| L6 | Impact is company-wide; their judgement shapes which problems engineering works on |
| L7 | Impact extends to the industry or redefines company strategy |
5.4 CMP-04 Collaboration and communication
| Level | Behaviour descriptor |
|---|---|
| L1 | Communicates status clearly; accepts and acts on review feedback; documents own changes |
| L2 | Gives specific, kind and actionable code review; writes clear pull request descriptions and short design notes; works well with product and design partners |
| L3 | Writes design documents that others can decide on; facilitates technical discussions to a decision; handles disagreement constructively and commits once decided |
| L4 | Aligns several teams and their managers around a technical plan; adapts the message for engineers, product and executives; builds trust across team boundaries |
| L5 | Represents engineering in organisation-level decisions; resolves conflicts between groups; communicates strategy so that teams can act without them |
| L6 | Influences executive and company-wide decisions; builds coalitions for long-term change |
| L7 | Communicates the company's technical vision internally and externally; trusted voice in the industry |
5.5 CMP-05 Leadership and mentoring
| Level | Behaviour descriptor |
|---|---|
| L1 | Shares what they learn; helps teammates when asked |
| L2 | Helps onboard new team members; participates in interviews after training |
| L3 | Mentors L1 and L2 engineers with visible growth; leads parts of the hiring loop; raises the team's engineering standards by example |
| L4 | Mentors senior engineers; grows technical leaders across teams; designs interview content; is sought out for advice outside their team |
| L5 | Builds leadership depth in an area so it does not depend on them; sponsors people who have had less access to visible, stretch work, using transparent allocation of opportunities; shapes hiring standards |
| L6 | Develops staff-level engineers across the company; shapes the engineering culture and the ladder itself |
| L7 | Develops the next generation of principal engineers; their example defines what senior technical leadership means at the company |
5.6 CMP-06 Operational and security ownership
| Level | Behaviour descriptor |
|---|---|
| L1 | Follows runbooks and secure-coding guidance; fixes issues found in review and scanning; learns how their code is deployed and observed |
| L2 | Joins the on-call rotation after shadowing; adds logs, metrics and alerts with their features; fixes assigned vulnerabilities within the agreed remediation time; writes postmortem actions for their area |
| L3 | Owns the operational health of a service: SLOs, dashboards, alert quality and runbooks; leads incident response for their service; performs threat modelling for new designs; keeps dependencies current |
| L4 | Improves reliability and security across several services; leads postmortems for major incidents and drives systemic actions; partners with security on design reviews; reduces toil measurably |
| L5 | Owns the reliability and security posture of an area; sets operational and secure-design standards; ensures readiness reviews happen before launches |
| L6 | Shapes company-wide reliability, resilience and security strategy with the CTO and CISO; leads response to the most severe incidents as technical lead |
| L7 | Sets the company's long-term approach to resilience and security engineering; recognised externally in this field |
5.7 Manager track descriptors
Managers are assessed on all six areas. The table below states what changes for the manager track; other descriptors apply at the equivalent IC level.
| Level | People leadership (CMP-05) | Delivery and operations (CMP-02, CMP-06) | Technical judgement (CMP-01) |
|---|---|---|---|
| M3 | Hires, onboards and develops a team; runs regular one-to-ones and growth plans; addresses performance issues early and fairly | Team delivers predictably; owns on-call health, incident follow-up and security remediation for the team's services | Ensures the team makes sound design decisions; can review designs and challenge risk |
| M4 | Develops leads and senior engineers; builds a hiring pipeline; balances workload across teams | Group delivers a quarterly plan across teams; operational metrics improve; manages dependencies with other groups | Ensures cross-team designs are reviewed by the right people; invests in technical debt reduction |
| M5 | Develops managers; designs team structures; owns retention and engagement for the area | Owns an area roadmap and its budget; accountable for area reliability and security posture | Partners with L5 engineers on technical strategy; makes build, buy and retire decisions |
| M6 | Builds the leadership bench across areas; shapes organisation design | Owns an organisation outcome tied to company goals; manages risk at organisation level | Ensures architecture governance works across areas |
| M7 | Leads the engineering leadership team; owns engineering culture, ladder and hiring standards | Accountable for engineering delivery, cost, reliability and security to the executive team | Sets engineering strategy with the CTO and principal engineers |
6. Expectations matrix
6.1 Rating vocabulary
| Rating | Meaning |
|---|---|
| Developing | Shows the behaviours of this level sometimes or with support |
| Consistent | Shows the behaviours of this level consistently and independently |
| Strong | Consistently shows behaviours of the next level in this area |
6.2 Minimum profile per level
The table shows the profile a person needs to hold a level. To be promoted to a level, the person shows that level's profile, with evidence, before the promotion (section 7.3).
| Area | L1 | L2 | L3 | L4 | L5 | L6 | L7 |
|---|---|---|---|---|---|---|---|
| CMP-01 Technical skill | Consistent | Consistent | Consistent | Consistent | Consistent | Consistent | Consistent |
| CMP-02 Delivery | Developing | Consistent | Consistent | Consistent | Consistent | Consistent | Consistent |
| CMP-03 Impact and scope | Developing | Developing | Consistent | Consistent | Consistent | Consistent | Consistent |
| CMP-04 Collaboration | Developing | Consistent | Consistent | Consistent | Consistent | Consistent | Consistent |
| CMP-05 Leadership | Developing | Developing | Developing | Consistent | Consistent | Consistent | Consistent |
| CMP-06 Operations and security | Developing | Developing | Consistent | Consistent | Consistent | Consistent | Consistent |
| Allowed "Developing" areas | 5 | 3 | 1 | 0 | 0 | 0 | 0 |
| Primary areas | 01 | 01, 02 | 01, 02, 06 | 01, 03, 04 | 03, 04, 05 | 03, 04, 05 | 03, 05 |
The "Allowed Developing" row counts the areas rated Developing in the same column: for example L3 allows one, which is CMP-05. Primary areas carry most weight in calibration when evidence is mixed.
6.3 Archetypes for L4 and above
Senior IC roles take different shapes. Calibrate against the archetype the person actually plays, with the same level bar.
| Archetype | Typical focus | Strongest areas |
|---|---|---|
| Tech lead | Direction and delivery for one large team or a few small teams | CMP-02, CMP-04 |
| Architect | Cross-team design and technical coherence of an area | CMP-01, CMP-03 |
| Solver | Deep work on the hardest, highest-risk problems | CMP-01, CMP-06 |
| Right hand | Extends a senior leader's reach across the organisation | CMP-03, CMP-04 |
7. Promotion process and evidence
7.1 Cycle
Promotions run [twice a year] on a fixed calendar published at the start of the year. Out-of-cycle promotions are limited to the cases in section 9.3.
| Step | Owner | Timing (Example) | Output |
|---|---|---|---|
| Nomination window opens | People partner | Week 1 | Nomination list |
| Packet drafted | Candidate and manager | Weeks 1 to 3 | Promotion packet (career/promotion-packet) |
| Feedback collected | Manager | Weeks 2 to 3 | Three to five written peer and stakeholder statements |
| Committee review | Promotion committee | Week 4 | Recommendation with rationale per area |
| Calibration | Calibration facilitator | Week 5 | Calibrated decisions and decision log |
| Communication | Manager | Week 6 | Conversation plus written outcome |
| Fairness review | People partner | Week 7 | Cycle fairness report (section 10) |
7.2 Nomination
- Managers must review every direct report against the next level once per cycle and record "nominate", "not yet, with gaps" or "not seeking" after talking with the person.
- Engineers may self-nominate. A self-nomination is reviewed by the committee even if the manager disagrees; the manager then adds a written view.
- Skip-level managers should check that nomination rates do not differ unexplained between teams.
7.3 Evidence rules
| Rule | Detail |
|---|---|
| EVD-01 Period | Evidence comes from the last 6 to 12 months; older evidence only shows trajectory |
| EVD-02 Specific | Each claim links to an artefact (design document, pull request, postmortem, metric, written feedback) |
| EVD-03 Attributable | The candidate's own contribution is stated separately from the team's |
| EVD-04 Mapped | Each piece of evidence is mapped to a competency ID and a target-level descriptor |
| EVD-05 Balanced | The packet names gaps as well as strengths; an honest packet is a stronger packet |
| EVD-06 Outcome-focused | Results (what changed) count more than activity (what was done) |
| EVD-07 Sustained | The target-level profile is shown in at least two separate pieces of work |
| EVD-08 Accessible | Evidence is written so a committee member outside the team can assess it without jargon |
7.4 Worked example: evidence map
| Promotion | Competency | Evidence | Target-level descriptor met |
|---|---|---|---|
| PRM-2026-014 (Example) L3 to L4 | CMP-01 | Event pipeline redesign adopted by checkout and payments teams (design document DD-212) | Designs other teams adopt |
| PRM-2026-014 (Example) | CMP-03 | Order-event lag fell from minutes to seconds, removing a top-three support complaint | Organisation's results measurably different |
| PRM-2026-014 (Example) | CMP-04 | Facilitated four-team agreement on event schema ownership; written decision ADR-031 | Aligns several teams around a technical plan |
| PRM-2026-014 (Example) | CMP-06 | Led postmortem for incident INC-0412 and delivered the three systemic actions | Leads postmortems for major incidents |
| PRM-2026-014 (Example) | CMP-05 | Mentored two L2 engineers, both now leading features | Mentors and grows engineers; cross-team reach is a next-level growth area |
7.5 Communicating outcomes
Communicate every outcome in a live conversation first, then in writing within [five working days]. A "not yet" outcome must include the specific gaps by competency ID, with examples of evidence that would close them, so the next growth plan starts from facts.
7.6 Appeals
A candidate may appeal within [15 working days] on process grounds (a rule in this ladder was not followed, evidence was ignored or misread). The People partner runs the appeal with a reviewer who was not on the committee. The appeal outcome is final for the cycle.
8. Calibration
8.1 Purpose and inputs
Calibration compares level decisions across teams so that evidence of the same strength leads to the same outcome. Inputs are the packets, the committee recommendations and the expectations matrix. Ratings from performance reviews are not inputs to level decisions.
8.2 Session rules
- The facilitator restates the level bar and the evidence rules before discussing any case.
- Cases are discussed in random order, not grouped by team or by manager seniority.
- The committee lead summarises each case in two minutes; the manager adds facts only, then leaves the advocacy to the evidence.
- Discussion refers to competency IDs and artefacts. Statements about personality, "presence", availability outside working hours or likeability are stopped by the facilitator.
- Each case ends with a decision (promote / not yet) and a one-line rationale in the decision log, with dissent recorded.
- At the end, the group reviews the decisions together for consistency: compare similar cases side by side.
- Distributions are reviewed for anomalies (section 10). There is no forced distribution or quota.
8.3 Decision log fields
| Field | Example (Example) |
|---|---|
| Case ID | PRM-2026-014 |
| Current and target level | L3 to L4 |
| Decision | Promote |
| Primary-area evidence | CMP-01 Consistent, CMP-03 Consistent, CMP-04 Consistent |
| Gaps noted | None below the L4 bar; CMP-05 rated Consistent at L4 (mentored two L2 engineers to feature leads); cross-team mentoring is a growth area for L5 |
| Dissent | None |
| Facilitator | [@facilitator] |
9. Level-change rules
9.1 Promotion
- Promotion is one level at a time. Skipping a level is not allowed.
- There is no minimum time in level. Time in level is reported for fairness monitoring only.
- Promotion recognises demonstrated performance at the next level; it is not used to retain someone who has an outside offer unless the evidence already meets the bar.
9.2 Hiring level
New hires are levelled using the interview evidence and the Technical Interview Rubric (career/technical-interview-rubric). Years of experience inform but never decide the level. If evidence is borderline, hire at the lower level and state in the offer the evidence that would support an early review at the first cycle.
9.3 Out-of-cycle changes
Allowed only when the scope of the role changes materially and immediately (for example, a new team is formed and the person leads it). The committee reviews the case with the same evidence rules.
9.4 Track switch
| Switch | Rule |
|---|---|
| IC to manager (L3 or L4 to M3 or M4) | Lateral move to the level with matching scope; a trial period of [six months] with an agreed path back without penalty |
| Manager to IC (M3 or M4 to L3 or L4) | Lateral move; the person is assessed against the IC descriptors from the next cycle |
| M5 and above to IC | Levelled by the committee against L5 to L7 descriptors; not automatic |
9.5 Re-levelling down
Re-levelling to a lower level happens only by mutual agreement (for example a request to reduce scope) or after a documented performance process run by People under local employment law. It is never a calibration outcome by itself. Pay protection rules are set in the pay band document.
9.6 Family supplements and specialists
Specialist families (SRE, security, data) use the same level numbers. A specialist at L4 is held to the same scope bar as any L4.
10. Fairness and bias checks
10.1 Process controls
| ID | Control | When |
|---|---|---|
| FAIR-01 | Descriptors reviewed for gendered, ableist or culturally narrow wording | Each ladder revision |
| FAIR-02 | Every eligible engineer reviewed against the next level by their manager | Each cycle |
| FAIR-03 | Packet format and length fixed for everyone | Each cycle |
| FAIR-04 | Committee and facilitator briefed on common evaluation biases (recency, halo, affinity, attribution of team success) | Annually and before each cycle |
| FAIR-05 | Evidence that depends on unequal access (high-visibility projects, after-hours availability) is challenged; managers record how stretch work was allocated | Each cycle |
| FAIR-06 | Part-time and leave periods are pro-rated, not counted as gaps | Each cycle |
| FAIR-07 | Outcome analysis by group with an action plan when gaps appear | After each cycle |
| FAIR-08 | Ladder and pay-band criteria checked for gender neutrality and published to workers (EU Pay Transparency Directive Art. 6 where transposed) | Each ladder revision |
10.2 Outcome metrics
| Metric | Formula | Signal |
|---|---|---|
| Nomination rate | nominated engineers in group / eligible engineers in group | Unequal access to sponsorship |
| Promotion rate | promoted engineers in group / eligible engineers in group | Unequal outcomes |
| Impact ratio (selection-rate ratio) | promotion rate of group / promotion rate of the group with the highest rate | Investigate when the ratio is below [0.8] (Example threshold) |
| Median time in level | median months in current level, per group | Slower progression for some groups |
| Not-yet with written gaps | "not yet" outcomes with written gaps / all "not yet" outcomes | Should be 100% |
The impact ratio threshold mirrors the four-fifths guideline used in US employment selection monitoring (29 CFR Part 1607, section 1607.4). It is a screening signal for investigation, not a legal test or a target. In small groups, ratios swing widely; look at several cycles together and seek specialist advice before drawing conclusions. As of October 2026 the EEOC has announced plans to rescind the Uniform Guidelines, and a June 2026 US Department of Justice opinion questions parts of them; they remain codified, and Title VII disparate-impact claims remain available to private plaintiffs. Check their current status before relying on them. The screening check stays useful whatever their status, because unexplained gaps in outcomes are a ladder-quality problem as well as a legal one.
EU pay transparency. Where the ladder maps to pay bands, it is also the main evidence for the pay-progression transparency duty in the EU Pay Transparency Directive (Directive (EU) 2023/970, Article 6): employers make the criteria used for pay, pay levels and pay progression easily accessible to workers, and those criteria are objective and gender-neutral. Member States may exempt employers with fewer than 50 workers from the pay-progression part. The transposition deadline was 7 June 2026 and national laws differ in timing and detail; check the national law that applies to you.
10.3 Data handling
Process demographic data only where local law allows, on a stated lawful basis (under the GDPR, also an Article 9(2) condition for special-category data; in the UK, the equality-of-opportunity monitoring condition in DPA 2018 Schedule 1 paragraph 8), with access limited to the People team, and report aggregates only (suppress any group smaller than [five] people).
10.4 Worked example
| Group (Example) | Eligible | Promoted | Promotion rate | Impact ratio |
|---|---|---|---|---|
| Group A | 40 | 8 | 20.0% | 1.00 |
| Group B | 25 | 3 | 12.0% | 0.60 |
Example: Group B's ratio (12.0 / 20.0 = 0.60) is below 0.8, so the People partner reviews nomination rates and stretch-work allocation for Group B and reports findings to the Head of Engineering before the next cycle.
11. Using the ladder day to day
11.1 Growth conversations
Managers hold a growth conversation at least [quarterly]: pick one or two competency areas, agree concrete opportunities (a project, a review role, an incident lead), and record evidence as it happens in a Brag Document (career/brag-document).
11.2 Performance reviews
Performance reviews (career/performance-review) rate results against the current level's expectations. A high performance rating does not by itself mean readiness for the next level, and a promotion does not require a top performance rating.
11.3 Hiring and onboarding
Job descriptions (career/job-description) quote the level summary and the primary areas. New hires receive the ladder in their first week, and the 90-Day Plan (career/ninety-day-plan) and Onboarding Guide (dev/onboarding-guide) set first goals against current-level descriptors.
11.4 Links to other programmes
- Security champions (
security/security-champions-program): count champion work as CMP-06 and CMP-05 evidence. - Engineering strategy (
dev/engineering-strategy): staff-level roles should map to strategic problems named there. - Delivery and developer experience data (
dev/delivery-performance-report,dev/developer-experience-survey): team-level signals; never use them to rate an individual.
12. Review cadence and change control
| Activity | Cadence (Example) | Owner |
|---|---|---|
| Minor wording fixes and examples | Any time, published with a version bump | Ladder owner |
| Full review of descriptors and matrix | Annually, after the second promotion cycle | Head of Engineering with staff+ council |
| Survey of engineers and managers on clarity | Annually | People partner |
| Fairness outcome review | After each cycle | People partner |
Change rules.
- Changes are proposed as change requests (LAD-CHG-NNN) with the reason and the affected IDs.
- Material changes (level definitions, matrix, process rules) take effect at the start of a cycle, never during one, and are announced at least [one cycle] ahead.
- Candidates in an open cycle are assessed against the version that was effective when the cycle opened.
- Keep competency and level IDs stable; retire an ID rather than reuse it.
| Change request | Summary | Decision | Effective |
|---|---|---|---|
| LAD-CHG-003 (Example) | Add AI-assisted development expectations to CMP-01 and CMP-06 (review of generated code, data handling) | Approved | Next cycle start |
Health metrics for the ladder. Track the share of "not yet" outcomes later overturned on appeal, calibration changes to committee recommendations, and survey clarity scores; rising numbers show the descriptors need work.
13. Glossary and references
13.1 Glossary
| Term | Definition |
|---|---|
| Archetype | A recognised shape of a senior IC role (tech lead, architect, solver, right hand) held to the same level bar |
| Calibration | A cross-team session that compares level decisions to keep the bar consistent |
| Career level | The level at which a person may stay indefinitely with full performance ratings (L3 here) |
| Competency area | One of the six observable dimensions used to assess level (CMP-01 to CMP-06) |
| Descriptor | A written description of behaviour expected at one level in one area |
| IC | Individual contributor: an engineer without direct reports |
| Packet | The written promotion case with mapped evidence |
| Impact ratio | One group's selection (promotion) rate divided by the highest group's rate; a monitoring signal, also called the selection-rate ratio |
| Track | A career path (IC or manager) with its own levels |
13.2 References
| Reference | Version or date checked | Use |
|---|---|---|
| Engineering Ladders, Jorge Fioranelli, github.com/jorgef/engineeringladders | Apache-2.0; repository checked 2026-10-24 | Inspiration for separating technology, system, people, process and influence dimensions; no text reused |
| Uniform Guidelines on Employee Selection Procedures (1978), 29 CFR Part 1607, law.cornell.edu/cfr/text/29/part-1607 | Checked 2026-10-24; EEOC rescission planned and June 2026 DOJ opinion questions parts: check current status | Background for impact-ratio monitoring (impact information, section 1607.4) |
| Directive (EU) 2023/970 (Pay Transparency), Article 6, eur-lex.europa.eu/eli/dir/2023/970/oj | Transposition deadline 2026-06-07; check national law | Progression criteria must be objective, gender-neutral and accessible to workers |
| Regulation (EU) 2016/679 (GDPR), Article 9; UK Data Protection Act 2018, Schedule 1 | Current consolidated texts | Conditions for processing demographic data in fairness monitoring |
| Acas, Interviewing job applicants and Following discrimination law, acas.org.uk | Page updated 2026-06-30 | Background on consistent, fair assessment in the UK |
| Equality Act 2010 (UK), legislation.gov.uk | Current consolidated text | Protected characteristics context for fairness checks |
Technical Interview Rubric (career/technical-interview-rubric) | This collection | Hiring-level evidence mapped to the same IDs |
Promotion Packet (career/promotion-packet) | This collection | Candidate packet format |
Standard and licence note
Structure aligned with common industry practice for engineering career frameworks, with inspiration from the open Engineering Ladders project by Jorge Fioranelli (Apache-2.0). No text, table or level wording is copied from that project or from any other ladder; all descriptors are original text written for this collection. Fairness monitoring references the Uniform Guidelines on Employee Selection Procedures (29 CFR Part 1607, a US government publication, whose rescission the EEOC has announced it plans), the EU Pay Transparency Directive (Directive (EU) 2023/970) and UK Acas guidance for context only; check the current official versions and the law that applies to your organisation before use. This is a documentation format, not legal advice. Template licence: MIT.
관련 템플릿
Academic CV Template
Academic CV: education, appointments, publications by type with citation styles, grants, teaching, supervision, service, talks
커리어ATS-Friendly Resume Template
Single-column ATS resume with standard headings, keyword alignment table against the job posting, formatting rules, test steps
커리어Brag Document Template
Brag doc – running record of your work