It is what happens before people have even properly experienced it.
I have worked with organizations of different sizes and implemented different types of HR technology, including platforms such as SAP S/4 Hana, SuccessFactors and, more recently, i-XALL. Across these experiences, I have repeatedly encountered what organizations commonly describe as “resistance to change.”
But over time, I have become increasingly uncomfortable with that phrase.
Calling someone resistant can be an easy explanation. It puts the problem on the employee: We have introduced something better, but they don't want to change.
My experience has taught me to ask a different question:
What is this resistance trying to tell us?
When Silence and Delay Become “Resistance”
One experience has stayed with me.
We were trying to move an organization away from heavily manual HR processes. Payroll was being run using Excel, financial reports were being manually compiled, and a significant amount of information existed in paperwork.
The reasons for introducing an HR system seemed obvious. The existing processes consumed time and created opportunities for errors. A digital system could simplify much of this work.
At least, that was how we saw it.
Then the implementation started slowing down.
We needed data, but it wasn't arriving. Responses were delayed. We followed up and then followed up again.
From a project-management perspective, it would have been very easy to put a label on what was happening:
Resistance.
After several attempts to reach the people involved, I decided to try something decidedly less technological.
I went to their premises and invited them for coffee.
Instead of talking about deadlines and outstanding data, I tried to make them comfortable enough to tell me what was really happening.
Eventually, they did.
The implementation was creating stress for them. Compiling the information we were requesting from all their spreadsheets and paperwork was difficult and time-consuming. What we saw as a data request, they experienced as another enormous task on top of an already complicated way of working.
That conversation changed the situation.
I assured them that we would guide them through it. I explained that if we could get through the implementation together, the system should ultimately remove a significant amount of the stress created by those manual processes.
I even jokingly promised that if their stress didn't reduce afterwards, I would buy them lunch for a month.
It was a light-hearted comment, but there was a serious lesson behind the conversation.
They didn't need another follow-up email.
They needed someone to understand why they weren't responding.
Sometimes the Problem You Are Solving Creates the Implementation Problem
There was an irony in that experience that I only fully appreciated afterwards.
We were introducing technology partly because existing manual processes were heavy and inefficient. Yet those same heavy processes made it extremely difficult for employees to prepare the data required to implement the technology.
The problem we were trying to solve had become an obstacle to solving it.
My initial expectation of what these employees needed was therefore wrong.
They weren't a client moving neatly from one established HR system to another. They were moving from Excel, paperwork and deeply established manual routines into a fundamentally different way of working.
That required more than conventional system training.
It required mentoring, patience and considerably more guidance.
Research into information-system implementations supports this distinction. Studies have found that employees can resist not only the technology itself but the changes it creates in established work routines. Perceptions of whether the new routines are useful and easy to perform can significantly influence resistance.
That distinction matters.
We often ask:
“Why aren't they accepting the system?”
Perhaps we should also ask:
“What are we asking them to stop doing, start doing or relearn?”
Resistance Is Not Always Rejection
My thinking about resistance has changed considerably across implementations.
Today, if somebody tells me, “Mary is resistant to change,” I don't immediately accept that description.
I want to know:
Why is Mary resistant?
What has she actually said or done?
What is she afraid will happen?
What previous experience has shaped her expectations?
Has she been exposed to organizational change before?
Was she prepared for this change, or did we simply announce it to her?
And perhaps most importantly: Does Mary have a point?
I have personally experienced situations where users challenged aspects of a system that I initially saw differently. When I stopped looking at the process from the implementation perspective and looked at it through their eyes, I realized that some of the complexity they were identifying was real.
They weren't necessarily obstructing the project.
They were giving us information.
This is something the research literature has also recognized. User resistance can range from passive to active behaviour, but researchers have argued that resistance can also provide useful information about problems surrounding organizational and technological change.
That has become an important principle for me:
Before trying to eliminate resistance, listen to what the resistance is telling you.
People Bring Their Previous Technology Experiences With Them
I encountered another version of this while implementing i-XALL.
Some users approached the technology with assumptions formed through their previous experiences with HR systems. Before properly using the new system, they expected processes such as entering information and running payroll to involve the same kind of complexity they had experienced before.
This is where I learned the importance of demonstration.
Rather than continuing to explain what the technology could do, we showed them live processes in workshops.
Then we let them do it themselves.
That second part was crucial.
You can explain to someone ten times that a process is simple. That doesn't necessarily remove their fear.
But when they perform the process themselves and realize, “I can actually do this,” something changes.
I have watched people visibly relax at that moment.
The intimidating idea of the new system becomes an experience they can understand.
Research into HR technology adoption provides some support for what I was observing. Perceived usefulness and ease of use have long been important factors in technology acceptance research, while studies specifically examining HR technology have identified inertia, switching costs and perceived threat among factors associated with resistance.
This means that demonstrating simplicity is not merely system training.
It can be part of change management.
Speak Human Before You Speak Technology
Technology projects have their own vocabulary.
Implementation teams naturally talk about integrations, configurations, workflows, migration, automation, APIs, environments and increasingly AI.
These terms may be perfectly normal to someone working with technology every day.
They are not necessarily normal to the person who has spent years processing payroll through spreadsheets and paper.
Sometimes sophisticated language unintentionally makes the transformation sound more frightening than it actually is.
An employee hears a complicated explanation and concludes:
“I'm not going to understand this.”
Once that belief takes hold, we may later describe their behaviour as resistance.
That is why one of my strongest lessons has been to speak the language of the person, not simply the language of the system.
When I say that I try to understand someone's “mentality” before implementing change, I don't mean categorizing people as technological or non-technological.
I mean understanding how they think about their work.
How do they believe the process works?
How would they like it to work?
Which parts frustrate them?
What do they believe the new system will do to their role?
Then I can explain the technology in relation to something that matters to them.
If someone spends hours manually compiling information, don't begin by selling them “digital transformation.”
Show them the hours they could get back.
Five Things I Would Do Before Introducing Another HR System
If another Head of HR asked me what I would do before introducing a major HR system, my answer today would be very different from simply creating a communication and training plan.
First, understand the people before introducing the technology. Study the existing processes, but also speak to the people performing them. Ask how they work, where they struggle and how they think the process could work better.
Second, find the fear behind the resistance. Don't assume reluctance means stubbornness. It could be previous experience, perceived complexity, workload, lack of confidence or fear of losing control. Research into HR technology has similarly associated resistance with factors including inertia, switching costs and perceived threat.
Third, show rather than simply tell. Demonstrate real processes that employees recognize, and then let them perform those processes themselves. The moment somebody experiences simplicity can be much more powerful than repeatedly being told that something is simple.
Fourth, prepare employees for change before go-live. Change management should not be something we activate when resistance appears. Employee participation during technology implementation has been associated with more positive perceptions and greater satisfaction with new technology, while more recent digital-transformation research continues to emphasize employee participation rather than treating transformation as purely technological.
Finally, recognize that different starting points require different levels of support. An experienced user moving from one modern HCM platform to another and an employee moving from years of spreadsheets and paperwork are not undertaking the same journey. Giving them identical training does not mean we have given them equal preparation.
Perhaps We Should Stop Trying to “Eliminate” Resistance
I originally approached this subject by asking how organizations could eliminate or prevent resistance to change.
My experience now makes me question whether elimination should even be the objective.
Resistance can delay an implementation. It can be frustrating. It can appear as unanswered emails, missed deadlines, reluctance to provide data, avoidance of training or continued reliance on old processes.
But resistance can also reveal something.
It can tell us that employees don't understand why the change is happening.
It can tell us that our training is inadequate.
It can expose a badly designed process.
It can reveal previous experiences that have damaged employees' confidence in technology.
And sometimes it can tell us that the employee has spotted a problem that the implementation team hasn't.
The challenge, therefore, isn't simply getting resistant people to comply.
It is learning to distinguish between unwillingness, uncertainty, fear, lack of preparation and legitimate criticism.
Across the HR systems I have helped implement, perhaps my biggest lesson has been surprisingly simple.
Before implementing the system, understand the individual.
Before explaining the functionality, understand how they think the process should work.
Before calling someone resistant, understand what they are resisting.
And before overwhelming people with the language of technology, sit with them, show them what will actually change and let them experience it themselves.
Sometimes that requires a sophisticated change-management programme.
And sometimes it starts with a cup of coffee.
