Innovation and resisting change
Every business has someone pushing to modernise and someone saying they tried that once. Both are usually partly right. Why resisting change is information rather than obstruction, why changing for its own sake costs just as much, and the one question that settles most of the argument.
Most businesses of any size contain both people. One says the place is falling behind and should be doing more with AI. The other says they tried something like this a few years ago, it was a disaster, and nobody wants to go through that again. Each is quietly convinced the other is the reason nothing gets better.
In our experience both are usually partly right, and the argument is almost never actually about technology.
Resisting change is information
When somebody will not use a new system, the instinct is to treat it as an attitude problem and apply more training. Sometimes that is what it is. More often the person knows something the plan did not account for.
The customer who always pays late and has an informal arrangement with the office. The job type that does not fit the form because it never has. The step two people assume is redundant and is actually the only place anybody checks the figure. None of that is written down anywhere, which is precisely why the new system does not handle it.
The person refusing to use the new system is often the only one who knows what it cannot do yet.
Treating that as obstruction wastes the most valuable information available to you, and it is usually available for free, early, from somebody who would rather tell you than be blamed later.
Four reasons people resist, and only one of them is stubbornness
| What is actually going on | What it sounds like | What to do about it |
|---|---|---|
| It costs them something real: status, autonomy, or a skill they are good at | “I do not see why we need to change” | Name the cost out loud. People accept a loss they can see far better than one nobody will admit to |
| They have watched this fail here before | “We tried that” | Ask what happened last time. It is the cheapest risk assessment you will ever get |
| It genuinely is worse for their part of the job | “It takes me longer now” | Check whether it is true, because it often is. The saving may be real and sit somewhere else entirely. Say so rather than denying their experience |
| Nobody has told them what happens to their job | Silence, then quiet non-use | Answer the question directly, including when the answer is uncomfortable |
Only the first of those is anything like what people mean by resistance to change, and even that is a rational response to an unacknowledged cost rather than a character flaw.
The opposite failure is just as expensive
Changing things for the sake of it has a cost that almost never appears on a business case. A business that replaces its core systems every couple of years never gets good at any of them. Every migration loses a little institutional knowledge, every new tool resets everyone to beginner, and the people who learned to work around the last system start building workarounds for this one.
The tell for this is a change described in terms of the technology rather than what it does. If the case for a project is that it is modern, or that competitors have one, there is no case. The question is what it changes about how a job gets done, and if that cannot be answered in a sentence, the project is not ready.
One question settles most of these arguments
Ask: what does this cost, and who pays it?
Every change costs something, and the cost is rarely carried by the people who get the benefit. The business gets the saving; one team carries an extra step. Leadership sees a cleaner report; somebody in operations now enters data twice during the transition. None of that makes the change wrong. Refusing to say it out loud is what makes it fail.
Once the cost and the person carrying it are both named, the conversation usually stops being about whether to change and starts being about how, which is a much more productive argument to have.
What actually works
Put the person who does the job in the room while it is being designed, not after. They will tell you about the exceptions nobody documented, and they will not have to defend their territory against a design that already excluded them.
Pilot on real work rather than a demonstration. Demonstrations use the clean example. Real work is where the awkward cases live, and the awkward cases are what decide whether the thing survives.
Name who owns it afterwards. A system with no internal owner drifts out of step with how the business actually works, and eventually somebody starts doing it by hand again “just for now”.
And the one that does the most work: give the loudest sceptic the job of listing everything the new system must not break. It is a real job, they are better at it than anyone else, and it turns the person arguing against the project into the person responsible for it being right.
The short version
Resisting change is usually information rather than obstruction, and the people doing it are often protecting something real that nobody wrote down. Change for its own sake costs as much as changing nothing, and hides the cost better. Ask what this costs and who pays it, answer honestly, and most of the argument resolves itself.
Stuck between the two camps?
Our Business Process Optimisation work starts by mapping how the job actually gets done, with the people who do it. That tends to settle the argument faster than another meeting about it.
Before you hand over your code
Changing developer is ordinary. It only turns into a recovery operation when the domain, the hosting or the code are in somebody else's name. What to check, and what to ask for while everyone is still speaking.
Before you build a dashboard
Most people think of Power BI first, and for good reason. But "dashboard" covers two different jobs that are modelled differently underneath, and knowing which one you need makes the choice simple.