I have heard the phrase “resistance to change” so many times over the years that I rarely questioned it. A new system is introduced, people start pushing back, and somewhere in a meeting someone inevitably concludes that we have a change management problem. The diagnosis usually arrives remarkably quickly, followed by familiar prescriptions involving more communication, more training, and perhaps another town hall explaining why everyone should be excited about the transformation. Meanwhile, some of the people actually doing the work are sitting there thinking that enthusiasm is wonderful, but it still takes them twice as long to complete Tuesday’s tasks.
A recent transformation has made me question whether we reach for the resistance diagnosis too quickly. I have watched people challenge new processes, question how work will actually get done, and raise concerns about additional steps and inefficiencies being introduced into their day. From a project perspective, that behaviour can easily look like reluctance to adopt the new system. From the employee’s perspective, however, they may simply be pointing out that the shiny new future we have designed is making something harder than it was before.
To be fair, sometimes resistance really is resistance. There are always a few people who avoid the new system like the plague, quietly waiting for someone else to test it, find the problems, survive the problems, and preferably document the solutions before they venture anywhere near it. They attend the training, nod at all the appropriate moments, and somehow remain remarkably unavailable when it is time to actually test anything. I have seen that behaviour too, and I am not suggesting that every objection contains a hidden piece of transformational wisdom waiting to be discovered.
What concerns me is what happens when we put those people in the same category as employees who have engaged with the new process and are telling us it does not work well. If someone has actually tested a future-state process and discovers that it requires more steps, creates duplicate effort, introduces awkward handoffs, or turns something relatively straightforward into a small administrative adventure, their objection deserves a different response. They may not be resisting change at all. They may be doing exactly what we asked them to do by testing whether the new way of working actually works.
This distinction becomes especially important in ERP transformations because it is remarkably easy to confuse a technically functioning system with a well-designed business process. The screen can work perfectly, the workflow can route exactly as configured, and every integration can behave precisely as the design document said it should, while the person sitting at the other end is wondering why they now need three screens, two approvals, and a spreadsheet to accomplish what used to take five minutes. Technically, everything may be working beautifully. Operationally, we may have created a monster.
That is where I think transformation teams need to become a little more curious. When users push back, the first question should not automatically be how we get them to accept the process. We should first understand what they are actually telling us about it. Are they avoiding the system because they do not want to learn something new, or have they tried the process and found a legitimate flaw? Are they uncomfortable because their familiar way of working is disappearing, or are we genuinely introducing unnecessary work? Those situations can look remarkably similar in a project status meeting, but they require very different responses.
There is also an uncomfortable truth buried in all of this. Once a transformation has been underway for months and considerable time and money have been invested, it becomes increasingly difficult to question the design itself. We naturally want to move forward. Deadlines are approaching, testing needs to finish, training needs to happen, and nobody particularly enjoys reopening a process that everyone thought had been settled six workshops ago. At that point, labelling the problem as resistance can be considerably more convenient than considering the possibility that the business might have a point.
The irony is that the people raising concerns are often the people closest to the work. They know which exceptions happen every Tuesday, which customer request never follows the standard process, which workaround exists for a reason, and which seemingly insignificant step will create an hour of additional work downstream. That does not mean they should dictate the design, nor does it mean every legacy process deserves to survive simply because “we’ve always done it that way.” It does mean their frustration can contain operational intelligence that a project team would be foolish to dismiss.
I think this is where good transformation leadership requires judgment rather than a standard response. Genuine avoidance needs to be addressed because eventually everyone has to participate in the change. Legitimate process concerns need something entirely different. They need investigation, discussion, and sometimes the humility to admit that what looked sensible on a process map does not work nearly as elegantly when an actual human being tries to use it for eight hours a day.
Perhaps that is why I have become increasingly uncomfortable with the phrase “resistance to change.” It describes the behaviour we can see without necessarily explaining what is causing it, and once we apply the label, we risk deciding what the solution is before understanding the problem. More communication will not fix a poorly designed process, just as redesigning a perfectly reasonable process will not suddenly convince someone who has decided to wait until everyone else works out the kinks.
The challenge is knowing which one you are dealing with.
When people push back during a transformation, perhaps we should spend a little less time asking how to overcome their resistance and a little more time understanding what the resistance is telling us. Sometimes the answer will be that someone simply does not want to change, and that needs to be managed. Other times, the answer may be considerably more uncomfortable: the people we thought were resisting the transformation were actually trying to make it better.
