Your team is resisting change. What are they protecting?

Leadership announces a new system. The slides look clean. The implementation date is ambitious. Someone in operations asks what happens to the exceptions, and the room decides they have a resistance-to-change problem. An inconvenient question has just been promoted to a personality trait.

Employee resistance to change can reflect a real design problem, a reasonable fear, limited capacity or disagreement about the direction. It can also include persistent obstruction. A manager needs to distinguish these possibilities before choosing a response. Enthusiasm is pleasant, but it is a poor substitute for understanding the work.

First ask what the change is for

Describe the problem in language the affected team can recognise. “We need a more modern platform” tells them about a purchase. “We need to stop customer requests getting lost between two teams” explains a working problem. Make the proposed benefit specific enough that people can examine it.

The CIPD change management factsheet highlights the importance of managing organisational change and the contribution of people professionals. My practical approach begins by connecting the proposed change to the actual work and people it affects. A general framework does not resolve your particular team's concerns automatically.

State what has been decided and what is still open. Asking for consultation after every meaningful choice is closed creates the experience of being invited to admire a decision. If the direction is fixed, people can still influence the implementation, risks and support, provided you honestly explain those boundaries.

Look for the thing someone expects to lose

A change can affect competence, time, autonomy, relationships, status or confidence about employment. These possibilities are prompts for conversation, not psychological diagnoses. Ask: “Which part of this proposal would make your job harder?” Then invite a concrete example rather than debating whether their attitude is modern enough.

Someone who knows the old process may worry that valuable experience will be ignored. Someone with a crowded workload may see training as another responsibility without relief. Someone who experienced a failed rollout may question whether support will survive launch week. Different concerns need different answers.

Do not pretend every loss is imaginary. Automation or restructuring can genuinely change roles. Share what you know, what you do not know and how decisions will be made. Do not promise job security you cannot guarantee or ask employees to accept personal uncertainty as proof of company loyalty.

The sceptic may be carrying your missing requirements

People closest to the work often know where the standard process fails. They may have built informal workarounds that keep customers served. Those workarounds can be inefficient, risky or necessary. You need to inspect them rather than assume every unofficial method is either brilliant or unacceptable.

The CIPD report Landing transformational change discusses reframing concerns about change as legitimate employee voice. It draws on organisational cases, rather than proving every objection is correct. The useful question is what an objection reveals that your plan has not considered.

Ask the sceptical colleague to walk through one recent case. Where would the new process help? Where would it fail? What information or decision would be missing? A worked example can transform a vague argument into a requirement, a test or a tradeoff that leadership must own.

Separate the concern from the behaviour

Someone can raise a valid issue in an unhelpful way. Someone can speak politely while undermining agreed work. Discuss both fairly. “Your concern about exception handling is useful. Publicly insulting the implementation team is not acceptable” preserves the information without excusing the conduct.

Likewise, a quiet employee should not be presumed resistant because they do not perform enthusiasm. Check whether they understand the change, can carry out the relevant work and have a route to raise difficulties. The project needs reliable participation, not a compulsory audition for the launch video.

When repeated obstruction is established, clarify the agreed responsibility, available support and expected behaviour. Use the appropriate management process if it continues. Listening does not mean removing all accountability. It means the decision can be made with a clearer understanding of facts and constraints.

Make a pilot that tests the disputed part

Choose a bounded workflow, a representative group and a comparison with the existing approach. Define what would make the change useful and what would require revision or stopping. The trial should answer the actual concern, not simply create another successful demo under unusually friendly conditions.

For an AI-assisted workflow, compare the full task, including checking and repairing outputs. A faster draft may be helpful, but the reviewing work still counts. Use approved information, establish human responsibility and include awkward cases. A pilot that excludes every difficulty mainly demonstrates how well the exclusions work.

Ask the team to help define the evaluation. Leadership may still own the final decision, especially where tradeoffs cross departments. Sharing the evidence and explaining the decision makes the process more credible. Universal agreement is not always possible, and presenting it as the goal can delay necessary action indefinitely.

A hypothetical example: the CRM nobody wants

Imagine a service company replacing a familiar customer system. In this hypothetical example, staff object because the new workflow requires the same details in two places during a transition period. Management initially interprets reluctance as attachment to old software. A walkthrough reveals duplicated work and unclear ownership.

The company removes one unnecessary entry step, names the source of truth and schedules supported practice using realistic cases. It also explains why some temporary duplication is unavoidable and when it will end. That response addresses the work problem without pretending the transition will be effortless.

If employees still disagree, managers can ask which remaining concern needs evidence and which reflects a preference they cannot accommodate. Some choices genuinely favour one team over another. Name that tradeoff and its owner. Calling everything a win-win does not make the extra work disappear.

Provide capacity, not just encouragement

Learning takes time. Allocate space for practice and decide what existing work will reduce during the transition. If normal targets stay untouched, employees may be expected to learn, migrate and deliver simultaneously. Their hesitation could be an accurate assessment of available hours rather than a lack of ambition.

Teach the tasks people actually need to perform. A general overview is useful context; it does not replace practice on the relevant workflow. Make help discoverable and choose someone responsible for keeping instructions current. Otherwise the first workaround becomes the unofficial training manual.

Plan what happens after launch. Who monitors problems? Who can adjust the process? Where do unresolved cases go? People will have more reason to try a new method if they can see a credible support route beyond the celebratory announcement.

Look for usable adoption

Logins and training attendance describe activity. They do not establish that the work improved. Review completion quality, exceptions, avoidable rework and whether people can explain the new responsibility. Interpret these measures alongside direct conversations. Avoid tracking private employee behaviour beyond a legitimate, proportionate operational need.

My AI adoption guide goes deeper into choosing and evaluating a workflow. The essay on AI as a human amplifier explains why human judgment remains central when tasks move to new tools.

If your change programme is stuck between ambitious leadership plans and a team with practical concerns, I can help connect the two. Product discovery, workflow design and corporate training are part of my experience. Tell me what you are trying to change, and we can identify a useful conversation and a bounded test.

Questions people ask

Why do employees resist organisational change?

Possible reasons include unclear benefits, realistic concerns about workload, loss of control, missing training or uncertainty about responsibilities and employment. Previous failed changes can also affect trust. Ask for concrete examples and avoid assuming a psychological motive. Some objections reveal requirements your plan missed, while persistent obstruction still needs clear expectations and an appropriate management response.

How can managers reduce resistance to an AI rollout?

Explain the business problem and what decisions remain open. Invite employees to show real cases, including exceptions. Test a bounded workflow with approved information and human review, then compare the full task rather than draft speed alone. Allocate time for training and practice. Share evidence, explain tradeoffs and provide a support route after launch so participation is workable.

Does listening to employee concerns mean everyone must agree?

No. Listening provides information and gives people a fair opportunity to influence relevant decisions. Leadership may still need to choose between competing priorities. Explain what is fixed, what can change and who owns the final decision. Address valid concerns without excusing harmful conduct. A transparent decision and clear responsibilities can be more useful than indefinitely pursuing unanimous enthusiasm.