Promotion and Performance Conversations Engineers Respect

A senior engineer on a team I worked with quit the week after their "exceeds expectations" review. Not because of the rating. Because the promo packet got rejected in calibration two days later, and nobody (not their EM, not the skip) had warned them it was a coin flip. They'd spent eighteen months hearing "you're crushing it." The story they told their network on the way out was simple: my manager either didn't know, or knew and didn't tell me. Both versions are bad for hiring.

Half-yearly cycles compress six months of unspoken signals into one 45-minute conversation. What you didn't write down didn't happen. What you didn't name in May doesn't get to count in October just because you remembered it during calibration prep. This playbook is for EMs who want their engineers to walk out of every review able to predict the outcome themselves, from artifacts already on paper.

Promotion criteria as an evidence list, not opinions

The fastest way to lose an engineer's trust is to defend a promo decision with adjectives. "Strong technical leadership." "Great cross-team impact." "Exceptional ownership." None of those words mean anything to an engineer holding a rejected packet. They want the artifact.

Run promotions on a four-column rubric tied to shipped work:

Notice what's not in the rubric: vibes, seniority by tenure, "felt like a Staff engineer in the room." Those are how you lose a calibration argument. The columns above are how you win one.

When you sit down to write a packet, the question stops being "is Priya ready for Staff?" and becomes "does Priya have three design docs adopted across the org, two services owned end-to-end, and a quarter of unblocking five engineers minimum?" If she has two design docs, you're not ready to put her up. If she has four and incident command on a P0, you have a case.

Show the bar with named examples. "At Staff, we expect work like Marco's payments-rewrite RFC or Lin's retry-budget framework." Generic levels in a wiki aren't evidence. Real packets that got approved are.

The companion to this article is the Staff Software Engineer job description. The scope, impact, and leverage language in your promo rubric should mirror that JD verbatim. If your rubric says "drives architecture decisions" but your JD says "owns multi-service system design," your engineers are calibrating against two different bars.

The 6-month visibility plan

The reason most promo packets fail isn't that the engineer didn't grow. It's that nobody knew they grew. A Staff candidate who shipped great work on three internal tickets that nobody outside the team can name is a Staff candidate whose packet gets killed in calibration. Visibility is a deliverable.

In month 1 of every half-cycle, sit down with each engineer who's a candidate for promo within the next 12 months and write a 6-month visibility plan together. Four artifacts, signed and dated:

1. One stretch project with a named exec sponsor and a shippable surface area (more on the trap below).
2. One cross-team artifact: an RFC consumed by another team, an integration that another EM can name, a migration that closed a tech-debt ticket two orgs over.
3. One mentorship outcome: a junior who gets promoted, a new hire who ramps in 30 days instead of 90, a hiring loop they led.
4. One written design doc that survives review and gets cited by someone outside the immediate team within 6 months.

That document goes into a shared folder. Both of you sign it. Now there is no ambiguity about what the next cycle is judged on, and the engineer can self-audit at month 3 and month 5 instead of finding out at the calibration table.

If they ship all four, the packet writes itself. If they ship two of four, they know in month 4 (not on review day) that the packet isn't ready, and they have a chance to course correct or accept a 6-month delay without it feeling like a betrayal.

The difficult performance conversation: SBI + Ask + Commit

Most EMs sandwich. They open with a compliment, deliver the criticism in the middle, close with reassurance. Engineers don't hear the middle. They hear "you're doing great, some minor stuff, you're doing great." Then they get blindsided in October and they tell their friends.

Stop sandwiching. Use SBI + Ask + Commit. Four steps, no padding.

Situation. The specific time, place, and context. "In the auth-service redesign review on March 12."

Behavior. What the person did, observably. Not what you inferred about their state of mind. "You declined to address two of the four reviewers' questions and said 'we can figure that out later.'"

Impact. What it cost the team or the work. "The reviewers escalated to me afterward. We delayed the launch by a week to redo the threat model."

