# Career Ladder Design

> Create transparent role progression frameworks showing how engineers advance within technical and lateral tracks. Use when defining career paths and promotion criteria.

- Skill: `sethdford/career-ladder-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/career-ladder-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/career-ladder-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/career-ladder-design

---


# 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)