Managing Resistance to Change in Software Teams

Resistance gets handled as a single phenomenon — something to be overcome, aligned, or managed. It isn't one thing. Four different problems produce it, they need opposite responses, and the shape of the objection tells you which one you're looking at.

Eleven of Aldermoor Health's engineers pushed back on the platform migration. Leadership's response was a single response: more context, more roadshows, more explanation of the why.

Two of the eleven had found a real defect in the plan — the cutover assumed a traffic pattern that didn't hold on Mondays. Six were fine with the destination and objecting to the sequencing. Two had watched the previous migration go badly and didn't believe this one would differ. One was about to lose the thing he was known for.

Every one of them got the same roadshow. The two with the defect stopped raising it after the third session, because raising it clearly wasn't the point. The migration hit the Monday problem eight weeks later, and one of those two had left by then.

The shape of the objection is the diagnostic

You don't need to interrogate motives. The form the objection takes is enough to sort it, and the four forms want genuinely different responses:

The objection looks like	What it usually is	The response
Specific, technical, falsifiable — and the objections differ from each other	The change may be wrong. Independent observation, not coordinated complaint	Evaluate the claim before defending the plan
About how, not whether — they agree with the goal when asked directly	The plan is wrong. Sequencing, scope, timing, owner	Revise openly, and visibly use one of their fixes
Vague, references previous changes, same people every time, absent in new hires	Trust is low. The change is the venue, not the subject	Smaller reversible pieces. Don't argue trust is fine
Disproportionate, and shifts to a new argument whenever one is answered	Identity or power. Their role is what's changing	Name it privately, in a 1:1, not in a meeting

The middle two are where most real resistance lives, and they're the two most often read as the first or the fourth — either "they're being difficult" or "they're just wrong about the technology."

That the objections differ from one another is the strongest single signal in the table. Coordinated complaint converges on one talking point. Independent observation doesn't, because people are looking at different parts of the system.

The test you can run: write down the last five objections you heard about a change and sort them into those four rows. If they don't all land in the same row, a single response was always going to fail some of them.

One question sorts most of them

When the form isn't obvious, one question does most of the work, asked in a 1:1 rather than a room:

"What would have to be true for this to work for you?"

The answers separate cleanly. Someone who says the cutover can't be on a Monday has a plan objection with a fix attached. Someone who says I'd want to see the last migration's problems written down first is telling you it's trust. Someone who can't answer, or whose answer changes each time you meet it, is usually somewhere the technical conversation can't reach.

It also does something the roadshow can't: most people haven't articulated their own conditions, and being asked forces them to. What comes back is frequently smaller than the resistance suggested — a rollback plan they can read, a named decision owner, an acknowledgement that the last one went badly.

The version that fails is asking this and not acting on the answer. Once is a signal that input lands. Twice with nothing changing teaches the opposite lesson permanently.

The test: ask it of your loudest objector. If their condition is something you could grant this week and haven't, the resistance is a plan problem you've been reading as an attitude problem.

Silence is the reading to fear

Active resistance is expensive to hear and cheap to have. It means people still believe the conversation produces something.

The dangerous state is the engineer who used to push back and has stopped. No objections, no comments, does the work as specified. This reads as alignment on every dashboard you have, and it is the opposite: they've concluded that engagement isn't worth the cost. They are job-hunting, or they've decided to be a pair of hands.

Two things follow. Falling objection counts are not progress — they're only progress if you can name what changed to satisfy the objections. And the engineer who raises the uncomfortable thing is doing unpaid work on your behalf; performance-managing them doesn't remove the problem they identified, it removes the reporting of it. Aldermoor lost its Monday-traffic warning that way, and the warning was correct.

The test: list who objected to your last significant change and who objects now. Anyone on the first list and not the second — check whether their concern was resolved or whether they simply stopped.

What doesn't work, reliably

Four patterns that look like change leadership and produce the opposite:

• Compliance theatre. Mandatory training, sign-off sheets, follow-up emails. Produces attendance records and no behaviour change, and it's an adoption problem that no amount of knowledge fixes.

• Villain framing. "A few negative voices we need to bring along." This creates the opposition it describes, and it tells everyone watching that disagreement is disloyalty.

• Asymmetric urgency. "No time to discuss this" paired with "we need everyone bought in." Either there's time for the conversation or there isn't enough certainty to demand alignment. Both can't be true, and the urgency you're invoking is a belief they hold, not a deadline you set.

• Claimed consensus. Announcing agreement that doesn't exist. People will execute a change they dislike; what they won't forgive is being told they endorsed it.

The common thread: each one converts information into silence, which is the only outcome that makes the situation genuinely unrecoverable.

The test: in your last change announcement, find the sentence describing how the team feels about it. If you wrote it rather than heard it, you asserted a consensus.

When you proceed anyway

Some changes aren't optional. A compliance deadline, a decision made above the level where input was sought, a vendor cutover with a date attached. Proceeding over objections is legitimate, and how you do it decides what it costs:

• Say it isn't optional, and say why, without spin.

• Be explicit about what's still open. Usually the sequencing, the timeline, and the support during it are genuinely negotiable even when the destination isn't. Saying so converts objections into useful plan input.

• Don't claim agreement. "I've heard the concerns, I don't have a way to act on them, and we're doing it" survives contact with reality. "Everyone's excited" doesn't.

• Don't punish dissent that respects the decision. Someone who argued and then executed is exactly the person you want raising the next problem.

Most teams will carry a change they don't love. What they won't carry is being told they love it.

The test: for a change you're mandating, name the parts still open to influence. If the honest answer is none, say that plainly — the pretence of consultation costs more than its absence.

What to change this week

Take the last change that met resistance and sort the objections into the four rows.

Expect them not to sort cleanly into one, and expect at least one to be a plan objection with a fix attached that nobody acted on. That one is the cheapest thing on your list, and acting on it visibly is what makes the next round of objections arrive early rather than late.

Then check the silence. Anyone who used to push back and doesn't — that's the conversation to have first, and the map of who is actually affected will tell you who else should have objected and hasn't.

Aldermoor's migration shipped four months late and worked. The Monday-traffic problem was fixed before cutover, by the engineer who'd raised it, after somebody finally asked him what would have to be true.