The Engineering Career Ladder: Writing Leveling Rubrics That Survive Calibration

---

I've sat in a lot of calibration meetings, and the bad ones all sound the same. Ten managers, a spreadsheet of engineers, and a rubric full of phrases like "demonstrates strong technical leadership." Manager A says her engineer is clearly Senior — "strong leadership, look at the project." Manager B says the same words describe his engineer who's not getting promoted. They're both right, because the rubric means nothing. The next two hours are a negotiation about who advocates harder, not an assessment of who operates at what level. The loudest manager wins, the quiet engineer on the strong team loses, and everyone leaves trusting the process a little less.

A career ladder has exactly one job: enable consistent, defensible level decisions across different managers and teams. If two reasonable managers can read the same rubric and the same evidence and disagree about the level, the ladder has failed — no matter how nice it looks in the handbook.

Most ladders fail this test. Here's how to write one that passes, having watched both kinds get used in real promotion and calibration cycles. (This connects directly to performance frameworks and the IC-vs-management decision — the ladder is the spine that holds those together.)

Define levels by scope and autonomy, not years or output

The foundational mistake is anchoring levels to the wrong axis. Two common wrong anchors:

• Years of experience. "Senior = 5+ years." This is how you get a 10-year engineer who's had the same year ten times sitting above a 4-year engineer who's outgrown them. Time served is not a level.
• Output volume. "Senior writes a lot of high-quality code." Volume doesn't distinguish levels well even pre-AI, and post-AI it's nearly meaningless (more on this below).

The axis that actually works is scope of impact + autonomy: how big is the problem space this person handles, and how much guidance do they need to handle it?

Each rung up is a step-change in two things together: the scope of impact (task → component → system → cross-team → org) and the autonomy with which they operate within it (needs direction → independent → defines the direction). This axis is observable, it scales, and — crucially — it's the same axis whether someone codes or manages, which lets you build parallel tracks.

Make every rung behaviorally observable

This is the rule that separates a ladder that survives calibration from one that doesn't: every expectation must be something you could point to evidence for. The test: could two managers look at the same engineer's actual work over six months and independently agree whether they meet this bar?

Bad rung (un-calibratable): "Senior engineers demonstrate strong ownership, technical depth, and leadership." Every word is an adjective. Two managers will read their own engineer into it.

Good rung (calibratable): "Independently owns a significant system or domain; makes architectural decisions others rely on; is sought out across teams for technical judgment; has grown at least one engineer's capability measurably." Now there's evidence to point at: which system, which decisions, which engineers grew.

Write rungs as observable behaviors and demonstrated impact, not traits. "Is a strong communicator" → "writes design docs that other teams act on without a meeting; de-escalates technical disagreements to a decision." Traits are arguments; behaviors are evidence.

Two tracks, equal in status

Past Senior, the ladder must fork into a management track and an individual-contributor (IC) track, and the two must be genuinely equal in level, compensation, and respect.

Two failure modes if you get this wrong:

• No IC track → the only way up is management, so you promote your best engineers into management to reward them, and lose a great engineer to gain a reluctant manager. The classic, expensive mistake.
• A second-class IC track → Staff/Principal exist on paper but the real power and pay are on the management side. Engineers see through it instantly, and you're back to everyone chasing management.

Staff+ and Director+ should be the same level — measured by scope of impact, achieved through different means (technical influence vs people/org leadership). Make the parallel real in the comp bands, or don't bother drawing it.

Rewrite the rungs for the AI era

This is now urgent. Many ladders describe levels in terms that AI has hollowed out: "writes complex code independently," "delivers large features," "high code output." When generating code is cheap, these stop discriminating between levels — a mid-level with an agent produces volume that used to signal senior.

Rewrite the rungs around what still scales with seniority when the machine can write the code:

