Career Ladder Design
Build transparent, accessible frameworks that show how engineers grow and advance in your organization.
Context
You are a senior tech lead designing a career ladder for $ARGUMENTS. Clear ladders reduce confusion, enable self-direction, and ensure fairness in promotions. Vague paths breed resentment and talent loss.
Domain Context
- Tanya Reilly's "Lateral Moves" — growth paths beyond management. Staff engineer, architect, and IC track should feel as valued as management.
- Ladder transparency (Stripe, Rent the Runway) — public ladders reduce politics and bias. Engineers know exactly what success looks like.
- Role clarity prevents drift: Undefined responsibilities lead to scope creep and burnout. Ladders define what each level actually does.
- Compensation alignment — each ladder level should have corresponding salary band. Misalignment creates rage-quit scenarios.
Instructions
Define ladder tracks: Design separate tracks for individual contributors (IC), technical leadership (staff/principal), and management. Clarify that all tracks have equal status and compensation potential.
Document level expectations: For each level (junior, mid, senior, staff), write 3-5 sentences per dimension: technical impact (complexity of problems owned), scope (team influence), execution (delivery velocity), and leadership (mentoring/design influence).
Establish clear criteria: Each level needs 3-4 concrete, evaluable criteria. Example for Senior: "Leads design of systems impacting 2+ teams," "Mentors 2+ engineers," "Delivers on-time 95%+ of commitments." Vague criteria breed dispute.
Create advancement rubric: Document how promotions are assessed. Example: "Senior→Staff requires peer review, 360 feedback, demonstrated influence on 3+ projects, and explicit recommendation from director." Remove surprise from promotion conversations.
Include examples and compensation bands: Real-world examples of people at each level make rubrics concrete. Show salary ranges so engineers know growth opportunity. Update ranges annually to match market.
Anti-Patterns
- Management-only ladders: Treating IC roles as dead-ends while management grows infinitely. This loses excellent engineers and forces false promotions to management.
- Vague promotion criteria: Saying "needs to demonstrate leadership" without specifying what that means. Different managers interpret differently. Promotion becomes political.
- Perpetual junior level: Some companies have junior→mid but no clear path to senior. Engineers plateau and leave. Always show 3+ visible levels.
- No tie to compensation: Showing ladder levels but not salary bands. Creates perception that promotions are meaningless. Be transparent about money.
- No reviews or updates: Static ladders that ignore market or technology shift. After 3 years, criteria no longer match reality. Review and update annually.
Further Reading
- An Elegant Puzzle (Will Larson) - team design and IC progression models
- Tanya Reilly's "Staff Engineer" book - navigating high-level IC roles
- Stripe's public career framework (engineering-levels.readthedocs.io) - reference implementation
- "Progression Without Management" (Camille Fournier, Medium)
1---2name: career-ladder-design3description: Create transparent role progression frameworks showing how engineers advance within technical and lateral tracks. Use when defining career paths and promotion criteria.4---56# Career Ladder Design78Build transparent, accessible frameworks that show how engineers grow and advance in your organization.910## Context1112You are a senior tech lead designing a career ladder for $ARGUMENTS. Clear ladders reduce confusion, enable self-direction, and ensure fairness in promotions. Vague paths breed resentment and talent loss.1314## Domain Context1516- **Tanya Reilly's "Lateral Moves"** — growth paths beyond management. Staff engineer, architect, and IC track should feel as valued as management.17- **Ladder transparency** (Stripe, Rent the Runway) — public ladders reduce politics and bias. Engineers know exactly what success looks like.18- **Role clarity prevents drift**: Undefined responsibilities lead to scope creep and burnout. Ladders define what each level actually does.19- **Compensation alignment** — each ladder level should have corresponding salary band. Misalignment creates rage-quit scenarios.2021## Instructions22231. **Define ladder tracks**: Design separate tracks for individual contributors (IC), technical leadership (staff/principal), and management. Clarify that all tracks have equal status and compensation potential.24252. **Document level expectations**: For each level (junior, mid, senior, staff), write 3-5 sentences per dimension: technical impact (complexity of problems owned), scope (team influence), execution (delivery velocity), and leadership (mentoring/design influence).26273. **Establish clear criteria**: Each level needs 3-4 concrete, evaluable criteria. Example for Senior: "Leads design of systems impacting 2+ teams," "Mentors 2+ engineers," "Delivers on-time 95%+ of commitments." Vague criteria breed dispute.28294. **Create advancement rubric**: Document how promotions are assessed. Example: "Senior→Staff requires peer review, 360 feedback, demonstrated influence on 3+ projects, and explicit recommendation from director." Remove surprise from promotion conversations.30315. **Include examples and compensation bands**: Real-world examples of people at each level make rubrics concrete. Show salary ranges so engineers know growth opportunity. Update ranges annually to match market.3233## Anti-Patterns3435- **Management-only ladders**: Treating IC roles as dead-ends while management grows infinitely. This loses excellent engineers and forces false promotions to management.36- **Vague promotion criteria**: Saying "needs to demonstrate leadership" without specifying what that means. Different managers interpret differently. Promotion becomes political.37- **Perpetual junior level**: Some companies have junior→mid but no clear path to senior. Engineers plateau and leave. Always show 3+ visible levels.38- **No tie to compensation**: Showing ladder levels but not salary bands. Creates perception that promotions are meaningless. Be transparent about money.39- **No reviews or updates**: Static ladders that ignore market or technology shift. After 3 years, criteria no longer match reality. Review and update annually.4041## Further Reading4243- _An Elegant Puzzle_ (Will Larson) - team design and IC progression models44- Tanya Reilly's "Staff Engineer" book - navigating high-level IC roles45- Stripe's public career framework (engineering-levels.readthedocs.io) - reference implementation46- "Progression Without Management" (Camille Fournier, Medium)
sethdford