Coaching an Engineer Who Will Not Take Feedback

He was one of the best engineers I had. Fast, precise, the kind of person who could hold a payments reconciliation flow in his head and spot the edge case nobody else saw. He was also, in code review, a brick wall. Every comment came back with a rebuttal. Every suggestion was met with a reason it was wrong, or beside the point, or something he had already considered and dismissed. After three months of this I realized I had stopped leaving comments on his pull requests, and so had everyone else on the team.

That last part is the tell. When an engineer will not take feedback, the failure mode is not a screaming match. It is silence. People quietly route around them, stop investing in them, and let their blind spots calcify. I have coached a handful of these engineers over the years. Some of it worked. Some of it did not. Here is what I have actually learned, most of it the hard way.

This Is Not One Problem, It Is Four

The first mistake I made was treating "does not take feedback" as a single defect with a single fix. It is not. In my experience it is at least four different problems wearing the same coat, and the coaching for each is completely different.

There is the engineer who does not trust that you know what you are talking about. There is the one whose identity is so fused to being right that a code comment feels like an attack on their worth. There is the one who genuinely did not understand the feedback and defends because they are confused, not defiant. And there is the one who heard you perfectly, disagrees on the merits, and is often correct. Before you spend a single ounce of energy coaching, you have to figure out which of these you are dealing with, because if you deploy the wrong intervention you will make it worse.

Rule Yourself Out First

The most uncomfortable question I ask before coaching anyone on feedback is whether the feedback itself was any good. I have watched managers, myself included, hand out vague, taste-based, poorly-timed notes and then label the recipient "defensive" when they pushed back. If your feedback is "I would have done this differently" with no reasoning attached, you have not given feedback. You have given an opinion wearing a badge, and a sharp engineer smells that instantly.

So I audit my own comments before I audit the person. Are they specific? Do they explain the cost of the current approach, not just the preference? Are they arriving in a giant batch at the end, or in a steady, low-stakes stream? I once inherited a team where the tech lead left forty comments on every review, most of them nits about variable names, buried among two comments that actually mattered. The engineers had learned to ignore all of it as noise. The problem was not that they would not take feedback. The problem was that the signal-to-noise ratio was garbage, and they had rationally tuned it out.

Separate the Loud Ones From the Right Ones

The trap with a defensive engineer is that their pushback is loud, and loud gets confused with wrong. But a lot of the time the engineer who argues hardest is arguing because they have thought about it more than you have. If you flatten every disagreement into "won't take feedback," you teach your best people that the way to succeed is to nod and comply, and you will end up with a team of exactly the compliant mediocrity you claim to hate.

So I run a private test. When this engineer pushes back, are they right often enough that the pushback is earning its keep? I actually track this loosely in my head over a few weeks. If someone disagrees with me and turns out to be correct six times out of ten, that is not a coaching problem. That is a person I should be listening to more carefully and probably promoting. The coaching problem is the person who disagrees with everyone and is right about a third of the time but has never once said the words "you're right, I hadn't considered that."

Name the Pattern Without Naming a Verdict

When it is genuinely a behavior problem, the conversation has to happen directly, and it has to happen away from the code. The worst thing you can do is deliver this feedback inside a code review, because now you are giving defensive feedback to a defensive person about being defensive, and the recursion helps no one.

I sit down one-on-one and I describe the pattern in concrete, observable terms, not character terms. Not "you're defensive," which is a verdict and invites a defense. Something like: "In the last four reviews, every comment I left got a counterargument. None of them got a change. I've noticed I've stopped leaving comments. I want to understand what's happening." Then I shut up. The goal is to make the pattern visible and let them react to it, not to hand them a diagnosis to fight.

The most useful sentence I have ever said to a defensive engineer was not advice. It was: "I've stopped giving you feedback, and I don't think that's good for either of us. I'd like to fix that. Help me understand what makes it land badly." Framing it as my problem to solve with them lowered the shield in a way three months of comments never had.

