That is not a small implementation problem. It is usually a sign that the change has not been designed tightly enough for the way work actually moves. People can support the idea and still keep reaching for the old path whenever the new one needs too much explanation, too much judgment, or too much special handling.

The pattern underneath the event

The visible problem is often framed as reluctance, inconsistency, or low discipline. But the deeper pattern is simpler: the new design does not match the work well enough to stand on its own. The organization is trying to run one rule set while the real work keeps producing situations that do not fit neatly inside it.

At first, exceptions look harmless. They sound practical. They keep work moving. Someone says yes to a one-off case, and the immediate blockage clears. But when that becomes the normal way to make the change usable, the exception stops being an exception. It becomes part of the operating model. The change no longer lives in the process. It lives in the discretion of the people who remember how to work around it.

Design creates behavior

The design choice matters here. A change that is meant to spread needs boundaries that are clear enough for people to use without constant interpretation. If the rules are vague, the handoffs ambiguous, or the edge cases left to local judgment, people will not experience the new way as a stable path. They will experience it as something that must be negotiated every time.

That changes behavior quickly. People stop treating the new process as the default and start treating it as a suggestion. They ask more questions before acting. They delay while waiting for clarification. They improvise when the pressure rises. None of that looks dramatic. It looks like ordinary work under strain. But it has a predictable effect: the old route becomes the safe route, because it is already understood and does not require a fresh decision every time.

This is where many change efforts quietly weaken. Leaders assume the issue is adoption and push for more communication. But if people keep needing exceptions to make the new way function, communication is not the missing piece. Design is. The system is asking people to carry too much interpretation for the change to become routine.

Behavior becomes operations

Once exceptions become common, the operational cost shows up everywhere. Someone has to notice the case, ask for the exception, review it, approve it, document it, explain it to the next person, and often revisit it later when the same issue returns under a slightly different name. That is not just one extra step. It is a chain of extra work.

Over time, the change creates a second system beside the official one. The official process is what appears in the policy or workflow. The real process is the one people use to survive the policy or workflow. Meetings start to fill with “just this once” decisions. Managers spend more time interpreting than leading. Frontline teams learn which cases are safe to route through the new system and which ones will come back to them in fragments, requiring follow-up and repair.

That kind of operational drift is hard to spot from the outside because the work still appears to be moving. Forms are submitted. Tickets are updated. Approvals are recorded. But movement is not the same as progress. If each case needs its own manual handling, the organization has not simplified the work. It has redistributed the burden into smaller, less visible pieces.

And once a process depends on that kind of manual effort, it becomes fragile. It works when the right people are available, when the calendar is light, when the issue is familiar, and when everyone involved remembers the workaround. It breaks down under pressure, staff turnover, or volume. The change has not become part of the system. It has become part of the attention load.

Operations become economics

That attention load has a cost. Exception-heavy change consumes time that is never fully counted. It takes time to decide, time to coordinate, time to explain, time to revisit, and time to support the people who are still unsure how to apply the new rule. Each exception may feel small in isolation. Together they create a steady drain on capacity.

The economics are poor because the change is no longer reducing work cleanly. It is adding decision cost. It is adding follow-up. It is adding support overhead for a process that should have been simpler to use in the first place. Teams spend energy keeping the change alive instead of letting it carry its own weight.

There is also a hidden strategic cost. When a new way depends on exceptions to survive, leaders cannot tell whether the underlying design is actually helping. The metrics may show activity, but the organization is paying for that activity with repeated manual intervention. Over time, that erodes trust in the change itself. People begin to assume that every new initiative will arrive with side rules, special cases, and a long list of “yes, but.” They stop expecting clarity and start budgeting for friction.

That is expensive in a quieter way than most leaders notice. It does not appear as one large failure. It appears as slow drag: more meetings, more clarification, more rework, more support, less capacity for the next change. A process that needs constant exceptions may still be technically in place, but financially it behaves like overhead.

What this means for change leaders

This is where the old impulse to push harder usually misfires. If the first version of a change keeps generating exceptions, the useful move is not to ask for more commitment. It is to return to the design and ask what the first adopters are revealing. In Waves of Change terms, this is the point where the group has to come back together, notice where burden shifted, and adjust the change so it can hold without constant manual rescue.

That usually means asking practical questions before you ask for broader adoption: Where does the rule break? Which cases keep needing special handling? What part of the workflow is forcing people to improvise? What would make the new path easier to use than the workaround? Sustainable change does not spread because it was approved. It spreads because it can survive normal work without needing a small rescue operation every time pressure rises.

A practical question to ask

Before you assume the problem is resistance, ask whether the change has been designed to work without permanent exception handling.

What would have to change so the next five cases could follow the new way without a special conversation?

This question helps because it moves attention away from attitude and toward design. It forces the team to look at the actual path the work takes, not the version described in the rollout deck. It also exposes whether the exception is truly rare or whether it is just the first sign of a pattern the system has not yet admitted.

Closing reflection

Most organizations do not suffer because they lack good intentions. They suffer because they keep installing change in ways that require too much improvisation to hold. A change is not durable just because it was launched. It becomes durable when the people who live with it can use it without carrying a new burden every time the work gets complicated.