Insights / Perspective / Change management and implementation training
PerspectiveResistance to change is information
Resistance can feel obstructive, but it often points to a real concern about the design or the plan. Treat it as data before you treat it as a problem.
In most change programmes there comes a moment when a project team starts talking about resistance. A department is dragging its feet. A group of experienced staff keeps raising objections. Training attendance is poor. The language shifts from colleagues to blockers, and the conversation turns to how to overcome them.
We think that framing is usually a mistake. Resistance can feel obstructive, but it often points to a real concern about the design or the plan. The people pushing back are frequently the ones who know the work best. Treating their objections as information rather than as an obstacle tends to produce a better change, and a faster one.
Why people resist, and why it is often rational
People rarely resist change for no reason. When you look closely, objections tend to fall into a handful of categories, and most of them are reasonable from where the person stands.
- The new process will not work in situations the designers did not see, and the person knows it.
- The change makes their job harder, at least for a while, and nobody has acknowledged that.
- They have seen previous changes fail and expect this one to go the same way.
- They do not understand why the change is needed, so it looks arbitrary.
- They are worried about their job, status or skills, and nobody has addressed it.
Only the last of these is mainly emotional, and even that is a perfectly rational concern. The first is a design problem. The second and third are credibility problems. The fourth is a communication problem. Each has a different remedy, and none of them is solved by pushing harder.
Listen first
The most useful response to resistance is to ask what worries people and what they would change. Do it in small groups or one to one, where people can speak plainly. Ask open questions and resist the urge to defend the design while you listen.
Good questions are simple. What concerns you most about this? Where do you think it will go wrong? What would you do differently? What would make this easier for your team? The answers are often specific and practical, and they frequently reveal things the project team genuinely did not know.
Separate fear from fact
Once you have heard the concerns, sort them. Some concerns are about real process flaws. Fix those. A typical example is a new approval workflow that looks sensible on paper but would leave urgent orders waiting overnight because the approver works a different shift. The warehouse team that raises it is not resisting; they are doing quality assurance for free.
Other concerns are fears that need a clear answer rather than a design change. Will I lose my job? Will I be able to learn the new system? Will my targets be adjusted while I get used to it? These deserve honest, specific responses. If the answer is not yet known, say when it will be.
Close the loop visibly
When a concern leads to a change, tell the people who raised it, and tell everyone else too. Visible evidence that feedback changed the plan does more for adoption than any amount of persuasion.
A small number of objections will be neither design flaws nor answerable fears. Some people simply prefer the old way and will take time to adjust. That is normal. Give them support, set clear expectations and let the experience of colleagues who have adapted do some of the persuading.
Show what is in it for them
Programmes are usually justified in organisational terms: lower cost, better control, faster reporting. Those benefits are real, but they rarely motivate the person entering orders or receiving goods. Explain concrete benefits for their daily work.
That means being specific. No more re-keying orders from email. Stock levels you can trust, so fewer awkward calls to customers. A screen that shows the full history of an account, so you are not chasing three colleagues for an answer. Where the benefits to a particular role are genuinely thin, say so honestly and explain why the change is still worth it for the organisation. People respect candour more than a forced sales pitch.
What leaders should do differently
For sponsors and senior leaders, the practical shift is to treat reports of resistance as a prompt to ask questions rather than to apply pressure. When a team is pushing back, ask the project team what the concerns are, which have been tested and which have led to changes. If nobody can answer, the listening has not happened yet.
- Spend time with the groups that are most sceptical, and listen more than you talk.
- Make it safe to raise concerns early, before positions harden.
- Ask for a short log of concerns raised and actions taken, reviewed at steering meetings.
- Recognise people who raise problems constructively, especially when their input improves the design.
None of this means abandoning the change at the first objection. A programme still needs direction and deadlines. But direction is easier to hold when the people affected can see that their knowledge has been used.
A practical starting point
The next time someone in your programme is labelled resistant, arrange a forty-five-minute conversation with them and two or three colleagues. Ask what worries them and what they would change. Sort what you hear into flaws to fix and fears to answer, act on both within a fortnight and tell them what you did. More often than not, the resistance changes shape.
Source: Intelliversal analysis.
