Markdown Editor

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

CarreraCompletaNo formal standard; open reference ladders (Engineering Ladders, Apache-2.0)engineeringladder

Cómo usar: 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.

Vista previa

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

FieldValue
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 updatedYYYY-MM-DD
Next scheduled reviewYYYY-MM-DD
Classification[Internal]

Approvals

RoleNameDecisionDate
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

VersionDateAuthorChange summary
0.1YYYY-MM-DD[@name]First draft for consultation
1.0YYYY-MM-DD[@name]Example: Approved after two calibration pilots at Corvid Commerce
1.1YYYY-MM-DD[@name]Example: Added operational and security ownership descriptors for L3 and L4 after review feedback

Contents

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

IDPrincipleWhat it means in practice
PRN-01Scope over activityLevels differ by the size and ambiguity of the problems a person owns, not by hours worked or number of tickets closed
PRN-02Sustained evidenceA level is shown in several pieces of work over the evidence period (section 7.3), not by one heroic project
PRN-03Two equal tracksThe IC and manager tracks are parallel; moving to management is a change of role, not a promotion
PRN-04Holistic judgementDescriptors guide judgement; a person does not need to show every behaviour in every area to hold a level
PRN-05TransparencyThe ladder, the process and the aggregate outcomes are published to everyone in scope
PRN-06Fairness by designDecisions use written evidence, structured criteria and calibration, and outcomes are monitored for bias (section 10)
PRN-07Security and operations are engineeringOwning 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

