A company decides to change something: a new system, a new process, a better way of working. It is well intentioned and often genuinely better on paper. Then it meets the people who have to live with it, and it runs into resistance. The usual explanation is the comfortable one: people are stubborn, they fear change, they are attached to the old way. So leadership pushes harder, mandates the new process, and treats the pushback as an obstacle to be overcome. This is almost always a mistake, because it throws away the most useful information available. Resistance to a change is rarely stubbornness. It is a signal, and the people pushing back usually know something the design missed.
The instinct to read resistance as irrationality is understandable, but it is wrong far more often than it is right. People who do a job every day are not, as a rule, opposed to their own lives getting easier. When they push back on a change that is supposed to help, the far more likely explanation is that from where they sit, it does not help, and they can see a reason you cannot see from where you sit. That reason is worth more than their compliance.
Resistance is usually rational
Start from the assumption that the people resisting are behaving sensibly, and the picture changes. A new process that is better for the organisation as a whole can be plainly worse for the individual asked to follow it. It might add steps to their day, remove a shortcut they had quietly relied on for years, or take away the discretion they used to handle the messy cases that never fit the tidy version. From the top, the change looks like an obvious improvement. From the desk where the work happens, it looks like being handed a slower, clumsier tool and told to be grateful. The resistance is not a failure to understand the benefit. It is an accurate read of a cost the design ignored.
They know something you don't
The deeper reason resistance is worth listening to is that front-line people hold knowledge the designers of the change usually lack. They know the exceptions, the edge cases, the informal steps that keep the real work moving, the reasons behind practices that look pointless from a distance. A change designed without that knowledge will often fail exactly where their objection predicts, because the objection is not vague discomfort; it is a specific, concrete case the new way cannot handle. When someone says this will not work, they frequently mean this will not work for the Tuesday delivery that always comes in wrong, or this removes the check that catches the error we get every month. That is not resistance to change. That is a bug report you are choosing to ignore.
The cost is often just in the wrong place
Even when a change is genuinely good overall, it often fails because of where its costs and benefits land. The effort of changing, learning the new system, giving up the familiar shortcut, absorbing the disruption, falls on one group of people, while the benefit shows up somewhere else entirely, in a report a manager sees or a number on a dashboard two levels up. Asked to do more work so that someone else's job gets easier, people resist, and they are not wrong to. This kind of resistance is not a signal that the change is bad. It is a signal that the incentives are misaligned, and the fix is not to push harder but to make sure the people bearing the cost also see some of the benefit, or at least that the trade-off is named honestly rather than pretended away.
Forcing it through buries the problem
The reason mandating compliance is so tempting is that it appears to work. The rollout completes, the numbers say the new system is in use, and the resistance seems to have been overcome. What has actually happened is usually that the resistance has gone underground, which is far worse than resistance you can see. People comply where they are watched and revert where they are not. They follow the new process to the letter in a way that quietly breaks things, a kind of malicious compliance that is technically obedient and practically useless. Or they build workarounds, unofficial spreadsheets and side channels, to get the real work done despite the system, and now you have a new layer of hidden, manual work on top of a system nobody trusts. The problem the resistance was pointing at has not been solved. It has just been made invisible, which means it will cost far more to fix later.
A worked example
A distribution business we worked with had rolled out a new order-entry system that the operations team openly disliked, and leadership had decided the team was simply resistant to change. When we sat with the team, the resistance turned out to be entirely specific. The old system had let them enter an order and fix the details afterward, which mattered because a large share of their orders arrived incomplete and were corrected by a phone call an hour later. The new system demanded every field up front, so the team had invented a workaround, entering fake placeholder data to get past the screen and correcting it later, which was slower than the old way and quietly corrupting the data everyone downstream relied on. Nobody at the top knew this was happening; they only saw reluctance. The team was not being stubborn. They were absorbing a design decision that did not fit how their orders actually arrived, and their resistance had been trying to tell everyone exactly that. We changed the system to allow a genuine draft state, the workaround disappeared, and the same team that had been labelled change-averse adopted the fix immediately, because this time it fit their reality.
Treat resistance as diagnosis, not defiance
None of this means every objection is right or that no change should ever be pushed. Sometimes resistance really is habit, and sometimes a hard trade-off genuinely has to stand. But the way to tell the difference is to get curious before you get firm. When a change meets resistance, the first move is not to overcome it but to understand it: find out what the people closest to the work know, what the new way breaks for them, and where the cost is landing. Then decide honestly whether to change the design, realign the incentives, or explain a trade-off that has to hold. Do that, and resistance stops being an obstacle and becomes the cheapest, most honest source of feedback you have on whether your change will actually work. Ignore it, and you will get compliance instead of adoption, which looks the same in a status report and is worth almost nothing in practice.
Reading resistance as information and designing change that fits how the work actually happens, so that adoption is real rather than merely reported, is exactly what our change management and adoption work is built around: getting the people who do the work into the design early, so the new way survives contact with reality. Book a discovery call and we will help you turn pushback into a better change.
Frequently asked questions
Why do people resist new systems and processes?
Usually for reasons that are rational from where they sit, not because they dislike change in the abstract. The new way is often genuinely worse for the person doing the work, even when it is better for the organisation: it adds steps, removes a shortcut they relied on, or strips out discretion they used to handle awkward cases. Sometimes it was designed without the knowledge the front-line staff hold, so it fails on the exceptions they deal with every day. And often the cost of changing falls on them while the benefit accrues somewhere else. Resistance is what you get when a change asks people to absorb a cost or a worse experience that the design never accounted for.
Is resistance to change a sign the change is wrong?
Not necessarily, but it is a sign that something has been missed, and it is worth treating as information rather than an obstacle. Sometimes resistance reveals a genuine flaw: the new process does not handle a real case, or it makes someone's job materially harder for no offsetting gain they can see. Sometimes it reveals a communication or incentive gap rather than a design flaw. Either way, the resistance is data about the difference between the change as designed and the change as it will actually be lived. Dismissing it as stubbornness throws that data away and usually guarantees the change fails quietly later.
How should leaders respond to resistance to a change?
By getting curious before getting firm. The most useful first move is to find out what the people resisting actually know, because they are often closest to the work and their objection frequently points at a real gap. Ask what the new way breaks for them, what case it fails to handle, and what it costs them that it did not cost before. Then decide honestly whether the answer is to change the design, change the incentives so the cost and benefit line up, or explain a trade-off that genuinely has to stand. Forcing compliance without doing this does not remove the resistance; it drives it underground into workarounds and quiet non-adoption that are harder to see and fix.
What happens if you force a change through despite resistance?
You usually get the appearance of adoption without the reality. People comply where they are watched and revert where they are not, or they follow the new process to the letter in a way that quietly breaks the work, or they build unofficial workarounds to get their job done despite the system. The underlying problem the resistance was pointing at does not go away; it just stops being visible, which makes it far more expensive to fix later. Forcing a change through can win the rollout and lose the outcome, leaving you with a system everyone technically uses and no one actually relies on.