We all know what it looks like when a software rollout fails. You buy the platform. You configure it. You train the staff. And then the staff — set in their ways, afraid of the new thing, attached to their spreadsheets — quietly refuse to use it. The project stalls. Someone brings in a change-management workstream: a communications plan, a champions program, a few lunch-and-learns, a trainer who says the word “journey” a lot. And when that fails, the blame falls on the staff. They were just too resistant to change. If only people were braver.
I don’t buy it, though. I’ve run software rollouts — ripping out a Frankenstack of legacy tools and moving two decades worth of data onto a single platform — and I reached 100% team adoption in about ten weeks without a single lunch-and-learn. What I learned is that “change management,” as it’s usually practiced, is mostly an alibi. It’s the explanation you reach for when you don’t want to say the real one out loud.
Pay attention to what your team is actually resisting. It’s almost never “change.” It’s friction. It’s a workflow that now takes eleven clicks where it used to take three. It’s a screen that asks for information in a way that has nothing to do with how the conversation with the patient actually goes. Resistance is a signal, and it’s usually an accurate one. The people closest to the work have noticed a gap between the tool and the job, and they’re telling you about it through their resistance.
Resistance is a signal, and it’s usually an accurate one.
When the new platform went live on my last rollout, the new intake workflow drew immediate complaints. It felt long. So long that one caseworker just stopped doing it. She just booked the consults and skipped the parts that annoyed her. A week later, clients were showing up for their appointments with no file prepared.
The change-management playbook would have told me to escalate, loop in her boss, maybe add her to a training cohort. But even if I could compel her to comply that way, all that effort would have been counterproductive — because she wasn’t wrong. The new intake really did feel longer. It asked the same questions as the old paper form, but it made you scroll down a single column on one screen instead of flipping a familiar double-sided sheet. That’s a real ergonomic downgrade in the moment, and no amount of enthusiasm about the “journey” makes scrolling feel like flipping.
So I didn’t follow the playbook. I sat down next to her and walked through the workflow, end to end — including the part she couldn’t see yet, where the answers to questions she was skipping flowed straight into the immigration forms she would later draft. The friction upstream bought something real downstream. Once that was visible, the resistance evaporated. Not because she got braver. Because the tool finally made sense as a fit for her actual job.
Whether an adoption succeeds or fails depends on the product, not the people.
Whether an adoption succeeds or fails depends on the product, not the people. When the software fits the work, adoption is close to automatic and “change management” is a rounding error. When it doesn’t, no amount of training or coaching will make up the difference.
This isn’t a new insight, by the way. When Gallup studied what separates great managers from the rest, one of their blunter conclusions was that people don’t change that much. Rollouts ignore this every time. A change-management program is, at bottom, a bet that you can install new behavior in people who have spent their whole career not changing very much. Fitting the tool to the work takes the other side of that bet — the side Gallup says actually pays.
Change management isn’t worthless. Sometimes the fit is genuinely good and people still cling to an old habit for a while. Sequencing, timing, and a clear why do matter at the margin. But it’s downstream of fit, and it’s a fraction of the size everyone treats it as. Most of what passes for a change problem is actually a design problem, if you look closely enough — and treating it as a hearts-and-minds campaign means you never fix the thing that’s actually broken. You spend your budget convincing people to tolerate friction instead of removing it.
The next time a software rollout stalls and someone proposes a change-management workstream, try asking a different question first: What, specifically, is this team being asked to do that’s worse than what they did before? Then go fix those things. Sit with the caseworker. Watch the eleven clicks. Make the downstream payoff visible. Most of the time you’ll find your “resistance” was a punch list all along.
Nobody resists good software. They resist bad fit. The sooner we stop calling the second thing the first, the sooner we stop blaming users for problems we built.