Career Ladders
Written levels described by scope and impact, equal IC and management tracks, staff and principal archetypes, and promotions that recognize sustained work.
The growth conversations in 1:1s need a shared language, and so does every decision about level and pay. Without a written ladder, levels are decided by whoever argues best in calibration, and promotions go to the people whose work is most visible to the people who decide. A ladder doesn't remove judgment, but it makes it explicit, discussable and the same for everyone: two engineers doing the same work land at the same level whoever their manager is, "what do I need to do to get promoted?" gets a better answer than "keep doing great work", and the same descriptions set the bar for interviews and the level of an offer.
Describe Scope and Impact, Not Tasks
A ladder that lists tasks ("writes unit tests", "participates in code review") is a checklist anyone can game and nobody grows by completing. Describe levels by the scope a person owns and the impact they have: a well-defined task, then a feature, a system, a domain spanning several teams, the organization's technical direction.
Dropbox's public career framework is a good model: each level is defined by its "scope, collaborative reach, and levers for impact", with separate core responsibilities (results, direction, talent, culture) and craft skills per discipline. It's also explicit that the framework is a guide, not a promotion checklist, which is the right way to read any ladder.
Two Tracks, Equal Seniority
Management is a different job, not a promotion. If the only way to keep growing is to manage, you'll convert some of your best engineers into unhappy managers and lose the work only they could do. Run parallel tracks with equal seniority: a Staff Engineer and an Engineering Manager are peers, and a Principal Engineer sits alongside a Director. CircleCI's competency matrix states the premise directly, that it doesn't assume all engineers should or want to become managers, and it builds leadership expectations into every IC level rather than reserving them for managers. Moving between tracks should be possible in both directions without loss of level.
Staff and Principal
Above senior, the ladder stops describing one job. Will Larson's Staff Engineer archetypes name four common shapes:
- Tech Lead: guides how one team or a small cluster of teams approaches its work.
- Architect: owns the direction and quality of a critical technical domain.
- Solver: goes deep on hard, high-risk problems the organization has flagged, until they're resolved.
- Right Hand: extends a senior leader's reach on the organization's most complex problems.
Naming them matters for promotion: a Solver and a Tech Lead produce very different evidence, and judging both against one template undervalues whichever doesn't fit it. Describe staff-plus levels by the scope and kind of impact expected, and let the archetype shape the evidence.
Promotion Recognizes Sustained Work
Promote people who are already working at the next level, consistently, over a meaningful period, not people who might be able to. Promoting on potential sets people up to struggle without support, and it signals to everyone else that the bar is negotiable. The ladder is the reference for "working at the next level", and the evidence is the work itself: designs, outcomes, the people they've grown.
Managers owe their reports a path, not a verdict: what the next level looks like for them, what work would demonstrate it, and the chance to do that work. A promotion should rarely surprise the person or the committee. Levels also drift without cross-team calibration, as each manager's sense of "senior" slides toward their own team; how to calibrate without rewarding the most persuasive manager is in Performance Reviews.
Avoid Promotion-Driven Development
A ladder that rewards "led a large project" will get large projects, needed or not: rewrites, new services and frameworks that exist partly as promotion evidence. Watch for it, and make the ladder reward outcomes and judgment over activity: the migration someone talked the team out of, the system that got simpler, the problem solved with a small change. Saying no to the wrong project is senior work, and the ladder should recognize it.
References
In practice
- Dropbox: Engineering Career Framework, levels defined by scope, collaborative reach and levers for impact
- CircleCI: Why we redesigned our engineering career paths, a public competency matrix that doesn't assume engineers want to manage
- StaffEng: Staff archetypes, Tech Lead, Architect, Solver and Right Hand
- Will Larson: Staff Engineer, leadership beyond the management track