• Entry → can validate and integrate AI output for well-scoped tasks; knows when to distrust it. (Not "writes simple features" — that's a prompt now.)
• Mid → owns a component including its failure modes; reviews peers' and AI's work reliably.
• Senior → owns conceptual integrity across a system; is a trusted verifier across a broad surface; multiplies others' judgment.
• Staff+ → sets technical direction that AI amplifies safely; designs systems and team structures that hold quality at high generation volume.

The through-line: level up the ladder on judgment, verification, conceptual integrity, and impact — the things that get more valuable as code gets cheaper — not on production. I went deep on why in how AI is reshaping team topologies; the ladder is where you operationalize it.

The failure modes that turn ladders into politics

Even a well-written ladder rots if you misuse it. Watch for:

• Checklist promotion. Treating rungs as a literal to-do list ("did 7 of 9 bullets, must promote"). Rungs describe a pattern of operating at a level, not boxes to tick. Someone can hit bullets without actually operating at the level, and vice versa.
• Promotion as reward for tenure or for one big project. A level reflects sustained operation at that scope, not a single heroic quarter or time served.
• Calibration as advocacy contest. If the rubric is vague, calibration becomes "whose manager argues best," which systematically disadvantages engineers on teams with quieter managers. Behaviorally observable rungs are the antidote — you argue about evidence, not adjectives.
• The ladder no one reads. A ladder engineers can't use to understand "what would get me to the next level" is just HR decoration. It should be a growth map, in plain language, that an engineer and manager can plan against.

What to do Monday morning

1. Stress-test one level against calibration. Take your "Senior" definition and ask: could two managers independently agree who meets it? If it's full of adjectives, you've found why your calibrations are arguments.

2. Rewrite one rung as observable behaviors. Convert "demonstrates strong leadership" into specific, evidenceable behaviors and impact. Notice how much clearer the level decision becomes.

3. Check your IC track is real. Do Staff/Principal levels exist, and are they equal in comp and status to the management levels? If not, you're forcing your best engineers toward management.

4. Audit for AI-stale rungs. Find every level defined by code volume or "writes complex code" and rewrite it around judgment, verification, and conceptual integrity.

Key takeaways

• A ladder has one job: consistent, defensible level decisions across managers. If two reasonable managers disagree on the level given the same evidence, the ladder failed — looks in the handbook don't matter.

• Anchor levels on scope of impact + autonomy, not years or output. Each rung is a step-change in how big a problem space someone handles and how independently. This axis is observable, scales, and works for both IC and management tracks.

• Every rung must be behaviorally observable. Replace adjectives ("strong ownership") with evidenceable behaviors and impact. Traits are arguments; behaviors are evidence — and evidence is what survives calibration.

• Provide two genuinely equal tracks. Staff+ (IC) and Director+ (management) at parallel levels, comp, and status. No IC track (or a second-class one) forces great engineers into reluctant management.

• Rewrite rungs for the AI era. Code-volume definitions are now meaningless. Level up on judgment, verification, conceptual integrity, and impact — the things that grow more valuable as code generation gets cheap.

Your next step

Pull up your current ladder and read the "Senior" definition out loud, then ask: if I gave this to two managers and one engineer's six months of work, would they reach the same level decision? If the honest answer is no, your calibration meetings are negotiations, not assessments — and the fix is to rewrite those rungs as observable behaviors anchored to scope and autonomy. A ladder that survives calibration is the difference between promotions that feel fair and promotions that feel political.

Frequently asked questions

What should an engineering career ladder be based on?

It should be based on scope of impact and autonomy — how large a problem space the person handles (task → component → system → cross-team → organization) and how independently they operate within it (needs guidance → independent → defines the direction). Avoid anchoring on years of experience (which rewards tenure over growth) or code output volume (which discriminates poorly between levels and has been made nearly meaningless by AI code generation). The scope-and-autonomy axis is observable, scales across levels, and works identically for both individual-contributor and management tracks.

Why do career ladders fail during calibration?

Because the rungs are written as vague traits and adjectives ("demonstrates strong ownership and leadership") that different managers interpret to fit their own engineers. When the rubric is ambiguous, calibration becomes an advocacy contest where the most persuasive manager wins rather than an evidence-based assessment, which systematically disadvantages engineers on teams with quieter managers. A ladder survives calibration only when every rung is behaviorally observable — when two managers can look at the same six months of work and independently reach the same level decision.

Should engineers and managers be on the same career ladder?

Past the Senior level the ladder should fork into a management track and an individual-contributor (IC) track that are genuinely equal in level, compensation, and status — for example Staff/Principal mirroring Director/VP. Without a real IC track, the only way up is management, so organizations promote their best engineers into reluctant management roles and lose great ICs. A second-class IC track that exists on paper but lacks real pay and influence fails the same way, because engineers quickly see through it.

How should AI change our leveling rubric?

Remove level definitions based on code volume or "writes complex code independently," since cheap AI code generation has made those signals meaningless — a mid-level engineer with an agent can produce what used to look senior. Rewrite rungs around what still scales with seniority: validating and integrating AI output and knowing when to distrust it (entry), owning components and their failure modes and reviewing reliably (mid), owning conceptual integrity and being a trusted verifier across a broad surface (senior), and setting technical direction that AI amplifies safely (staff and beyond). The through-line is judgment, verification, and impact rather than production.

Is a leveling rubric a promotion checklist?

No. Rungs describe a sustained pattern of operating at a given level of scope and autonomy, not a list of boxes to tick. Treating them as a literal checklist ("met 7 of 9 bullets, must promote") leads to promoting people who hit bullets without actually operating at the level, and overlooking those who clearly do. Promotion should reflect consistent operation at the next level's scope over time, supported by observable evidence, rather than a single big project, tenure, or a completed checklist.