ActivityEngineerManagerPromotion committeeCalibration facilitatorPeople partnerHead of Engineering
Maintain the ladder textCCCCRA
Self-assessment and brag documentRCIIII
Growth plan against next levelRAIICI
Nomination for promotionCRIIII
Promotion packetRAIICI
Level decisionICRCCA
Calibration sessionIRCACI
Fairness analysis of outcomesIICCRA
AppealR (raises)CCIR (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

LevelTitle (Example)Scope of impactAutonomyTypical time horizon
L1Associate EngineerWell-defined tasks within one componentWorks with close guidance and frequent reviewDays to one sprint
L2EngineerFeatures within one service or componentIndependent on defined work; asks for help early on ambiguityOne sprint to one month
L3Senior EngineerA service or a significant feature area for one teamFully independent; shapes how the team worksOne quarter
L4Staff EngineerSeveral services or a cross-team technical problemSets direction for a group of teams; finds the right problemsTwo to four quarters
L5Senior Staff EngineerAn organisation-wide technical areaDefines strategy for an area; aligns directorsOne to two years
L6Principal EngineerEngineering-wide technical directionShapes company technical strategy with the CTOTwo to three years
L7Distinguished EngineerCompany and industry-level impactSets multi-year bets; recognised externallyThree 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

LevelTitle (Example)ScopeTypical span
M3Engineering ManagerOne team: people, delivery and operational health4 to 8 direct reports
M4Senior Engineering ManagerTwo or three teams, or one large team with sub-leads8 to 20 people in the group
M5Director of EngineeringA product or platform area of several teams with managers reporting in20 to 60 people
M6Senior DirectorSeveral areas; owns an organisation-wide outcome60 to 150 people
M7VP of EngineeringThe engineering organisation or a major division150 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

LevelEngineers (Example)Share
L165%
L23428%
L34840%
L41815%
L598%
L643%
L711%
Total120100%

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

IDCompetency areaDefinitionTypical evidence sources
CMP-01Technical skillDepth and breadth of engineering knowledge applied to design, code, data and tests; quality of technical judgementDesign documents, code reviews, architecture decision records, incident fixes
CMP-02DeliveryTurning goals into working, maintainable software predictably: planning, breaking down work, managing risk, finishingDelivered milestones, change history, delivery reports, retrospectives
CMP-03Impact and scopeThe size, ambiguity and business value of the problems owned, and the outcomes achievedProduct or customer metrics, strategy documents, cost or reliability results
CMP-04Collaboration and communicationWorking effectively with others: clear writing and speaking, constructive review, managing disagreement, stakeholder alignmentDesign discussions, RFC feedback, peer feedback, stakeholder notes
CMP-05Leadership and mentoringGrowing others and raising the standard of the group: mentoring, onboarding, hiring, setting technical or people directionMentee outcomes, interview participation, talks, guides written, feedback
CMP-06Operational and security ownershipOwning software in production: reliability, observability, on-call, incident response, secure design and remediation of vulnerabilitiesOn-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

LevelBehaviour descriptor
L1Writes correct, readable code for well-specified tasks with tests; learns the team's tools, conventions and codebase; asks focused questions after attempting a problem
L2Designs and implements features within a service; chooses suitable data structures and patterns; writes tests that catch real defects; reviews peers' code for correctness
L3Designs 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
L4Solves technical problems that span several services or teams; produces designs other teams adopt; identifies systemic weaknesses (coupling, scaling limits) before they cause harm
L5Owns the technical direction of an organisation-wide area; defines standards and reference architectures; makes reversible and irreversible decisions at the right level of rigour
L6Shapes engineering-wide architecture and technology choices; anticipates technology shifts and positions the company for them; resolves the hardest cross-cutting technical disputes
L7Creates 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

LevelBehaviour descriptor
L1Completes assigned tasks to the agreed definition of done; raises blockers within a day; estimates own tasks with guidance
L2Breaks a feature into incremental, shippable changes; estimates reliably; delivers small changes behind flags or in safe steps; communicates progress without prompting
L3Plans 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
L4Leads delivery across several teams; sequences work to reduce risk; unblocks teams by resolving technical dependencies; improves delivery practices measured in the delivery performance report
L5Ensures an area delivers its multi-quarter roadmap; designs migration and rollout strategies at organisation scale; stops or reshapes work that no longer pays off
L6Aligns engineering-wide delivery with company strategy; drives programmes that no single organisation could deliver; sets delivery standards that others follow
L7Delivers outcomes that redefine the company's capabilities or market position over multiple years

5.3 CMP-03 Impact and scope

LevelBehaviour descriptor
L1Impact is on own tasks; work is chosen by others
L2Impact is on features within the team; understands why the feature matters to users
L3Impact is on the team's goals; proposes work that improves product or engineering outcomes; measures results after shipping
L4Impact is on a group of teams; finds and frames problems that nobody owns; the organisation's results are measurably different because of their work
L5Impact is on an organisation; owns an outcome tied to company objectives (revenue, cost, reliability, compliance)
L6Impact is company-wide; their judgement shapes which problems engineering works on
L7Impact extends to the industry or redefines company strategy

5.4 CMP-04 Collaboration and communication

LevelBehaviour descriptor
L1Communicates status clearly; accepts and acts on review feedback; documents own changes
L2Gives specific, kind and actionable code review; writes clear pull request descriptions and short design notes; works well with product and design partners
L3Writes design documents that others can decide on; facilitates technical discussions to a decision; handles disagreement constructively and commits once decided
L4Aligns several teams and their managers around a technical plan; adapts the message for engineers, product and executives; builds trust across team boundaries
L5Represents engineering in organisation-level decisions; resolves conflicts between groups; communicates strategy so that teams can act without them
L6Influences executive and company-wide decisions; builds coalitions for long-term change
L7Communicates the company's technical vision internally and externally; trusted voice in the industry

5.5 CMP-05 Leadership and mentoring

LevelBehaviour descriptor
L1Shares what they learn; helps teammates when asked
L2Helps onboard new team members; participates in interviews after training
L3Mentors L1 and L2 engineers with visible growth; leads parts of the hiring loop; raises the team's engineering standards by example
L4Mentors senior engineers; grows technical leaders across teams; designs interview content; is sought out for advice outside their team
L5Builds 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
L6Develops staff-level engineers across the company; shapes the engineering culture and the ladder itself
L7Develops 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

LevelBehaviour descriptor
L1Follows runbooks and secure-coding guidance; fixes issues found in review and scanning; learns how their code is deployed and observed
L2Joins 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
L3Owns 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
L4Improves reliability and security across several services; leads postmortems for major incidents and drives systemic actions; partners with security on design reviews; reduces toil measurably
L5Owns the reliability and security posture of an area; sets operational and secure-design standards; ensures readiness reviews happen before launches
L6Shapes company-wide reliability, resilience and security strategy with the CTO and CISO; leads response to the most severe incidents as technical lead
L7Sets 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.

LevelPeople leadership (CMP-05)Delivery and operations (CMP-02, CMP-06)Technical judgement (CMP-01)
M3Hires, onboards and develops a team; runs regular one-to-ones and growth plans; addresses performance issues early and fairlyTeam delivers predictably; owns on-call health, incident follow-up and security remediation for the team's servicesEnsures the team makes sound design decisions; can review designs and challenge risk
M4Develops leads and senior engineers; builds a hiring pipeline; balances workload across teamsGroup delivers a quarterly plan across teams; operational metrics improve; manages dependencies with other groupsEnsures cross-team designs are reviewed by the right people; invests in technical debt reduction
M5Develops managers; designs team structures; owns retention and engagement for the areaOwns an area roadmap and its budget; accountable for area reliability and security posturePartners with L5 engineers on technical strategy; makes build, buy and retire decisions
M6Builds the leadership bench across areas; shapes organisation designOwns an organisation outcome tied to company goals; manages risk at organisation levelEnsures architecture governance works across areas
M7Leads the engineering leadership team; owns engineering culture, ladder and hiring standardsAccountable for engineering delivery, cost, reliability and security to the executive teamSets engineering strategy with the CTO and principal engineers

6. Expectations matrix

6.1 Rating vocabulary

RatingMeaning
DevelopingShows the behaviours of this level sometimes or with support
ConsistentShows the behaviours of this level consistently and independently
StrongConsistently 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).