Coach the Behavior, Not the Attitude

You cannot directly coach someone into being less defensive, any more than you can coach someone into being less anxious by telling them to relax. Attitude is downstream of a hundred things you do not control. What you can coach is specific, observable behavior, and then let the attitude follow the behavior if it is going to.

What I ask for, concretely, tends to look like this:

• Before responding to a review comment, restate what you think the reviewer meant, so we both know you actually heard it before you rebut it.
• When you disagree, disagree on the specific technical trade-off, in writing, not on whether the comment should exist at all.
• Pick one piece of feedback per review that you act on without arguing, even if it is minor, so that "acting on feedback" stops being a foreign motion.
• If you think the reviewer is wrong, say so in a fifteen-minute call, not a forty-message thread that grinds the merge to a halt for two days.

These are things a person can actually do on Tuesday. "Be more open" is not. Every time I have made progress with a defensive engineer, it was by shrinking the ask down to a behavior small enough to practice.

Make the Cost Real to Them

Some engineers genuinely do not see the damage, because it is invisible to them by design. The team's silent withdrawal does not show up in their inbox. So part of coaching is making the cost legible. I have said, plainly, "Two people on this team have told me they no longer bring you their design questions because the conversation is exhausting. That is a problem for your career, not just for them, because influence is the whole job at the senior level and you are losing it."

That is a hard thing to hear and I do not say it lightly. But I would rather someone hear it from me in a private room than discover it two years later when they wonder why they keep getting passed over for the staff role they think they have earned. Defensiveness has a real, compounding cost, and connecting it to the thing they actually want, usually growth and standing, is often the moment something shifts. Abstract feedback about "collaboration" bounces off. "You are becoming someone people work around" tends to land.

Know When It Is Not Going to Change

Not every one of these stories has a happy ending, and I am suspicious of anyone who says otherwise. I have coached engineers who intellectually agreed with every word, thanked me sincerely, and were exactly the same six months later, because the defensiveness came from somewhere much deeper than a work habit. At some point you have to make a decision about how much of the team's oxygen one person's ego is allowed to consume.

My rough timeline is a quarter of honest, documented effort. If I have named the pattern clearly, made the cost visible, asked for specific behaviors, and given real coaching, and nothing moves, then the conversation changes from coaching to consequences. That does not always mean firing. Sometimes it means a role where they work more independently and their blast radius on other people is smaller. But I stop pretending the trajectory is upward when the evidence says it is flat, and I stop spending on it the energy that six coachable people deserve more.

Take Feedback in Front of Them

The single most effective thing I have done, and the one I reach for first now, has nothing to do with the difficult engineer at all. It is taking feedback well, visibly, myself. When someone challenges my architecture call in a meeting and they are right, I say so, out loud, specifically: "Good point, I was wrong about the failure mode there, let's do it your way." A defensive engineer watching their CTO change their mind in public, without any apparent loss of status, learns something no one-on-one can teach.

Culture on this is caught more than taught. If the senior people on your team treat being corrected as a small everyday event rather than a wound, it becomes safe for everyone to be corrected. If they treat it as a threat, you can run all the coaching conversations you want and the water will still be poisoned. You cannot ask for a behavior you are not willing to model, especially the ones that require a little ego to be set down.

Conclusion

The engineer I opened with is still on my team, four years later, and now runs a good chunk of our ledger platform. What turned it around was not a clever technique. It was figuring out that his defensiveness was the confusion kind, not the ego kind, that half my feedback had genuinely been unclear, and that once I got specific and started restating his position before critiquing it, he did the same back. He was never going to be the type who says "good point" easily. He is the type who goes quiet, disappears for a day, and comes back having quietly done the thing. I had to learn to read that as acceptance instead of demanding it look like agreement. Sometimes the person is not refusing the feedback. They are refusing the shape you keep insisting it be received in, and the fix is yours as much as theirs.