Why Process Change Fails in Small Teams (and How to Make It Stick)

Here's an uncomfortable pattern we've seen enough times to trust it: a process fix is designed well, implemented enthusiastically, and within four to six months the team has quietly drifted back to something close to the old way of doing things. Nobody decided to abandon the fix. It just eroded, one small shortcut at a time, until the "new process" existed mostly in a document nobody opened anymore.

This is the reason the third stage of our own method is called Control rather than treating a fix as finished once it's implemented. After fifteen years watching both successful and failed change efforts, the pattern behind which ones stick has very little to do with how good the original fix was.

Why small teams are more vulnerable to this, not less

It's tempting to assume smaller teams find change easier — fewer people to convince, shorter communication chains. In practice, small teams are often more vulnerable to regression, for a structural reason: there's no dedicated capacity to enforce or check the new way of working. A large organisation might have a process owner, a quality function, an internal audit cycle that catches drift. A five-person team has none of that slack — everyone is already fully occupied delivering the actual work, and the new process survives only as long as someone remembers to care about it under pressure.

The four things that actually predict whether a fix sticks

1. Someone owns it, by name

"The team" does not own a process. A specific person does, even if it's a part-time responsibility layered onto their main role. Without a named owner, responsibility diffuses to nobody, and the first time the old habit is faster under pressure, it quietly wins.

2. The new way is genuinely easier, not just theoretically better

If the improved process requires more steps, more clicks, or more waiting than the shortcut people were using before, it will lose, however much better it is on paper. Sustainable fixes almost always make the correct way the path of least resistance — removing the temptation rather than just documenting the discipline required to resist it.

3. There's a simple way to notice drift early

You don't need sophisticated monitoring — a five-minute check at a regular team meeting, a simple metric glanced at monthly, is usually enough to catch regression while it's still a small correction rather than a full rebuild. The absence of any check-in at all is the single most common thread across the failed fixes we've been brought in to repair.

4. The reason for the change is remembered, not just the mechanics

Teams that understand why a process changed — what it was costing before, in terms they recognise — are far more resistant to drift than teams that were simply handed a new procedure to follow. When people understand the problem a fix solves, they notice for themselves when a shortcut starts reintroducing it.

A fix that isn't sustained isn't really a fix — it's an expensive few weeks of doing things right, followed by a return to exactly where you started.

What this means practically

If you're implementing a process change without external support, build the sustain plan at the same time as the fix, not as an afterthought once things seem to be working. Name an owner before you launch. Test whether the new way is actually faster for the person doing it day to day, not just better for the business overall — if it isn't, redesign it until it is. And schedule the first "is this still working" check before you've even finished the rollout, because the natural drift begins earlier than most teams expect, often within the first month.

This is also why we treat Control as a distinct, ongoing stage in our own method rather than folding it into an Improve engagement and walking away. A roadmap that gets implemented once and never checked again tends to have the shelf life of a New Year's resolution — genuine intent, followed by a slow return to whatever was easiest.