Leadership · Psychology
When someone on your team pushes back, read it before you react to it
A manager pushes back on something you have asked for. The instinct in the room is almost always the same: treat it as a compliance problem. Explain again, more firmly, why it needs to happen. Most of the time, that instinct is wrong.
Twenty years managing teams across European scale-ups taught me to treat pushback as data before I treat it as defiance. Not because every objection is right. Because most objections carry information that disappears the moment you respond to the tone instead of the content.
Pushback is rarely about the task itself
When someone resists an instruction, three different things could be happening underneath it, and each one calls for a completely different response.
- They see a problem you don't. They are closer to the operational reality than you are, and the instruction conflicts with something they know that you don't yet. This is the most valuable kind of pushback, and the easiest to miss if you respond to the resistance instead of asking what they're seeing.
- They don't trust the reason behind it. The task might be right, but the "why" was never made clear enough to survive contact with their daily reality. People resist instructions more than they resist explanations.
- They are protecting something that already broke once. If a similar request went badly before, under someone else or under you, resistance can be a scar, not an opinion. That one needs a different conversation entirely: about what happened last time, not about what needs to happen this time.
Responding with more authority solves none of these. It just tells the person that the second attempt at that conversation will be more careful, and quieter, next time.
The mechanism underneath it
This connects to something I have written about before: locus of control. People who believe their input changes outcomes raise concerns openly. People who have learned that raising concerns changes nothing stop raising them, and you lose the signal entirely, not just the friction. A manager who still pushes back on you has not given up yet. That is worth protecting, even when the pushback is inconvenient.
The manager who stops pushing back is not the manager who agrees with you. It is the manager who has stopped expecting to be heard.
I wrote more about this mechanism in locus of control and agent disengagement. The same dynamic runs one level up the org chart, between managers and the leaders they report to.
How to actually respond
Three moves, in order, before deciding whether the pushback should change anything.
- Ask what they're seeing, not what they think. "What are you seeing that makes this feel wrong" gets a different, more specific answer than "why don't you agree with this." One invites operational detail. The other invites a debate.
- Separate the task from the trust. If the resistance is really about a past failure, no amount of reasoning about the current task will land until that history is acknowledged directly.
- Decide out loud, either way. If you still need the task done after hearing them out, say so plainly, and say what you heard that didn't change your mind. If they changed it, say that too. Silence about the reasoning is what teaches people that raising concerns is pointless.
What this is not
This is not a case for treating every objection as correct, or for slowing every decision down for consensus. Some pushback is simply resistance to change, and the task still needs to happen. The difference is that you now know that, instead of assuming it, because you asked before you decided. Leaders who skip the asking step end up right about as often as leaders who ask, they just have a worse-informed team by the time they get there.