| name | career-ladder-design |
| description | Create transparent role progression frameworks showing how engineers advance within technical and lateral tracks. Use when defining career paths and promotion criteria. |
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)
