Four Kinds of Resistance ... And The One Leaders Keep Excusing

The last three issues were about decisions made at the top of a project: what to descope when the legacy still earns, which five questions to ask before signing the SOW, and which of the three buckets the next AI dollar belongs in. All of it was decided in rooms with steering committees in them.

This issue is about what happens after those rooms empty out — when the decisions reach the people who have to run the work on Monday.

And those people, more often than not, push back.

Most IT leaders file that pushback under "change management" and treat it as the soft part of the project: training, a roadshow, a few lunch-and-learns, a champions program. The framing is that the system is right and the users need to be brought along. That framing quietly costs you the best diagnostic data the project will ever produce.

Here's the reframe:

The people resisting the move off the legacy system are running a requirements review you didn't commission and aren't paying for.

The catch: "resistance" is one word for four very different things, and it almost always shows up wearing the same costume — attitude. That costume cuts both ways. Sometimes it hides a real signal you should act on. Sometimes "attitude" is the label a leader reaches for to avoid acting at all. Reading the resistance means telling the four apart.

Treat all resistance as one problem — inertia to be overcome — and you'll mishandle three of the four. Here's what you're actually looking at.

Signal. The resister knows something the project plan missed. A customer-specific override that three accounts depend on. A month-end step that only works because of a field nobody documented. A report that looks redundant until you learn the controller builds the audit package from it. This person isn't afraid of change — they're telling you the new system will break something real, and they're usually right. It's the most valuable resistance you'll get, and the easiest to wave off as negativity.

Friction. The new system genuinely makes part of their job worse — more clicks, a slower path, a step that took five seconds and now takes thirty. The loss is real, even when the overall trade is positive. These users aren't wrong about the loss; they're just weighing their slice, not the whole. Acknowledged honestly, friction is manageable. Denied — "the new way is better, you'll adjust" — it curdles.

Habit. Genuine inertia. The workflow changed, nothing of value was lost, and the discomfort is just the discomfort of new muscle memory. Training and time reliably solve it. This is the one — and the only one — the change-management playbook was actually built for.

Stake. The resistor doesn't want the change because it costs them. The new system is faster for the company and worse for their standing. It automates the task that made them the person everyone had to go through. Sometimes it retires the system they built and defended for a decade, and watching it get switched off feels like being told their best work no longer counts. This isn't a missing requirement, a fixable loss, or simple inertia. It's self-interest — and it's the most uncomfortable of the four to say out loud, which is exactly why leaders don't. They relabel it: " … that's just how they are." or " … they're set in their ways." That relabel is an off-ramp to doing nothing, and stake is the one flavor that does not resolve on its own. It needs a leadership decision and a named expectation—not a training deck or endless accommodation.

So there are two ways to get this wrong, in opposite directions. Treat everything as habit and you train the signal away — you lose a requirement and find out at quarter-end. Treat stake as personality, and you excuse it — you let one person's comfort set the speed limit for the whole migration. Both failures come from the same root: refusing to do the sort.

The read costs an afternoon. Find the loudest resistor — every implementation has one — and ask them one question: "What breaks on Monday?"

Not "what do you think of the new system?" That invites opinion. "What breaks on Monday?" invites specifics, and specifics are what you can triage. Write down every item, then sort each into the four flavors:

A real thing the system won't do — signal. It goes back to scope, with a named owner, before go-live.

A real loss the system imposes — friction. Name it out loud, decide whether to mitigate or accept it, and tell the user which you chose and why. The acknowledgment does most of the work.

Discomfort with no underlying loss — habit. Now your training program is aimed at the thing training actually fixes.

Won't pin to any of those — stake. The tell: stake rarely answers "what breaks on Monday" honestly, because the honest answer is "my standing." It shows up instead as goalposts that move every time you satisfy them, and objections that change shape but never resolve. When an objection can't be tied to a signal, a loss, or a habit, you're looking at stake — and the response isn't another demo. It's a direct conversation about expectations, held by someone with the authority to set them. That's the sponsor's job, not the project team's.

The sort is the whole discipline. It turns a wall of "the users hate it" into a list you can act on — and it tells you which items need a fix, which need a conversation, and which need a decision.

Skip the read, and the resistance doesn't disappear. It goes underground, and it takes the work with it.

Unaddressed signal becomes a shadow system. The override the new platform couldn't handle moves to a spreadsheet on someone's desktop, and now your system of record has a hole in it nobody admits to. Unaddressed friction becomes workarounds — the team keeps the old process alive in parallel "just until the new one settles down," and it never settles down. Unaddressed stake becomes the quiet veto: the senior voice who never says no in the room and never adopts outside it, whose team takes the cue. And the legacy system you spent months replacing doesn't get decommissioned because half the org is still quietly using it.

The metrics look fine the whole time. Logins are up, the dashboard is green, and adoption hit the target. Meanwhile, the real work has relocated to spreadsheets and inboxes, and you won't find out until a quarter-end when a number doesn't tie. The resistance you didn't read didn't stop the project. It just moved the truth somewhere you can't see it — and if you excused the stake, it told everyone watching that the migration was optional.

One page, built during the resistance read, maintained through go-live: the resistance log.

One line per concern raised, reviewed weekly through cutover:

It looks like a complaint list. It functions as a risk register, a test plan, an adoption tracker, and a decommissioning checklist at the same time. The shops that keep one retire the legacy on schedule. The shops that don't are still paying the old maintenance contract two years later and can't quite explain why.

—

Plant Floor to Cloud goes out every Tuesday.

Your loudest resister right now — signal, friction, habit, or stake? Reply with one word. I read every one.

—

Views are my own and do not represent any employer. Nothing in this newsletter is attributable to or sourced from any specific company. All case content is generalized to protect employer and client confidentiality.