Leveling Manager

Standing Mandates

• ALWAYS distinguish level evidence from performance evidence — strong performance is not level evidence.
• ALWAYS prepare counter-arguments to anticipated calibration objections before the meeting.
• NEVER write a promotion case with general claims — every assertion needs a specific example.
• NEVER evaluate level by comparing to a single highlight; evaluate against the full rubric.

Engineering Leveling — Manager Framework

When to Use / When Not to Use

Use when:

• Writing or reviewing a promotion case before a calibration cycle
• Designing or sharing level rubrics with your engineers
• Preparing to advocate for a promotion in a calibration session

Not for:

• IC promotion planning (use leveling-ic)
• Coaching 1-on-1 conversations (use 1-on-1-manager)
• Performance improvement plans (different from leveling)

Process

1. Define rubric — ensure rubric exists and is shared with the engineer
2. Collect evidence continuously — running doc per engineer; STAR format; tag by rubric dimension
3. Write the promotion case — structure: executive summary + evidence by dimension (2-3 examples each) + developmental areas
4. Apply the skeptic test — read the case as someone who doesn't know this engineer; find the weak spots
5. Calibration — present evidence, not opinions; have additional examples ready; know when to yield vs. push back
6. Communicate — promotions: name what demonstrated readiness; not-yet: specific gap + path + timeline

Output Template

Promotion case structure:

## Promotion Case: [Name] — [Current Level] → [Target Level]

### Executive Summary
[1 paragraph: specific claim with named evidence. Not "she's great" — "here are three initiatives that demonstrate Staff-level behavior."]

### Evidence by Dimension

**[Dimension 1 — e.g., System Design]**
- Example 1: [STAR format]
- Example 2: [STAR format]

**[Dimension 2 — e.g., Cross-team Influence]**
- Example 1: [STAR format]
- Example 2: [STAR format]

[Repeat for each rubric dimension]

### Developmental Areas
[Honest gap statement + why it is not a blocker, or what the plan is]

What Claude Does / What You Do

Related Skills

• ../leveling-ic/SKILL.md — understand what your ICs are working toward
• ../1-on-1-manager/SKILL.md — 1-on-1 growth tracking is the source of continuous evidence

Core Principle

Leveling is not a judgment about a person — it is an assessment of demonstrated impact at a given scope. The question is never "is this person good?" It is: "At what scope does this person consistently operate, with what level of autonomy, and what evidence supports this?" Levels describe patterns of behavior over time, not single events or potential.

The foundation: Most leveling systems fail because they conflate three things: potential, performance, and level. An engineer can be performing well at their current level without being ready for the next. A high-potential engineer is not automatically at the next level until they've demonstrated it. Calibration conversations fail when managers argue about these distinctions without shared definitions. Good leveling starts with a clear rubric, gathers evidence systematically, and writes the promotion case before advocating for it.

Scoring

Goal: 10/10. When evaluating your leveling practice as a manager, rate 0-10. A 10/10 means you have a documented rubric, gather evidence continuously, write promotion cases grounded in specific examples, and represent your engineers effectively in calibration. Always provide the current score and specific improvements needed.

• 9-10: Clear rubric shared with engineers, evidence gathered continuously, promotion cases written with specific examples, calibration participation is strong
• 7-8: Rubric exists but isn't shared proactively; promotion cases are written but rely on recency; calibration is reactive
• 5-6: Leveling is intuition-based; no rubric; promotion cases are thin; calibration is uncomfortable
• 3-4: Leveling is opaque to engineers; promotions happen based on tenure or politics; no calibration
• 1-2: No leveling framework; "good" vs "not good" is the only assessment; engineers don't know what's expected

The Leveling Manager Framework

1. Level Definitions and Rubrics

Core concept: Every level in an engineering career ladder is defined by a combination of scope (what size problem?), autonomy (how much direction needed?), impact (what changes in the world?), and craft (how well does the technical work hold up?). A rubric translates these dimensions into specific, observable behaviors for each level.

Why it works: Without a rubric, leveling is subjective and inconsistent — different managers apply different standards, and engineers don't know what to work toward. A rubric creates a shared language: "operating at Staff level" means something specific, not "I feel like they're Staff."

Key insights:

• Typical engineering levels: Junior (L3/E3) → Mid (L4/E4) → Senior (L5/E5) → Staff (L6/E6) → Principal (L7/E7)
• The key inflection points: Junior→Mid (independence within tasks), Mid→Senior (independence within projects), Senior→Staff (influence across teams/systems)
• Rubric dimensions: Technical Execution, System Design, Project Leadership, Collaboration, Impact
• Each dimension should have 3-4 observable behaviors per level — specific enough to find evidence for
• Share the rubric with engineers: if they don't know what "Senior" looks like, they can't develop toward it
• Rubrics should be calibrated across managers, not defined by one person

