Change fatigue is a technology problem

In a recent engagement, an operations team was described to us as change-resistant. We asked them to walk through a single customer request end to end. It touched six systems, required the same reference number typed four times, and included one step whose only purpose was to satisfy a report that had been discontinued.

Their resistance to a seventh system was not cultural. It was an accurate assessment of what the last six had done to their working day. Every rollout had been individually justified and collectively corrosive.

Organisations plan technology roadmaps against engineering capacity and budget. Almost nobody plans against adoption capacity - how much process change a given team can absorb in a year while still hitting their targets. It is finite, it varies by team, and exceeding it produces the exact symptoms usually labelled as resistance.

Making it explicit changes the conversation. When a portfolio board can see that the customer service team is absorbing three major changes this quarter, sequencing decisions improve immediately - not because anyone became more empathetic, but because the constraint became visible alongside the others.

The single most effective practice we have adopted: every rollout must name what it removes. A system, a manual step, a duplicate entry, a report nobody reads. Not eventually - in the same release.

This is unpopular with programme managers because decommissioning is unglamorous work with no launch event, and it is the reason estates accumulate. It also transforms how a change lands. A rollout that removes three steps while adding two is experienced as relief rather than as imposition, and the adoption curve reflects that.