To give feedback to someone who tends to get defensive, make the conversation feel less like a threat before you get to the issue. Talk to them privately and soon after it happens, and pick one thing. Describe a specific behaviour and its impact rather than their character, then ask for their view before you suggest a fix. If they push back, don’t push harder. Acknowledge how they’re feeling, go back to the facts, and be willing to finish the conversation another day.
That’s the short version. The longer one is below, because I’ve had feedback conversations go wrong the same way more times than I’d like to admit: I raise something, the other person’s shoulders go up, and from that moment neither of us is really listening.
Why people get defensive in the first place#
Defensiveness isn’t stubbornness, or at least it rarely starts that way. It’s what people do when they feel threatened, and feedback threatens more than we tend to think. You’re nominally talking about a pull request or a missed deadline. What the other person hears is a question about whether they’re good at their job, whether they belong on the team, whether you’ve been quietly thinking this for months.
Once someone feels that, their attention goes to protecting themselves, not to the point you’re making. Arguing harder only confirms the threat. So most of what works below is about lowering the stakes first and only then getting to the substance.
It also helps to remember that some people come into these conversations already bruised. A previous manager who only ever spoke up to criticise, a culture where mistakes got people sidelined. You can’t fix that history in one meeting, but it explains why a mild comment sometimes gets a much bigger reaction than it deserves.
Before the conversation#
Most feedback conversations are decided before they start. A few things I do now that I didn’t used to:
I pick one thing. If I’ve saved up five issues, the person hears a prosecution, not feedback. The other four can wait, and often turn out to be symptoms of the first one anyway.
I do it soon. Feedback about something that happened six weeks ago lands as “why are you only telling me now?”, which is a fair question with no good answer. A day or two after the event is about right: soon enough that it’s fresh, late enough that neither of you is still hot.
I do it privately, and I don’t do it over chat if I can avoid it. Written feedback loses tone, and a defensive reader fills the missing tone in with the worst possible version. If it has to be written because the team is remote or across timezones, I keep it short and offer a call.
And I check my own state. If I’m annoyed, the other person will pick it up within the first sentence, whatever words I use. Some feedback I’ve given would have gone much better if I’d waited until I’d stopped being irritated.
What to actually say#
The structure I keep coming back to is the one usually called situation, behaviour, impact (SBI): when it happened, what they did, and what it caused. The point is that each part is observable. There’s nothing in it about who they are, only about what happened.
Here’s the difference in practice. Say a developer merged a change on a Friday afternoon without waiting for review, and it broke checkout over the weekend.
The version that gets walls up: “You always rush things out. You need to be more careful.”
The version that has a chance: “On Friday the payment change went in without a review, and checkout was down for a few hours on Saturday. I’d like to understand what happened, because I don’t think it was carelessness.”
The second one names one event, says plainly what it cost, and ends by assuming good intent. “Always” and “never” are the words that do the most damage. They turn one incident into a judgement of character, and the other person will immediately think of the counterexample that proves you wrong.
I also try to own the observation. “I noticed” and “I’m concerned” are honest about the fact that this is my view, offered from my side, and they leave room for me to have missed something. Often I have.
Then I stop talking and ask. “How did it look from your side?” There’s usually context I didn’t have, like a deadline someone else set or a reviewer who was off sick. Even when there isn’t, the question tells the person this is a conversation and not a verdict.
Feedback also lands far better with a way forward attached. Not a list of problems but “next time, could we…”. Better still if the way forward comes from them.
When they push back anyway#
You can do everything right and still get resistance. It tends to come in a few recognisable forms, and each one needs a slightly different response.
The most common is denial: “that’s not what happened.” Don’t argue about it. Go back to what you both can see, like the commit, the message or the date, and ask what you’re missing. If the facts really are disputed, it’s fine to say “let’s both look at it again and pick this up tomorrow.”
Then there’s deflection, as in “well, the requirements kept changing” or “so-and-so does it too”. There’s often some truth in it, so acknowledge it rather than dismissing it: “That’s fair, and we should fix the requirements problem too.” Then bring it back gently: “Separately from that, I want to talk about the review step.”
A counter-attack, like “you merge things without review all the time”, is the hardest one not to match. Take a breath. If they’re right, say so, because it’s the fastest way to lower the temperature, and you’ve just shown the openness you’re asking them for. Then come back to the original point.
Shutting down, whether that’s silence or “fine, whatever you say”, looks like agreement and isn’t. I’ll name it softly, something like “it seems like this didn’t land well, and that’s okay”, and offer to continue later. Forcing a response from someone who’s withdrawn just gets you a fake one.
Over-apologising (“I’m terrible at this, I’m so sorry”) is defensiveness too, just pointed inwards. The person is protecting themselves by getting the criticism in first. Reassure them that it’s one specific thing and not their whole performance, and move on to what happens next.
Through all of these, the one rule I try to hold is not to match their energy. When someone gets defensive, my instinct is to get defensive right back, and that’s the one move guaranteed to sink the conversation. If I stay level, the temperature usually comes down on its own. It helps to say the feeling out loud, something like “I can tell this is frustrating to hear”, rather than pretending the tension isn’t in the room.
Know when to stop#
Sometimes none of it works and the walls stay up. Pushing harder at that point achieves nothing. It’s fine to park the conversation and come back in a day or two once things have settled. The feedback will still be true tomorrow, and people are often much more reflective once they’ve had a night to sleep on it. Some of the best follow-up conversations I’ve had started with the other person saying “I’ve been thinking about what you said.”
That one took me the longest to learn.
After the conversation#
What happens in the following week matters as much as the conversation itself. If the person changes the behaviour, say you’ve noticed, explicitly and soon. That’s how they learn feedback from you isn’t only ever bad news, and it makes the next conversation easier.
And ask, when it fits, how the feedback landed. “Was that fair?” balances things and shows the openness you’re hoping for in return. When I moved into management I started doing this routinely, and it caught a couple of times where I’d been clearer in my head than out loud.
In short#
Lower the threat before you raise the issue. Pick one thing, raise it privately and soon, describe the behaviour and its impact rather than the person, and ask for their side before suggesting a fix. When they push back, don’t match it. Acknowledge the feeling, return to the facts, and be willing to stop and pick it up another day. Then follow up, because the conversation after the conversation is where trust gets built.