You purchased licenses for the new AMS or CRM platform.

You ran the training.

You sent the go-live email with a subject line like “Exciting News!”

Leadership showed up to celebrate. The vendor called it a success.

Three months later, your team is back in spreadsheets. Or Lists.

I’ve seen this play out dozens of times across industries: nonprofits, professional services, healthcare, growing mid-markets. And every time, the diagnosis is the same. It gets framed as a people problem. Not enough buy-in. Resistance to change. Need for better communication.

That’s almost never the whole story.

Strategy lives in committees. Work lives in Tuesdays.

Technology strategy gets built at the leadership level. In Steering committees. Business cases. Feature comparisons and integration maps. It gets evaluated on capability, scalability, reporting, and ROI.

On paper, the logic holds up perfectly.

But strategy doesn’t live on paper. It lives in how your program manager spends her Tuesday morning.

She’s not thinking about digital transformation. She’s thinking about an approval that’s stuck, a deadline that’s slipping, and three competing requests that hit her inbox before 9am. The new system either fits that reality or it doesn’t.

There’s no middle ground.

Here’s the question I ask in almost every consulting engagement: if you showed me what a typical Tuesday looked like before go-live and after, how different would it actually look?

For most organizations, the honest answer is: not very.

The system got layered on top of the existing work. It didn’t change the work. That’s the root cause of adoption failure.

Shadow systems are not rebellion. They’re signal.

Pay attention to the spreadsheets people build outside the official system. The side Slack threads that replace formal updates. The workarounds teams quietly develop just to keep momentum going.

Organizations treat these as symptoms of resistance. I read them differently.

Here’s an example I’ve seen firsthand. An organization goes live on a new ERP platform on a Monday. By Wednesday, a finance analyst on the team has quietly kept the old Excel tracker running on the side, “just until things settle down.” She wasn’t trying to sabotage anything. She was trying to make sure the month-end close didn’t fall apart while everyone figured out the new system.

Nobody noticed. Leadership assumed the transition was happening. It wasn’t.

Six weeks later, the team was maintaining financials in two places: the new ERP and the original spreadsheet. Nobody could tell you which one was the source of truth. Reconciling them became its own job.

The team wasn’t resistant to the new system. They were drowning in it. The implementation didn’t reduce their workload. It doubled it.

And here’s the part that’s easy to miss: she wasn’t wrong to do it. The new system hadn’t been configured to handle the edge cases her team dealt with daily. Nobody had told her what to do when it didn’t work. So she did what capable people do. She solved the problem in front of her.

That’s not resistance. That’s a system design failure showing up at the frontline.

Shadow systems are feedback. They tell you the official workflow doesn’t fully support the lived reality of the work. And when the old way still functions, even imperfectly, people will default to it. Not because they oppose change. Because they’re trying to get their work done.

The organizations that get this right don’t just launch a new system. They retire the old one. Formally. Completely.

They close the escape hatch. And they make sure the new system is actually ready to hold the weight before they do.

Adoption is a design problem, not a communication problem.

Most organizations treat adoption as a change management issue to be solved after deployment. More emails. Refresher training. A leadership town hall.

These things have their place. But they’re addressing the symptom, not the cause.

The work that actually drives adoption happens before go-live. It’s operational redesign: deciding which processes change, which manual steps disappear, which decisions now live inside the system, and which legacy trackers get formally shut down.

I push clients to answer four questions before they flip the switch on anything:

1. How does this change a program manager’s Tuesday? Be specific.

2. What task disappears entirely? Not moves. Disappears.

3. Which spreadsheet is being formally retired on Day 1?

4. What makes it harder to revert than to use the new system?

If a leadership team can’t answer those questions clearly, they don’t have an adoption strategy. They have a deployment plan.

Those are not the same thing.

Technology enables. Work design sustains.

Here’s the part that takes time to sink in, especially for leaders who’ve invested real money and energy in a platform: the tool isn’t the transformation. It’s the vehicle.

The transformation happens when the organization actually redesigns how work gets done. Role by role. Workflow by workflow. Decision by decision.

When strategy, process, and role expectations are genuinely aligned, behavior follows. And when behavior changes, adoption isn’t something you’re chasing anymore.

It’s just what happens.

So before you pull the next usage report, ask a different question: did we actually redesign the work? Or did we add a new system on top of the old one, leave the old one running, and wonder why nothing changed?

Adoption doesn’t fail because of poor communication. It fails because the work never actually changed. And when capable people build workarounds, that’s not a people problem. It’s a signal that the system wasn’t ready to replace the work it was supposed to. Redesign the workflow before launch. Retire the old system only when the new one can hold the weight.