You put in the work. You documented how something should go, or held the meeting where everyone aligned, or built the template and explained the new way.
For about a week, it worked.
Then, quietly, things drifted back. The template got skipped. People defaulted to asking instead of checking the document. The new handoff step disappeared into a busy Thursday.
It's easy to read that as the team not following through. Not taking it seriously. Resistant to change.
Sometimes that's true.
But more often, the process failed — not the people.
Why things drift back
When a new process goes in, it's competing with something that already exists: the way things have always been done. The old way is familiar. It's automatic. It doesn't require anyone to remember anything new in the middle of work that's already moving.
For a new process to hold, it has to become the path of least resistance — or at least close to it. That rarely happens on its own.
The change asked too much of memory
A process that requires someone to remember a new step — without a prompt, a visible place to check, or something built into the existing flow — is always fragile. Memory has limits, especially during busy stretches when people are already making dozens of small decisions a day.
Nobody owned the transition
Implementing a change and stewarding it are two different things. If no one is specifically noticing when the new process gets skipped and naming it, drift becomes normal fast — quietly, without anyone deciding to abandon it.
The process didn't fit how the work moves
A lot of operational improvements make sense on paper but don't fit how a team's day flows. When a new process creates friction instead of reducing it, people find workarounds quickly — and without thinking of it as a workaround.
Too much changed at once
When a team is absorbing multiple new processes at the same time, the attention required to make any one of them hold gets spread thin. Everything stays partial. Nothing becomes normal.
What makes changes hold
The operational changes that stick tend to have a few things in common.
They're smaller than they look. A change that touches one specific part of the work — one handoff, one recurring task, one decision point — is far easier to make real than a change that touches everything at once.
They fit inside the existing flow. The best process improvements don't ask people to change how they work. They make the right move the obvious move within the workflow that already exists.
They have a clear owner during the transition. Not forever — just long enough for the new way to become the expected way. Someone who notices the drift and names it, without drama.
They're built from what's happening. Processes designed around how a team ideally works tend to fail as soon as the day gets complicated. Processes built around how the team works — including the messy parts — tend to hold.
The question worth asking
If a process you put in place has drifted back, the most useful question usually isn't "why won't my team follow this?" It's closer to: "What made the old way easier than the new one?"
That's almost always where the friction lives.
It might be that the new step adds time nobody has. It might be that the document is hard to find when someone needs it. It might be that the handoff point was never fully clear to both sides. It might be that two people involved still disagree on who owns the step — without having said so out loud.
Finding that one thing — the specific friction, not the general feeling — is usually what makes the fix hold this time.
Where to start
If your team has been through a few rounds of "we're going to change how this works" without much lasting relief, the answer probably isn't a more comprehensive overhaul.
It's more likely that the specific friction causing the drift hasn't been fully named yet. Or the change that was put in place wasn't small enough to be absorbed without losing momentum.