"Resistance to change" is the most comfortable diagnosis in organizational transformation. It is comfortable because it removes responsibility from the one who designed the change and transfers it to the team experiencing it, it is comfortable because it sounds technical without being so, and it is comfortable because it suggests that the problem lies with the people, not with the decisions made before they arrived at the process.
But when a team does not adopt a new technology, when users revert to Excel after implementation, when no one uses the system that took months of work, it is almost never because people do not want to change. It is because something in the design of the change failed.
What is really behind it
Fear of losing a role that no one named: When an organization implements automation or AI without having an honest conversation about what will change in each person's work, the team fills that silence with their own conclusions. And the most natural conclusion is the most threatening: they are going to replace me.
Poorly designed processes that the tool does not resolve: There are implementations that automate the problem instead of solving it. The team knows this before anyone else because they live the process every day.
A change that was imposed without context: People do not resist change; they resist changes that they do not understand or that do not seem valid to them.
Insufficient training disguised as lack of willingness. A team that does not know how to use a tool well is not going to use it, and if they also feel that admitting that difficulty is a risk, they will avoid it in silence.
What leadership almost never asks
→ Did we explain to the team what will change in their work and what will not change?
→ Did we design the process before choosing the tool or did we choose the tool and then look for the process to fit?
→ Did we involve those who live the process in the design of the solution?
→ Do we measure the success of the implementation with real adoption metrics — or just with delivery metrics?
What a well-managed technological transition looks like
It is not a frictionless transition; friction is inevitable and in many cases, it is healthy. It is a sign that something is truly changing, as what differentiates a well-managed transition is that the friction is anticipated, named, and accompanied. The team knows what will change and why, they had space to ask uncomfortable questions before the system went live. The process errors were incorporated into the design instead of being ignored.
The question worth asking before naming the resistance
The next time a technological transformation process encounters friction, before diagnosing resistance to change, it is worth asking: Was the change well designed? Did the team have enough information? Did anyone listen to what they had to say before implementing? Because sometimes what we call resistance is simply the judgment of people who understand the process better than anyone and are saying, in the only way they have left, that something is not right. Listening to them is not yielding to change; on the contrary, it is designing it better.