How to deal with a teammate who fights every code review comment

Daniel is a good engineer who answers code review comments with essays, escalations, or silence. Two people on your team have quietly stopped reviewing his work. He’s noticed, and he’s decided it’s a clique. His pull requests sit longer, the reviewers who remain hedge every comment, and the thing you’re really losing is review itself.

You’re not here to re-argue any thread. You’re here to repair a working relationship, and that means two things have to be true when you leave: he knows the pattern and its cost, and he’s agreed to one concrete change. Winning an argument about Tuesday’s comment gets you neither.

Why this one is hard

It’s hard because he’s already written your opening for you. His first line will be something like let me guess, someone’s complained about my tone, and the moment you confirm it, the conversation becomes about who complained. He reads a review comment as a verdict on him, and he’ll read this meeting the same way unless you give him something else to read.

It’s also hard because he has a point, somewhere. Other people on the team are blunt too. If you pretend otherwise, he’ll produce the receipts, and he’ll be right, and you’ll have lost the room.

Before you walk in

The pattern, not the threads. Essays, escalations, silence; two reviewers routing around him; PRs sitting longer. That’s the pattern. Don’t bring a list of examples. If you bring one, he’ll dispute its framing, and you’ll spend twenty minutes on a comment from March.

The cost, in his terms. The cost to him is reviewers. The cost to the team is that review has stopped being a place where people say what they think. Say both, briefly.

The one change you’re asking for. Comments stay on the code. When a thread starts to turn, it moves to a call. When a comment feels personal, he flags it to you, same day, instead of replying. Three parts, small enough to try next week.

The line you won’t cross. You won’t make this a trial of any single thread, and you won’t accept someone else’s bluntness as a reason to drop the ask. Same standard for everyone, including him.

Your opening line

Pattern, cost, and a question that opens rather than corners.

I want to talk about how reviews are going, not any one review. When a comment lands on your PR, the reply is usually an essay, an escalation, or nothing. Two people have started routing around you rather than review your work, and that costs you reviewers. What’s happening for you when a comment comes in?

The question at the end is the important part. It treats the defensiveness as information you want, not an accusation you’re making.

The version to avoid:

A few people have mentioned the tone in your review replies, and I wanted to check in…

It confirms there’s a file, confirms there’s a group, and he’ll ask who. That’s the whole meeting gone.

The three pushbacks you’ll hear

“Fine. I’ll be less spicy. Happy?”

The joke that buys his way out. He’s agreeing to nothing, and by Thursday “less spicy” will mean whatever he needs it to.

I’d rather not settle for less spicy, because neither of us would know what it meant next week. I’m asking for something specific: comments stay on the code, and when a thread starts to turn, it moves to a call.

A vague concession is worse than none. It lets you both leave feeling done without anything changing.

“Give me one example. A specific one.”

He’s moving the conversation to ground where he can win, thread by thread. And he’ll win some of them.

I can, and you’d have a fair point on half of them. That’s why I’m not here about any one thread. I’m here about the pattern, and the fact that people have stopped reviewing you. That part isn’t in dispute.

Once you litigate a thread, you’ve agreed the pattern is the sum of the threads. It isn’t. The pattern is that review has stopped working.

“Here’s what Mark wrote on my PR last week: ‘this is wrong.’ Where’s his meeting?”

The counter-receipt. He’s testing whether this is about behaviour or about him, and the honest answer has to be behaviour.

If Mark’s comment felt personal, flag it to me and I’ll have the same conversation with him. That doesn’t change what I’m asking from you.

Don’t deny the receipt and don’t trade it. Hold the standard and apply it to Mark too, out loud.

Where you stop

The good ending is specific. He says something like: comments on the code, disagreements in a call, and I flag the first one that feels personal to you, same day. I’ll try it. Take it. Say thanks, confirm next week, and don’t add anything.

Somewhere in the good version he may tell you why. At his last company, review threads were used as the evidence in a performance case, and he has the screenshots. He’s never told anyone here. If he says it, don’t rush past it. Say that this isn’t that, and that the fastest way for him to know that is to see what happens the first time he flags one. That reveal is the thing a good conversation surfaces. You can’t ask for it, and you shouldn’t pretend to know it.

If it stalls, say this once:

I’m not building a file. I’m trying to get you reviewers back.

If he says so it is a tone file, send whatever you’re building to HR and copy me, stop. Don’t argue the label; there’s no version of that argument you win in the room. Say you’ll write down what you asked for and send it to him so you both have it, and end the meeting. If HR does come into it, you want the written ask to be the first document in the record, not the last.

Afterwards

Send him three lines that evening: the pattern you described, the change he agreed to try, and the standard you’ll hold everyone to. No examples, no history. If he flags a comment that week, respond the same day, every time, even if the comment was fine. The first flag is him testing whether the agreement was real.

Then make the next one easier: on his next PR, when a thread reaches three replies, call it to a call yourself before he does. Most review fights happen because nobody moved them off the thread.