Ask. What you want different, specifically, next time. "When a reviewer flags a security question on a design doc, I need you to answer it in the doc within 48 hours, even if the answer is 'we'll defer this and here's why.'"

Commit. A date and a checkpoint. "Let's revisit this at our 1:1 on April 9 and look at how the next two design reviews went."

Two example scripts you can lift verbatim:

Code reviews blocking the team. "In sprint 23, three of your code reviews took more than 4 days to turn around. One of them blocked the checkout-revamp launch by a full sprint. The team is starting to route around you, which means you're losing context on the codebase. I need you to either turn reviews around in 24 hours or reassign them to someone who can. Let's check in at our 1:1 on the 15th."

Design docs lack rigor. "Your last two design docs (the queue migration and the rate-limiter rewrite) had no failure-mode section and no rollback plan. The architecture review committee sent both back for a second pass, which cost you two weeks each. At Staff level, design docs need to land on the first review at least 70% of the time. I want the next doc you write to include a failure-modes table and a rollback section before it goes to ARC. We'll review the next doc together before submission on the 22nd."

Notice what's missing. No "but you've been doing great work otherwise." That sentence is for your own comfort, not theirs. Save it for the end of the meeting if you need to, after the commit.

PIP signals: when to start, when to skip

A Performance Improvement Plan is a tool, not a punishment. The single biggest mistake EMs make is starting one too late, which is usually because they were sandwiching for six months. The second biggest mistake is starting one when the real issue is fit, not performance.

Start a PIP when all three are true:

1. The behavior has been named to the engineer in writing (in 1:1 notes they can read back).
2. The behavior has been repeated across at least two cycles or two months.
3. The behavior is unchanged after at least two written 1:1 notes calling it out and at least one SBI conversation.

If you can't show all three from your 1:1 doc, you don't have a PIP case. You have a feedback gap, and the PIP will get challenged by HR and your peer EMs in calibration.

Skip the PIP when it's a fit problem, not a performance problem.

A "fit problem" looks like: the engineer is technically fine, ships their work, but is mismatched with the team's domain (deeply infra person on a product team, deeply product person on a platform team) or the company's stage (likes 10-person scrappy chaos, hired at 800 people). The engineer's not failing. The seat is wrong.

Forcing a PIP on a fit problem creates a rage exit. The engineer fights, wins technically, leaves anyway, and tells everyone you tried to manage them out unfairly. Cost: 6 months of team morale and your reputation in the broader market.

Offer a managed transition instead. Direct, kind, dated. "I think you'd be a stronger fit on the platform team. I've talked to Maria and she has an opening. I'd like to support you transitioning over the next 4 weeks. If you'd rather look outside, I can give you 6 weeks of runway and a strong reference." Engineers respect this. Their friends respect this. Your hiring pipeline benefits.

The PIP decision tree, simplified:

A clean PIP resolves in 60 days, either through real improvement or a clean exit. If yours is dragging into month 4, you're managing your own discomfort, not the engineer's performance.

Promotion calibration with peer EMs

Calibration is the meeting where promo decisions actually get made. The packet you wrote is the entry ticket. The 90 minutes in a room with 4-6 peer EMs and your director is where champion vs. challenger dynamics decide the outcome.

Bring a one-page pre-read. Two days before calibration, send your peer EMs a single page per candidate:

• Name, current level, target level
• Top 3 artifacts (with links to design doc, RFC, incident retro)
• Scope/impact/leverage evidence in three short bullets each
• One paragraph on the strongest counter-argument and your response to it

That last bullet is what separates an EM who walks out with their engineer promoted from one who doesn't. Pre-empting the challenger's argument in the pre-read means the pushback in the room is something you've already addressed in writing. If you don't pre-empt it, your peer who's pushing back gets to frame it first.

Defend a borderline case without overselling. Borderline means the engineer is at the bar on two of three dimensions and approaching on the third. Don't say "they're absolutely Staff." Say "they're at-bar on scope and leverage, approaching on impact, and here's the work in flight that closes the gap by Q3." That's the kind of language that survives a director's scrutiny. Overselling a borderline case kills your credibility for the next two cycles.