AreaL1L2L3L4L5L6L7
CMP-01 Technical skillConsistentConsistentConsistentConsistentConsistentConsistentConsistent
CMP-02 DeliveryDevelopingConsistentConsistentConsistentConsistentConsistentConsistent
CMP-03 Impact and scopeDevelopingDevelopingConsistentConsistentConsistentConsistentConsistent
CMP-04 CollaborationDevelopingConsistentConsistentConsistentConsistentConsistentConsistent
CMP-05 LeadershipDevelopingDevelopingDevelopingConsistentConsistentConsistentConsistent
CMP-06 Operations and securityDevelopingDevelopingConsistentConsistentConsistentConsistentConsistent
Allowed "Developing" areas5310000
Primary areas0101, 0201, 02, 0601, 03, 0403, 04, 0503, 04, 0503, 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.

ArchetypeTypical focusStrongest areas
Tech leadDirection and delivery for one large team or a few small teamsCMP-02, CMP-04
ArchitectCross-team design and technical coherence of an areaCMP-01, CMP-03
SolverDeep work on the hardest, highest-risk problemsCMP-01, CMP-06
Right handExtends a senior leader's reach across the organisationCMP-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.

StepOwnerTiming (Example)Output
Nomination window opensPeople partnerWeek 1Nomination list
Packet draftedCandidate and managerWeeks 1 to 3Promotion packet (career/promotion-packet)
Feedback collectedManagerWeeks 2 to 3Three to five written peer and stakeholder statements
Committee reviewPromotion committeeWeek 4Recommendation with rationale per area
CalibrationCalibration facilitatorWeek 5Calibrated decisions and decision log
CommunicationManagerWeek 6Conversation plus written outcome
Fairness reviewPeople partnerWeek 7Cycle 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

RuleDetail
EVD-01 PeriodEvidence comes from the last 6 to 12 months; older evidence only shows trajectory
EVD-02 SpecificEach claim links to an artefact (design document, pull request, postmortem, metric, written feedback)
EVD-03 AttributableThe candidate's own contribution is stated separately from the team's
EVD-04 MappedEach piece of evidence is mapped to a competency ID and a target-level descriptor
EVD-05 BalancedThe packet names gaps as well as strengths; an honest packet is a stronger packet
EVD-06 Outcome-focusedResults (what changed) count more than activity (what was done)
EVD-07 SustainedThe target-level profile is shown in at least two separate pieces of work
EVD-08 AccessibleEvidence is written so a committee member outside the team can assess it without jargon

7.4 Worked example: evidence map

PromotionCompetencyEvidenceTarget-level descriptor met
PRM-2026-014 (Example) L3 to L4CMP-01Event pipeline redesign adopted by checkout and payments teams (design document DD-212)Designs other teams adopt
PRM-2026-014 (Example)CMP-03Order-event lag fell from minutes to seconds, removing a top-three support complaintOrganisation's results measurably different
PRM-2026-014 (Example)CMP-04Facilitated four-team agreement on event schema ownership; written decision ADR-031Aligns several teams around a technical plan
PRM-2026-014 (Example)CMP-06Led postmortem for incident INC-0412 and delivered the three systemic actionsLeads postmortems for major incidents
PRM-2026-014 (Example)CMP-05Mentored two L2 engineers, both now leading featuresMentors 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

  1. The facilitator restates the level bar and the evidence rules before discussing any case.
  2. Cases are discussed in random order, not grouped by team or by manager seniority.
  3. The committee lead summarises each case in two minutes; the manager adds facts only, then leaves the advocacy to the evidence.
  4. Discussion refers to competency IDs and artefacts. Statements about personality, "presence", availability outside working hours or likeability are stopped by the facilitator.
  5. Each case ends with a decision (promote / not yet) and a one-line rationale in the decision log, with dissent recorded.
  6. At the end, the group reviews the decisions together for consistency: compare similar cases side by side.
  7. Distributions are reviewed for anomalies (section 10). There is no forced distribution or quota.

