I've spent my career helping organisations adopt new ways of working. And I've watched, project after project, as technology teams build something brilliant and then wonder why nobody uses it. The answer is almost always the same: they treated change management as a phase at the end rather than a discipline from the start. I joined RIVER because they understand this. Most tech companies don't.
What You Need to Know
- Change management bolted onto the end of delivery has a poor track record
- Adoption resistance isn't irrational. It's a predictable response to poorly managed change
- Embedding change thinking from discovery changes the questions you ask and the software you build
- The technology is rarely the problem. Organisational readiness is
The End-of-Project Trap
Here's how change management usually works in enterprise technology projects. The build runs for six months. Two weeks before go-live, someone remembers that users need to actually adopt the thing. A change manager gets pulled in. They write a communication plan. They schedule training sessions. They create a FAQ document. Launch day arrives. Training happens. And then adoption stalls.
70%
of change programmes fail to achieve their goals
Source: McKinsey & Company, 2015
That statistic hasn't improved in decades. And the reason is structural. When change management starts at the end, it can only address the symptoms of resistance, never the causes.
The causes were baked in months earlier. During discovery, when nobody asked how the new system would change people's daily work. During design, when the interface was built for an idealised user rather than the actual people who'd need to transition from the old way. During development, when decisions were made about workflows without considering how those workflows would disrupt established habits.
What Resistance Actually Is
Resistance to change gets treated as a problem to overcome. "The users are resistant." As if they're being unreasonable. As if the correct response to having your entire work process replaced overnight is enthusiasm.
Resistance is information. It tells you something about the gap between what you've built and what people need.
When someone "resists" a new system, they're usually saying one of five things:
"I don't understand why." The purpose of the change was never communicated in terms that made sense to them. They heard "we're implementing a new system" but not "this will eliminate the four-hour manual reconciliation you do every Friday."
"I wasn't involved." The system was designed without their input. They had no voice in shaping the tool they're now expected to use. This feels like something being done to them rather than for them.
"I'm going to lose something." Status, expertise, autonomy, familiar routines. Change always involves loss. Acknowledging that loss is the first step to managing it.
"I don't have the skills." The new system requires competencies they don't yet have. The training session two days before launch didn't build confidence. It built anxiety.
"The timing is wrong." They're already stretched. Year-end reporting. Restructure. Staff shortages. Layering a system change on top of existing stress guarantees a poor reception.
None of these are irrational. They're all predictable. And they're all addressable if you start early enough.
Resistance isn't the enemy of change - indifference is. If people are pushing back, they care enough to engage.
Tim Hatherley-Greene
Chief Operating Officer
Embedding Change From Discovery
At RIVER, change management starts when discovery starts. Not as a separate workstream running alongside the technology. As an integrated part of how we understand the problem.
Discovery Questions That Matter
Standard discovery asks: what are the requirements? What data do you need? What integrations are required?
Change-aware discovery adds: who will be affected by this? How will their day change? What will they stop doing? What new skills will they need? Who are the influencers in each team? What's the change history? Has this organisation been through a failed implementation before?
These questions change the project. They surface risks that pure technology discovery misses. An organisation that's still recovering from a botched ERP rollout two years ago needs a fundamentally different adoption approach than one that's never undergone a major system change.
Design for Transition, Not Just Destination
Most enterprise software is designed for the end state. The fully trained user with complete data and established workflows. Nobody designs for the transition state. The confused user on day one with incomplete data trying to figure out where to start.
When change management is embedded in design, the transition experience gets designed deliberately. Onboarding flows. Guided workflows for the first month. Help content that answers the questions new users actually ask, not the questions the documentation team anticipated.
Build Champions, Not Just Users
Every organisation has informal leaders. The people others watch and follow. If those people adopt the new system, their peers will follow. If they resist, their peers will too.
Identifying these champions early and involving them in the design process does more for adoption than any training programme. They feel ownership. They become advocates. And when their colleagues struggle, they're the first line of support because they understand both the old way and the new way.
The Organisational Readiness Assessment
Before we commit to a delivery timeline, we assess the organisation's readiness for change. Not the technology readiness. The people readiness.
How much change has this organisation absorbed recently? Is there change fatigue? Are sponsors genuinely committed or just funding the project? Is there capacity in the teams to learn new systems while maintaining current operations?
Sometimes the honest answer is "the organisation isn't ready." The technology could be built, but it wouldn't be adopted. In those cases, the right move is to address the readiness gaps first. Rushing to delivery when the organisation can't absorb the change is a guaranteed way to waste the investment.
Why Tech Companies Miss This
Technology companies are built around building technology. That's what they're good at. That's what they hire for. That's what they measure.
Change management is a different discipline with different expertise, different tools, and different success metrics. Most tech teams don't have it, don't understand it, and don't think they need it.
When Isaac brought me into RIVER, he said something that stuck: "We've built great systems that nobody used. That's a failure no matter how good the code is." That admission is rare in the technology world. Most companies blame the client when adoption is poor. The system works. It's not our fault they won't use it.
It's absolutely your fault. Or at least, it's your responsibility. If you're building enterprise software and you're not thinking about adoption from day one, you're building something that might never deliver the value it was designed to create.
The technology is the easy part. Getting two hundred people to change how they work is the hard part. And it deserves at least as much attention, rigour, and investment as the build itself.