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

1. 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.

2. 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).

3. 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.

4. 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.

5. 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)