Resistance is usually rational
When staff avoid new software, the instinct is to talk about change resistance. Almost always they are responding sensibly to their own experience: the new way takes longer, or it removes something they relied on, or nobody explained what it is for.
Treating adoption as an attitude problem guarantees failure. Treating it as feedback about the system usually solves it.
The three real causes
- It is slower for them. A system that saves the business time can cost the individual time. If data entry now takes seven fields instead of three, the person entering it has a worse day, whatever the reporting benefit.
- Nobody explained why. People asked to change a routine without a reason assume the reason is bad.
- The old way still works. If the spreadsheet is still there and nobody insists, the spreadsheet wins. It always wins.
Training that works
- Short and role-specific. Teach the four things this person does, not a tour of the system.
- Close to go-live. Training a month early is forgotten by launch.
- Hands on, with their own data. Watching a demonstration teaches almost nothing.
- A one-page reference for the common tasks, printable, at the desk.
- A named person to ask who is not the supplier — ideally a colleague who learned it first.
The single highest-return investment in adoption is training one enthusiastic person per team properly and letting them help everyone else. Peer support beats formal training and costs less.
Fix the individual cost
If the new system genuinely takes a person longer, that is a design problem worth fixing rather than a training problem. Watch someone do the task and remove the friction: defaults, pre-population, keyboard shortcuts, fewer required fields.
Sometimes the extra effort is genuinely necessary for a business reason. In that case, say so honestly rather than pretending the new way is faster when the person doing it knows it is not.
Retire the old route deliberately
Keeping the old system available indefinitely guarantees partial adoption and inconsistent data. Set a date, communicate it, help the stragglers, and then close it.
Do not close it before the new system is genuinely ready — that produces workarounds you will never discover. But do close it, because an open escape hatch is used.
Three signals of quiet resistance
- Data being entered in batches at the end of the day, which usually means it is still being captured on paper first.
- Shared logins, which means the permission model does not match how people actually work.
- A parallel spreadsheet someone maintains “just for our team” — the clearest signal that the system is missing something they need.
Each of these is information rather than misbehaviour. Ask the person what the spreadsheet does that the system does not, and you usually get a short, fixable list.