When a peer EM blocks your engineer to protect their own (it happens, especially when ratings are stack-ranked or budget is constrained), don't fight it in the room. You'll lose, and you'll burn the relationship. Instead, take it offline. "I want to make sure I understand your concern about Priya's design-doc bar. Can we walk through her three RFCs together this week?" Nine times out of ten, the resistance dissolves when you take the conversation off the calibration stage.

The "stretch project" trap

Half the failed promo packets I've seen got killed by a stretch project that was never going to ship visible work. The pattern is always the same. EM assigns a stretch project that sounds great on paper. Engineer spends 4 months on it. Project gets deprioritized, scope-cut, or the exec sponsor moves teams. Engineer ships nothing externally visible. Calibration room asks "what did Priya do this half?" EM has nothing to point to.

Pre-validate stretch scope before assigning. Three checks, all required:

1. Real budget. There's a line item or a headcount allocation, not a "we'll figure it out later." If finance can't name it, it doesn't exist.
2. Named exec sponsor. A specific Director or VP who has, in writing or in a recorded meeting, said "this is one of my top 3 priorities this half." Not a CC on a launch email. A statement.
3. Shippable surface area. A user, customer, or internal team that will use the output and can confirm it landed. If the only people who'll see it are the engineer's own team, it's a normal project, not a stretch.

If any of three is missing, the project is a career trap. Push back, even if the engineer is excited. "I love this idea. Before I assign it as your stretch, I need to know who the exec sponsor is and what user gets to use it. Without those two, you'll burn 4 months on something that doesn't help your packet." The good engineers thank you in month 5. The great ones thank you in month 1.

Written growth doc cadence

One document. Same document. Lives the entire tenure of the engineer on your team. Not three separate docs in three different places.

Three cadences feed it:

The monthly bullet is the underrated one. Five minutes. The engineer writes what they shipped, what blocked them, what they learned, what they're asking from you. You read it before the next 1:1 and respond in writing. Six months later, when calibration prep starts, you have 6 months of bullets that compress into the formal packet without any heroic recall effort.

The big rule: the engineer can read their own trajectory at any time. If your engineer asks "where am I at?" the answer is "open the doc, scroll to the last quarterly review, you can see exactly where you stand." No surprises. No "let me schedule time to talk through it." The doc is the answer.

This is also how you recover when an engineer transfers teams or you leave the company. The next EM inherits a real document. Not a Slack DM history.

Common pitfalls to avoid

• Saving real feedback for review day. If your engineer is hearing it for the first time in October, you failed in May.
• Promoting on potential instead of evidence. Potential is what you bet on at hiring, not at promo. Promo runs on shipped artifacts.
• Soft language that translates to "no problem" in the engineer's head. "I'd love to see a bit more polish on your design docs" is not feedback. It's a hint that gets ignored. Use SBI.
• Calibrating without artifacts in the room. If you can't link the design doc, you don't have an argument.
• Confusing hours worked with impact shipped. A 60-hour engineer who shipped two features doesn't beat a 40-hour engineer who shipped four.

Measuring success

You'll know this playbook is working when:

• Zero engineers are surprised by their review-day rating, because they've been reading the same growth doc you have.
• Promo packets get approved on the first calibration round 70% of the time, because you stopped putting up borderline cases as long shots.
• PIPs resolve within 60 days (either real improvement or a clean transition) instead of dragging into month 6 and poisoning the team.
• Engineers can quote their own next-level criteria from memory, because you wrote the rubric down and walked through it on a real artifact.

The bar is simple. The engineer holding a rejected packet should be able to point at the criteria, point at their work, and agree with the gap. If they can't, the failure was yours, not theirs.

Learn More

• Staff Software Engineer Job Description
• Running 1:1s With Engineers That Move Things
• Hiring Senior Engineers Who Stay
• Skip-Level 1:1s That Actually Surface Truth