Author: Simon Attard
You bought the better tool. The team quietly went back to the old one
Most owners have lived this. You research the options, invest in the better system, run the training, and send the announcement. For a few weeks it looks like it is working. Then adoption starts to slip.
Someone keeps a private spreadsheet running alongside the new platform. A workaround appears. Within a quarter, half the team has drifted back to the way things were, and the expensive new system becomes a place they update only when reminded.
The instinct is to blame the people. They are stuck in their ways. They will not embrace progress. That explanation is convenient, and it is usually wrong.
Resistance is almost never about the software
When people push back against a new system, they are rarely arguing about features. They are defending something the system quietly threatens.
A new tool takes someone who was fluent and makes them a beginner again. The person who knew every shortcut, who others came to for help, suddenly feels slow and exposed. That is not laziness. That is a loss of competence, and competence is tied closely to identity and status at work. We are also wired to feel a loss more sharply than an equivalent gain, so the discomfort of the change lands long before the promised benefit does.
Underneath most resistance sits a simple set of questions people rarely say out loud. Will I still be good at my job? Do I trust the people asking me to change? Do I understand why this is happening to me? Get those wrong and no amount of software quality will save the rollout.
The failure rate is a people number, not a technology number
The scale of this is easy to underestimate. It is widely reported that a large majority of change and transformation efforts fall short of their goals, a figure McKinsey has long put in the region of seventy percent, and the reasons cited are almost always human rather than technical.
The appetite for change is also shrinking. Gartner found that employee willingness to support organisational change fell to around thirty eight percent, down from seventy four percent a few years earlier. People are tired. When surveyed on why they resist, the answers cluster around mistrust of the organisation, not understanding why the change is happening, and uncertainty about what it means for them.
Notice that none of those are complaints about the technology itself.
What if the resistance is data, not defiance?
Here is where it gets more interesting, and where I think many leaders go wrong. In their Harvard Business Review piece Decoding Resistance to Change, Jeffrey and Laurie Ford argue that resistance is best understood as feedback, not obstruction. Sometimes the person dragging their feet has spotted a real flaw the leadership missed. Sometimes they remember
the last three systems that were announced with the same confidence and quietly abandoned, and they are simply unwilling to invest belief
again.
The uncomfortable part of their argument is that leaders often create
the resistance they then complain about, through poor communication, broken past promises, and treating questions as defiance. The skeptic who keeps asking hard questions is frequently the person who cares most about the work being done properly. Shut them down and you lose
both the insight and the person.
The real question is not how to overcome resistance. It is what it is protecting
I hold both of these views at once, because they are both true. Some resistance is fear and loss, and it needs empathy, a clear and honest reason why, and genuine support while people rebuild their competence.
Some resistance is signal, and it needs listening to, because the system may be flawed or the trust may already be broken.
The practical work is less dramatic than the language of transformation suggests. Bring people into the why before you bring them the what. Give them a real hand in shaping how the change lands, so it becomes theirs rather than something done to them. Protect their sense of being good at their job through the awkward beginner phase. And if past changes were promised and quietly dropped, name that honestly, because people carry it whether you mention it or not.
There is a design lesson in this too. A system that is genuinely easier to use than the old way removes most of the argument before it starts. When we rebuilt the digital presence for GROHE with Alfred Hili and Co, the focus was product led experience: designing around the person using it so the new way feels lighter than the old, not heavier.
Friction is what sends people back to the spreadsheet. Remove the friction and adoption stops being a fight.
Leading people through change has more in common with teaching than instructing. You model it, you make it safe to be new at something, and you let people arrive at the value themselves rather than demanding they accept it on your word. Change lands at the speed of trust, not at the speed of the rollout plan.
How MYC Delivers This
At MYC we treat adoption as part of the design, not an afterthought.
Our work with GROHE through Alfred Hili and Co is a good example: a considered digital rebuild with a product led experience that made the new far easier to choose than the old. That is the same principle
behind any system that actually gets used, whether it is a website, a brand, or a way of working. If you are introducing something new and
want it to land rather than stall, take a look at our work and start a conversation. The best time to think about resistance is before you announce the change, not after it quietly fails.
So before your next rollout, ask the harder question. Not how do I get people to accept this, but what is this change going to cost the people I am asking to adopt it, and have I made that worth their while.