Resistance Is Information
People who push back on a change usually have reasons. Treating resistance as data rather than obstruction surfaces risks you missed, and occasionally tells you the change should stop.
Somewhere in the second or third month of most transformation programmes, the language shifts. The early framing — engagement, communication, bringing people along — gives way to something harder. There are pockets of resistance. Certain individuals are blockers. We need to identify who is not on board.
At this point the programme has usually stopped learning. Once resistance is categorised as an obstacle, the only available responses are persuasion, pressure and removal, and none of those involve finding out anything. The alternative posture is not softer. It is more demanding: treat every instance of resistance as a report from someone with information you do not have, extract the content, and then decide what to do. Some of it will be positional defence dressed as concern. A surprising amount of it will be correct.
This is not a plea for consensus. Changes worth making are usually opposed by someone whose interests are genuinely harmed, and waiting for universal enthusiasm is a recipe for doing nothing. It is a plea for a specific discipline: separate the content of an objection from the motive behind it, because those are independent, and the habit of inferring the first from the second is how organisations lose access to their own risk knowledge.
The rational reasons people resist
Start from the assumption that the person in front of you is behaving sensibly given their position, and the behaviour usually becomes legible.
Incentives point the other way. A regional manager measured on cost per unit is being asked to support a change that will raise cost this year and lower it next. A delivery manager bonused on on-time, on-scope delivery is being asked to embrace scope variability. These people are not resisting the change; they are responding correctly to the compensation and appraisal system the organisation built. Until that system changes, their resistance is the system working as designed, and arguing with it is a category error.
Status and identity are at stake. Expertise that took fifteen years to build is being devalued. A person whose authority derived from controlling an approval gate is being told the gate is going. Someone who was the one person who knew how the batch process worked is being asked to document it. These are real losses, and the fact that they are personal does not make them illegitimate. Organisations are quick to describe this as ego and slow to notice that they are asking people to give up the thing they were rewarded for developing.
They know risks you do not. This is the category that matters most and is dismissed most often. The operations lead objecting to weekly releases may be remembering the incident from four years ago that nobody wrote down. The compliance officer's apparently pedantic point may be the thing that fails an inspection. The engineer who says the decoupling will not work is frequently the only person who has read the whole codebase. Domain knowledge is unevenly distributed and it correlates with tenure, which also correlates with scepticism about change programmes — so the people most likely to be labelled resistors are disproportionately the people holding the risk knowledge.
They have seen this before. In an organisation on its third or fourth change programme, the sceptics are not being cynical; they are being empirical. They have watched previous programmes arrive with the same vocabulary, consume two years, and leave behind a vocabulary. Their prior is well-founded, and it is unreasonable to treat a well-founded prior as an attitude problem. The only thing that updates it is evidence, which means early, visible, kept commitments rather than better messaging.
The change is genuinely bad for them. Sometimes the honest answer is that the change makes someone's job worse, smaller, or non-existent. Pretending otherwise is the most reliable way to lose the room, because everyone can see it.
Distinguishing principled objection from positional defence
Both exist, and both sound similar at first. The distinguishing features are not about tone — positional defence is often polite and principled objection is often blunt.
| Principled objection | Positional defence | |
|---|---|---|
| Specificity | Names a mechanism and a scenario | Stays general, cites culture or fit |
| Falsifiability | Can say what evidence would change their mind | Objection survives any evidence |
| Stability | Same objection each time | New objection each time the last is answered |
| Scope | Concerns the outcome | Concerns the process, the pace, or the mandate |
| Offer | Proposes an alternative route to the same goal | Proposes delay or further study |
| Forum | Raised openly | Raised sideways, after the meeting |
The moving-objection pattern is the clearest signal. If you answer the concern about regulatory risk and the concern becomes tooling, and you answer tooling and the concern becomes timing, you are not dealing with an argument; you are dealing with a position looking for a justification. The correct response is not to answer the fourth objection. It is to say, plainly and without hostility, that you have noticed the objection keeps moving and to ask what the real concern is. This conversation goes better than people expect, because the person usually knows they are doing it.
Two cautions before applying this table. First, an objection raised sideways is frequently a symptom of the organisation's information culture rather than of the individual's character — in a Westrum pathological or bureaucratic environment, raising a concern openly is punished, so it goes underground. If most of your resistance arrives indirectly, the diagnosis is about the environment, not the people. Second, someone can hold a principled objection and have their interests threatened at the same time. Those coexist routinely. The interest does not invalidate the argument, and the argument does not excuse ignoring the interest.
Working with the middle layer
Middle management is where transformations are most often stalled and most often blamed. The framing of the "frozen middle" is common and mostly unhelpful, because it describes the symptom as though it were a disposition.
What is actually happening is structural. The middle layer is being asked to implement a change that removes a substantial part of its historical function — allocating people, approving decisions, aggregating status upward, coordinating between silos — while remaining accountable for exactly the same results, usually against unchanged targets, and with no description of what the job becomes afterwards. Senior leadership gets a new narrative and a place in it. Teams get autonomy and new practices. The middle gets a reduction in authority and silence about their future. Resisting that is not frozen; it is rational.
Three things change the dynamic.
Describe the destination job concretely. Not "servant leadership" as a slogan, but the actual content: capability building, removing systemic impediments, managing the flow of work across teams, owning the health of the system rather than the allocation of people. People can move towards a described role. They cannot move towards an adjective. See what-happens-to-middle-management.
Change what they are measured on at the same time as what they are asked to do. Asking a manager to stop assigning work while still holding them to a utilisation target is asking them to accept a worse appraisal for the programme's benefit. Very few people accept that trade, and the ones who do are taking a personal risk that the organisation has not acknowledged.
Give them a real role in designing the change. Not consultation theatre — actual design authority over some part of it. The middle layer holds the operational detail that determines whether a design survives contact with reality, and involving them converts the most dangerous constituency into the one with ownership. This is the part of Kotter's guiding-coalition idea that most programmes implement as a steering committee of directors, which is precisely the layer that already agrees.
Compliance is not commitment
An organisation can compel compliance. It cannot compel commitment, and the difference determines whether anything survives the programme's end.
Compliance looks like this: the ceremonies happen, the boards are updated, the reports are filed, and the attendance is full. It is indistinguishable from commitment on a dashboard, which is why maturity assessments are so unreliable. Underneath, nothing has been internalised, no judgement has been changed, and the moment the coaching stops or the pressure moves elsewhere, behaviour reverts within weeks.
The tests are qualitative and quite reliable. Does anyone adapt the practice to their context, or is it performed exactly as instructed? Adaptation requires understanding the purpose; rote performance does not. Does anyone bring you a problem the practice revealed, or do you only hear that everything is going fine? Does anyone argue with you about the detail? Silent agreement from a group that was sceptical a month ago is almost never a conversion; it is a decision to stop spending energy.
The uncomfortable implication is that mandate produces compliance at best. Where you have genuine authority, use it for the structural changes — funding, boundaries, decision rights, measures — which are things you can legitimately decide and which change the conditions everyone else operates in. Do not use it to mandate behaviours, because behaviours under mandate are performed rather than adopted, and you will have converted a visible disagreement into an invisible one.
When the resistance is right
The hardest discipline is holding open the possibility that the change should not proceed, and meaning it.
There are several conditions under which stopping is the correct decision. The change may be wrong for this context: a practice that works in a product organisation applied to a domain with genuinely different constraints — long-cycle regulated work, safety-critical systems, hardware dependencies. The prerequisites may be absent: asking teams to release weekly when the deployment pipeline cannot support it is not a change, it is an instruction to fail. The timing may be impossible: an organisation absorbing a merger, a regulatory programme and a platform migration has no change capacity left, and adding a fourth guarantees that all four are done badly. Or the cost may exceed the benefit: some coordination overhead is genuinely cheaper than the architectural work that would remove it, on this system, this year.
In each case, the people telling you this are usually telling you early and being ignored, and the information reaches leadership eighteen months later as a post-implementation review.
Making "stop" a real option requires two things. It must be safe to say — which means someone senior has to visibly change their mind at least once, in public, on the basis of an objection raised from below. And there must be a defined route for it: a standing mechanism where evidence against the change is reviewed on the same footing as evidence for it. If your programme has a risk log that only contains delivery risks and never contains "the approach may be wrong for this area", you do not have that route.
There is a middle option that is underused: pause and test. Where an objection is specific and falsifiable, run the experiment. Give the sceptic a defining role in the design of the test and agree in advance what result would settle it. This converts an argument into an empirical question, and it is the closest thing to a reliable method for changing minds in either direction — including yours.
What to do on Monday
List the three people most often described as blockers in your programme. For each, write down what they would lose if the change succeeded — in status, authority, measured performance or workload. Be specific and unflattering to the programme. If you cannot answer for someone, you do not yet understand their position well enough to have a useful conversation with them.
Then go and ask each of them, individually and away from their management line, what would have to be true for this to work that they do not believe is true today. Write down the answers verbatim. Do not defend anything in that meeting; your only job is to collect.
Sort the answers into three piles: things that are already true and simply not known, which are a communication problem; things that are not true but could be made true, which are now your backlog; and things that are not true and cannot be made true here, which are the real constraint on the change and which you have just discovered far earlier than you otherwise would. Take one item from the middle pile, fix it visibly within a month, and tell the person who raised it that it came from them. That single act does more for the programme's credibility than any amount of communication strategy, because it demonstrates the only thing people are actually testing for — whether saying something true has any effect.