8.3 Decision log fields

FieldExample (Example)
Case IDPRM-2026-014
Current and target levelL3 to L4
DecisionPromote
Primary-area evidenceCMP-01 Consistent, CMP-03 Consistent, CMP-04 Consistent
Gaps notedNone 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
DissentNone
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

SwitchRule
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 ICLevelled 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

IDControlWhen
FAIR-01Descriptors reviewed for gendered, ableist or culturally narrow wordingEach ladder revision
FAIR-02Every eligible engineer reviewed against the next level by their managerEach cycle
FAIR-03Packet format and length fixed for everyoneEach cycle
FAIR-04Committee and facilitator briefed on common evaluation biases (recency, halo, affinity, attribution of team success)Annually and before each cycle
FAIR-05Evidence that depends on unequal access (high-visibility projects, after-hours availability) is challenged; managers record how stretch work was allocatedEach cycle
FAIR-06Part-time and leave periods are pro-rated, not counted as gapsEach cycle
FAIR-07Outcome analysis by group with an action plan when gaps appearAfter each cycle
FAIR-08Ladder 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

MetricFormulaSignal
Nomination ratenominated engineers in group / eligible engineers in groupUnequal access to sponsorship
Promotion ratepromoted engineers in group / eligible engineers in groupUnequal outcomes
Impact ratio (selection-rate ratio)promotion rate of group / promotion rate of the group with the highest rateInvestigate when the ratio is below [0.8] (Example threshold)
Median time in levelmedian months in current level, per groupSlower progression for some groups
Not-yet with written gaps"not yet" outcomes with written gaps / all "not yet" outcomesShould 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)EligiblePromotedPromotion rateImpact ratio
Group A40820.0%1.00
Group B25312.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

ActivityCadence (Example)Owner
Minor wording fixes and examplesAny time, published with a version bumpLadder owner
Full review of descriptors and matrixAnnually, after the second promotion cycleHead of Engineering with staff+ council
Survey of engineers and managers on clarityAnnuallyPeople partner
Fairness outcome reviewAfter each cyclePeople partner

Change rules.

  1. Changes are proposed as change requests (LAD-CHG-NNN) with the reason and the affected IDs.
  2. 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.
  3. Candidates in an open cycle are assessed against the version that was effective when the cycle opened.
  4. Keep competency and level IDs stable; retire an ID rather than reuse it.
Change requestSummaryDecisionEffective
LAD-CHG-003 (Example)Add AI-assisted development expectations to CMP-01 and CMP-06 (review of generated code, data handling)ApprovedNext 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

TermDefinition
ArchetypeA recognised shape of a senior IC role (tech lead, architect, solver, right hand) held to the same level bar
CalibrationA cross-team session that compares level decisions to keep the bar consistent
Career levelThe level at which a person may stay indefinitely with full performance ratings (L3 here)
Competency areaOne of the six observable dimensions used to assess level (CMP-01 to CMP-06)
DescriptorA written description of behaviour expected at one level in one area
ICIndividual contributor: an engineer without direct reports
PacketThe written promotion case with mapped evidence
Impact ratioOne group's selection (promotion) rate divided by the highest group's rate; a monitoring signal, also called the selection-rate ratio
TrackA career path (IC or manager) with its own levels

13.2 References

ReferenceVersion or date checkedUse
Engineering Ladders, Jorge Fioranelli, github.com/jorgef/engineeringladdersApache-2.0; repository checked 2026-10-24Inspiration 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-1607Checked 2026-10-24; EEOC rescission planned and June 2026 DOJ opinion questions parts: check current statusBackground 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/ojTransposition deadline 2026-06-07; check national lawProgression criteria must be objective, gender-neutral and accessible to workers
Regulation (EU) 2016/679 (GDPR), Article 9; UK Data Protection Act 2018, Schedule 1Current consolidated textsConditions for processing demographic data in fairness monitoring
Acas, Interviewing job applicants and Following discrimination law, acas.org.ukPage updated 2026-06-30Background on consistent, fair assessment in the UK
Equality Act 2010 (UK), legislation.gov.ukCurrent consolidated textProtected characteristics context for fairness checks
Technical Interview Rubric (career/technical-interview-rubric)This collectionHiring-level evidence mapped to the same IDs
Promotion Packet (career/promotion-packet)This collectionCandidate 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.

Plantillas relacionadas