How to tell your fastest engineer their code reviews are too rushed

Daniel approves his teammates’ pull requests in minutes: a thumbs-up, no comments. Two production incidents this month trace back to changes he waved through. He also closes more tickets than anyone on the team, and he will bring that up before you’ve finished your first sentence.

The mistake is to treat speed and review as one subject. They aren’t. His throughput is the thing you value; his review habit is the thing that’s costing you. This guide covers how to keep those two apart, how to hold the standard when he asks whether you’d rather he closed fewer tickets, and how to leave with one concrete change rather than a promise to “look closer”.

Why this one is hard

He’ll open with “If this is about the incident, the fix is already merged.” That’s a framing move: the incident is closed, so what’s left to discuss? If you accept the frame you’ll end up talking about the fix. The subject isn’t the fix. It’s the review that didn’t happen.

Then there’s the number. He knows his ticket count, and it’s real. Anyone who’s been measured on one figure for long enough hears “be more thorough” as “be slower”, and “slower” as “worse”. You won’t know why that word lands so hard unless you leave the conversation open long enough for him to tell you.

Before you walk in

One subject. Reviews that approve without reading. Not his commit messages, not his standup manner, not the incident fix. The incidents are evidence for the subject, not subjects of their own.

The two incidents. Which pull requests, who authored them, when he approved, how long between the PR opening and his thumbs-up. Minutes, not “quickly”. You’ll be asked, and he’ll have numbers if you don’t.

The credit, said first. You are going to say he ships faster than anyone and you want that to continue. Decide that now, so it comes out before the criticism, not as a consolation after it.

The line you won’t cross. You won’t let “do you want me to close fewer tickets?” become the question. The answer is no. The question is whether a review from him means anything, and right now it doesn’t.

Your opening line

Credit the speed, name the habit, name the cost, in that order and in under a minute.

It’s not about the fix, that’s done. You ship faster than anyone here and I want to keep that. What I want to change is the reviews. Two of this month’s incidents went through your approval in under five minutes with no comments. A thumbs-up from you should mean someone read it.

You’ve answered his opening question, separated the thing you value from the thing you don’t, and put the evidence on the table before he can ask for it.

The version to avoid leads with the incidents and lets him fill in the rest:

So, the two incidents this month. Both went through your review. I think we need to talk about being more careful.

He hears “careful” as “slow”, and from then on he’s defending his ticket count rather than hearing about his reviews.

The three pushbacks you’ll hear

“Sure, I’ll look closer next time.”

The breezy agreement. It costs him nothing and changes nothing, which is why it’s offered so quickly. Don’t take it.

I’d rather agree on something we can both see. For the next month, no approval without at least one comment that shows you read the diff, and nothing under ten minutes on a PR that touches production.

A promise to “look closer” can’t be checked. A comment and a minimum time can.

“So you’d rather I closed fewer tickets?”

Said with the throughput numbers ready. This is the real objection, and it’s a trade he thinks you’re asking him to make. You aren’t.

No. Close the same number. I’m asking for a review from you to be worth something, and right now your approval is the fastest path to production for code nobody’s read.

You’ve refused the trade, which is the only way to stop the ticket count becoming the subject.

“The incidents were the authors’ fault. Reviews were never the safety net.”

The hardest one, because it’s half true. Authors own their code. But a review that approves everything is a safety net with a hole in it, and the hole is what you’re here about.

The authors own their changes, agreed. But if a review doesn’t catch anything, we should stop pretending it’s a step. I’d rather it was a step. What made it feel like theatre?

This is the question that gets you the thing you didn’t know. In this case it might be that his last team measured him purely on throughput, and careful review comments once got him labelled the blocker. You can’t change what “thorough” means to him until you know where the meaning came from.

Where you stop

You’ve credited the speed, named the habit, put the incidents down and asked what made reviews feel pointless. If he’s now telling you about the old team, or asking what a good review looks like here, you’re doing well. Answer the question. Have a short checklist ready, because “send me the checklist and I’ll hold the line on it” is the best ending this conversation has. He’ll add that the sprint numbers are now your problem. Accept that. They are.

If he’s still arguing that the incidents don’t count, say this once:

We can disagree about whose fault the incidents were. Your approval was on both. From Monday a review from you has a comment on it. Let’s start there.

Then set the date and finish. If he goes the other way, “you want slower reviews, you’ve got them, weeks of them”, don’t chase it. That’s a threat made in the heat of the room. Let it sit, send the checklist anyway, and watch what he actually does with the next PR.

Afterwards

Send the checklist the same day, short enough to fit on one screen: what a review from him must include, and the minimum time on anything production-facing. One line at the top: “This is the standard. Your ticket count isn’t part of it.”

Then notice the first review he does properly, and say so where the team can see it. He was labelled a blocker once for doing exactly this. The fastest way to undo that is to make the careful review the thing that gets noticed.