The month after the go-live high
Why isn't the new system just working?!
There’s a moment in almost every transformation project I’ve worked on where everyone breathes a collective sigh of relief and starts talking about what’s next.
The new system is live. The new process has been communicated. The deck has been shared. Someone has made a Loom video. There’s a Confluence page now (or a Notion doc, or a section of Monday.com, or a folder in Google Drive that everyone bookmarks and nobody opens again).
And then, quietly, the thing starts dying.
Not dramatically. Not all at once. People don’t reject it outright. They just... revert. Not out of malice, and not because they’re resistant to change in some deep-seated psychological way. Because the old way still works for now, the new way requires effort, and nobody’s watching anymore.
I’ve watched this happen enough times to know it’s not a people problem. It’s a design problem. Most organisations are reasonably good at building things. They are consistently, reliably, almost impressively bad at the six weeks after.
A few years ago I was brought into a company to redesign how they managed work across a distributed international team. We built something quite good, actually: a system that pulled everything into one place, gave finance and the board real-time visibility, and cut process duplication significantly. The go-live felt great. Training sessions happened. Slack announcements were made. The CEO sent a message saying this was a big deal.
Six weeks later I came back in for a check-in and found that roughly a third of the team had stopped using it. Not because it didn’t work. Because the person who’d championed it had moved on to the next priority, nobody had followed up on the people who’d drifted, and the path of least resistance was whatever they’d been doing before. Not realising how much more work they are creating for their future selves (the reason the system was built in the first place!)
We fixed it. But we shouldn’t have needed to, and the fix wasn’t technical. It was relational. Someone had to go and actually sit with the people who’d quietly checked out, understand what wasn’t working for them specifically, and close the gap. That took longer than building the system in the first place.
What I’ve taken from this, and from variations of it across more businesses than I’d like to admit, is that adoption is a completely different job from implementation. Building something requires a certain kind of brain: systematic, logical, good at seeing how parts connect. Embedding it requires something else entirely. Patience. Repetition. The ability to genuinely care about why someone in accounts finds the new workflow annoying (rather than concluding they’re just difficult), and the willingness to fix that rather than dismiss it.
The organisations that get this right treat go-live as the beginning of the work, not the end of it. They build the follow-through into the plan from the start: who’s checking in with who, when, and what the feedback loop actually looks like. They don’t celebrate the launch until it’s working, which almost always takes longer than the project plan assumed (and there’s no shame in that, if you’ve planned for it).
The ones that struggle treat launch as the finish line. And then they wonder, six months later, why the new thing isn’t quite delivering what they’d hoped and everyone seems to be doing it slightly differently.
There's an added layer to this that's becoming harder to ignore. With AI tools and automation moving at the pace they currently are - both as standalone platforms and baked quietly into tools teams are already using - the old sequential approach to change is starting to break down. You can't spend three months properly embedding something that's already been updated twice, or that half your team has started using a different version of without telling anyone. The window between "we've just got this working" and "there's already a better version" is shrinking. Which means the follow-through can't be an afterthought built onto the end of a project plan. It has to be iterative, faster, and designed in from day one, or you'll spend the next few years launching things that never quite land and the whole business (bottom line AND people) will feel the impacts.