Practice applications:

2. Evidence Collection

Core concept: Promotion cases are won or lost in calibration based on the quality of evidence. Evidence is specific, behavioral, and tied to impact — not general impressions or tenure. Collecting evidence continuously, throughout the year, is dramatically more effective than scrambling at promotion time.

Why it works: Recency bias is the single biggest threat to fair leveling — managers remember the last three months more than the prior nine. Continuous evidence collection counters recency bias, catches growth that happened incrementally, and produces a promotion case that is hard to refute because it is grounded in facts.

Key insights:

• Keep a running doc per engineer: weekly or bi-weekly entries of specific examples with context
• After every significant event (incident, design review, launch, conflict), write a note: "What did they do? What was the impact? What does this demonstrate about their level?"
• Use the STAR format: Situation → Task → Action → Result
• Collect both positive evidence (behaviors at the target level) and developmental observations (gaps at the target level)
• Ask other managers, engineers, and stakeholders for input — don't be the only observer
• Quantify impact where possible: "The refactor they led reduced API latency by 40%, enabling the SLA upgrade for three enterprise customers"

Practice applications:

3. Writing the Promotion Case

Core concept: A promotion case is a structured document that argues, with evidence, that an engineer has consistently operated at the next level. It is not a performance review, not a list of projects, and not an expression of the manager's feelings. It is an evidence-based argument, written as if a skeptic will read it.

Why it works: Calibration panels are skeptical by design — their job is to maintain level standards across the organization. A promotion case that says "she's great and ready for Senior" will fail. A case that says "here are five specific examples across six months demonstrating Staff-level behavior in three rubric dimensions" will succeed, because it's hard to refute.

Key insights:

• Structure: Executive summary (1 paragraph) → Evidence by rubric dimension (3-5 paragraphs) → Summary of level rationale → Developmental areas
• Each rubric dimension needs at least 2-3 specific examples — no dimension should be supported by a single data point
• Write the executive summary last — it should synthesize the evidence, not preview vague impressions
• Address the developmental areas honestly: "Not yet at full scope on [dimension] — here's the plan" is more credible than pretending there are no gaps
• Write it as a document, not a list of bullet points — narrative is more persuasive and easier to follow
• Have another senior manager review it before submission — they'll see the gaps a sponsor can't

Practice applications:

4. Calibration Conversations

Core concept: Calibration is the process by which managers align on level standards across the organization. It is not a negotiation or an advocacy session — it is a conversation about whether a specific body of evidence meets a specific level definition. The manager's job is to represent the engineer fairly, not to win at all costs.

Why it works: Without calibration, each manager applies their own standards, and leveling becomes inconsistent. Engineers in some teams get promoted faster with less evidence; others are held to a higher bar. Calibration creates organizational fairness — the same bar applies regardless of team or manager.

Key insights:

• Know the level rubric cold before calibration — you need to speak to evidence against specific criteria
• Present evidence, not opinions: "Here are three examples of Staff-level behavior" not "I really believe she's ready"
• Be prepared for skepticism — have additional examples ready for the dimensions that will be questioned
• Know when to yield: if calibration reveals a genuine gap you missed, update your assessment — that's the system working
• Know when to push back: if calibration is applying an inconsistent standard, name it: "What would constitute sufficient evidence? Can we align on the bar?"
• Document calibration outcomes and share with engineers (appropriately) — they should know what was discussed and what would change the outcome

Practice applications:

5. Communicating Leveling Decisions

Core concept: Whether the outcome is promotion, "not yet," or development feedback, the manager must communicate clearly, specifically, and with a path forward. Vague decisions ("you're not quite ready") destroy trust. Specific decisions ("the gap is system-level design, and here's what that looks like") enable growth.

Why it works: Engineers whose promotions are declined without clear rationale either leave or lose motivation. Engineers who receive specific, honest feedback about the gap — and a credible path to closing it — often grow faster than those who were promoted on schedule. The communication is as important as the decision.

Key insights:

• Promotions: name what demonstrated readiness — "what made this promotion clear was X, Y, Z"
• Not-yet decisions: name the specific gap, not a vague feeling — "the gap is X, which at Staff level looks like Y"
• Provide a timeframe and a plan: "Here's what I want to see in the next two quarters" + specific opportunities
• Don't sugarcoat a gap you privately believe is uncloseable — if the engineer has a genuine ceiling, have that harder conversation
• Separate the decision from the relationship: "I advocated for you; the calibration panel identified a gap that I think is worth discussing"
• Follow up in writing: decisions and plans should be in the shared 1-on-1 doc, not just spoken

Practice applications:

Common Mistakes