There's a version of consulting that goes like this. Someone shows up, makes a bunch of recommendations, your team gets excited about the changes, and then the consultant leaves and everything slowly drifts back to how it was before.
I've seen it happen. I've watched it happen to other people's clients, and early in my career, it happened to a few of mine. It's the thing I worry about most.
Because the real test of consulting isn't what happens during the engagement. It's what happens three months after it ends.
Why changes don't stick
Changes revert for a few predictable reasons, and none of them are because people are lazy or resistant to change.
The most common one is that nobody owns the change. A new process gets introduced, everyone nods along, and then nobody is specifically responsible for making sure it keeps happening. Without ownership, things drift. People go back to what's familiar because familiar is easier than new.
Second, the change wasn't built for the people using it. This happens when a consultant designs something that's theoretically optimal but practically annoying. A reporting process that takes 45 minutes every Friday when the team is already scrambling to close out the week. A communication tool that duplicates what they're already doing somewhere else. If the new way is harder than the old way, the old way wins.
Third, the reasoning got lost. People adopted the change because the consultant was there explaining why it mattered. Once that person leaves, the "why" fades, and without the "why," the "what" starts to feel arbitrary. New hires especially have no idea why things are done a certain way, and nobody can explain it because nobody remembers.
What I build in to prevent this
I've thought about this problem a lot. Here's what I do about it.
Clear ownership from day one
Every change we implement has a named owner. Not a department, not "the team," but a specific human being who is responsible for making sure it keeps working. We decide this together during the engagement, and the owner is involved in building the change so they understand it fully.
This isn't about blame. It's about clarity. When something has an owner, it gets maintained. When nobody owns it, it doesn't.
Documentation that people actually read
I have a strong opinion about documentation. Most of it is useless. Not because documentation is a bad idea, but because most documentation is written for the wrong audience, at the wrong length, in the wrong format.
A 40-page operations manual that lives in a Google Drive folder nobody opens is not documentation. It's a filing exercise.
What I create instead is short, specific, and located where people will actually find it. Process steps that live in the tool where the process happens. A one-page reference card for the weekly team meeting format. Decision criteria pinned in the relevant Slack channel. The documentation goes where the work goes.
Training, not just telling
There's a difference between telling someone how a new process works and actually training them on it. Telling is a one-time information transfer. Training is practice, repetition, and feedback until the new way feels natural.
During the implementation phase, I don't just install new processes and explain them. I run through them with the team. We do it together a few times. I watch for confusion and address it. By the time I leave, your team has done the new thing enough times that it's not new anymore.
The 30-day check-in
Every engagement includes a follow-up check-in about a month after I wrap up. This isn't a sales call. It's a genuine "how's it going" conversation.
Are the changes holding? What's working well? What's starting to slip? Is anything not making sense now that you've been living with it for a few weeks?
This check-in has saved a lot of good work from quietly dying. Sometimes there's a small adjustment needed. Sometimes there's a question the team didn't think to ask until they'd been running the new process for a while. That 30-day window is when those things surface, and catching them early makes the difference between changes that last and changes that fade.
Your role in making it stick
I can build in every safeguard I know, but ultimately, whether changes stick depends on you.
You need to actually care about maintaining them. That sounds obvious, but it's worth saying. If a new process gets introduced and you, the owner, start ignoring it or making exceptions, your team will notice. They'll follow your lead, not your instructions.
You also need to hold the line during the uncomfortable period. Every change feels awkward for a few weeks. There's a stretch where the old way would be easier and the new way hasn't become natural yet. If you bail during that stretch, you lose the investment. Push through it. It gets easier.
And when someone new joins the team, take the time to bring them up to speed on why things are done a certain way, not just how. The "why" is what keeps changes alive across team turnover.
A honest caveat
Not every change survives, and that's okay. Businesses evolve. What works today might not fit in a year. The goal isn't to create permanent, unchangeable systems. The goal is to create systems that are intentionally chosen and maintained for as long as they serve you, rather than systems that erode because nobody was paying attention.
If you change something I implemented because your business has grown past it, that's a success. If you change it because it quietly fell apart and nobody noticed until things were messy again, that's the failure I'm trying to prevent.
The difference is intentionality. Keep making conscious choices about how your business runs, and the specific systems matter less than the habit of maintaining them.
If the idea of working with someone who actually sticks around long enough to make sure things work sounds appealing, let's have a conversation about whether it makes sense for your situation.