Forget the rating. Forget the calibration meeting. Forget the form with the five competencies and the free-text box nobody reads.
If your engineer walks out of a performance review holding brand new information about their own performance, you already failed. Not in the meeting. Months before it. The meeting only exposed the failure.
The surprise is the diagnostic
A surprise in a review is not a communication hiccup. It is proof of a manager who knew something, sat on it, and saved it for a scheduled event.
Think about what saving it up means. You watched a problem repeat. You had the evidence. You chose silence, then handed over a written record of your silence and asked the engineer to sign it.
Feedback delayed is feedback denied.
Nine months of quiet
I have watched this play out more times than I want to count.
An engineer gets marked down for collaboration. They push back and ask for a concrete example. The manager reaches back three quarters to a design review where the engineer steamrolled a junior colleague. Six people sat in the room. Every one of them remembers it. Nobody said a word at the time. Nobody said a word the following week either.
So the engineer spent nine months repeating a behavior nobody flagged, and then got punished for the repetition.
Ask yourself who failed there.
The engineer had no signal. The manager had every signal and spent it on a form.
Why engineering managers sit on it
I have been the manager sitting on it, so I get the pull. Four things drive it.
Conflict feels expensive in the moment. A hard conversation on Tuesday costs you twenty uncomfortable minutes. Silence costs you nothing today. The bill arrives later, with interest.
Managers believe hoarding evidence equals fairness. One data point feels flimsy. Five feels solid. So you wait for five, and by then the pattern hardened into an identity.
The process rewards hoarding. The form asks for documented examples across the review period. Fill it out honestly and you are incentivized to collect rather than correct.
Technical managers confuse the two feedback muscles. You will drop a blunt comment on a pull request at 11pm without blinking. Then you spend three weeks avoiding a two-minute chat about how someone talks in standup. Same person. Same courage required. One feels like engineering, the other feels like management, and most of us were promoted for the first one.
The numbers back this up
Gallup found a mere 14% of employees strongly agree the performance reviews they receive inspire them to improve. Two in ten strongly agree their performance gets managed in a way motivating them to do outstanding work.
Fourteen percent. Your build pipeline would be ripped out and rebuilt at a 14% success rate. Your review process survives untouched year after year.
Now the other side of the ledger. Gallup also found 80% of employees who received meaningful feedback in the past week are fully engaged. Employees getting daily feedback are 3.6 times more likely to agree they feel motivated to do outstanding work than employees getting annual feedback. Gallup's recommended cadence for most roles is a few times per week.
A few times per week. Not once a year, with a form.
My own research found 99.5% of survey respondents said they have had one or more types of bad boss. Ask people what made the boss bad and you rarely hear about strategy or technical skill. You hear about the thing nobody told them until it was too late to fix.
Your metrics will not rescue you
Some leaders read all this and reach for dashboards. If the feedback is late and vague, make it automatic and numeric. Wire up DORA, sort by developer, done.
No.
Google's own write-up on the four keys describes metrics indicating the performance of a software development team. Team. Deployment frequency, lead time for changes, change failure rate and time to restore describe a delivery system, not a person inside it.
Pull one engineer's deployment count into their review and watch what happens next. Commits get split. Trivial changes ship on their own to pad the number. Risky work gets avoided because a failure shows up in the stats. You did not measure performance. You reshaped it, in the wrong direction.
We learned this lesson once already. Microsoft dropped stack ranking in November 2013 after a decade of watching it wreck team behavior. Marcus Buckingham wrote about the damage of rating people on a curve at the time. Fourteen years on, plenty of engineering orgs run a quiet version of the same thing with prettier charts.
Metrics tell you where to look. A human still has to look, and then open their mouth.
The no-surprises rule
Here is what I ask of every engineering manager I work with. One rule, four habits.
The rule: nothing appears in a review for the first time. If it shows up in the document, the person heard it from you already, out loud, close to when it happened.
Say it inside 48 hours
Not next sprint. Not at the one-to-one three weeks out. Within two days, while both of you remember the specifics. Vague feedback is a symptom of late feedback. You forgot the details, so you reach for adjectives.
Say it where the work happens
Feedback lands better attached to a real artifact. A pull request. A design doc. A postmortem. A standup you both sat through an hour ago. Pulling someone into a room strips the context out and turns a small correction into an event.
Write it down the same day
Two lines in a shared doc, visible to both of you. Date, what happened, what you said. Do it right after the conversation. This is the part managers skip, and skipping it is why the evidence problem exists at all. You are not building a legal file. You are building a shared memory neither of you argues about in six months.
Make the review a summary, not a reveal
The review meeting should be boring. Genuinely boring. Everything in it, the engineer heard from you weeks or months ago. You are reading back a story you narrated together. If your engineer's eyebrows move, you have work to do on the other 51 weeks.
Worth adding: your read on someone is one read. If you want the full picture before it hardens into a rating, get input from the people working next to them. Deb and I built a 360 feedback tool at Step It Up HR for this reason, because the loudest voice in a calibration room is rarely the best informed one.
What the surprise costs you
Managers think the cost of a surprise lands on the employee. It lands on you.
You lose the fix. Nine months of a correctable behavior went uncorrected because you held the information. The team absorbed the cost the whole time.
You lose the benefit of the doubt. After one ambush, every future piece of feedback gets received as an attack. You spent your credibility on one meeting.
You lose the person, then the people around them. Engineers talk. One ambushed review becomes a team-wide belief about how the game gets played here. Watch how fast candor dries up after one of those.
You lose the paper trail when you need it. Try building a performance improvement plan on nine months of unspoken observations. HR will ask when you raised it. "I didn't" is not an answer with a good ending.
The test
Here is the check I use, and I would hand it to any engineering leader running reviews this cycle.
Open the review you are about to deliver. Read every line. For each one, answer a single question: when did I say this out loud, and what date was it?
Every line without a date is a line you owe someone. Go say it now, before the meeting. Then delete it from the document, because a surprise saved for the room was never feedback. It was ammunition.
Your next review cycle is coming. How many lines in your drafts have a date on them?