Back to Insights

The People Side of Change: Why Transformations Fail and How to Lead Them

June 16, 2026 Ali Hayder
The People Side of Change: Why Transformations Fail and How to Lead Them

I’ve led technology rollouts in companies across three countries — ERP implementations, new systems, process overhauls — and the pattern is always the same. The projects that fail don’t fail because the technology didn’t work. They fail because the people weren’t brought along.

The system goes live, everyone goes back to their desk, and within a month the old spreadsheet is back — quietly, unofficially, and universally. The expensive new tool sits unused while the work happens the way it always did.

Here’s how to lead change that sticks, based on what actually works.

Explain the why before the what

People don’t resist change because they’re stubborn. They resist because nobody explained why the change matters — to them, not just to the company.

“We’re implementing a new ERP” is a fact. “The current process means our warehouse team re-enters data three times and our invoices go out a week late — this system eliminates both” is a reason. The second version gives people something to connect to. It acknowledges the pain they’ve been living with and offers a real fix.

If you can’t articulate the why in terms that matter to the people doing the work, the change hasn’t been thought through well enough — or the work isn’t understood well enough.

Involve the users early, not at training

The worst time to ask users for input is after the decision is made and the system is configured. By then, their feedback is a problem, not a contribution — because changing things now costs time and money.

Bring the people who’ll use the system into the conversation early:

  • Have them map the current process — they’ll tell you things no flowchart captures.
  • Let them test prototypes or configurations — their reactions tell you where the design breaks reality.
  • Ask what will make their work harder — then fix it or explain why the trade-off is worth it.

People support what they help build. They tolerate what gets imposed on them. The difference is the distance between success and expensive shelfware.

Find your champions and use them

Every team has two or three people others listen to — not because of title, but because of credibility. Find them early, involve them in the design, and let them become the advocates.

A respected colleague who says “I helped test this and it actually makes my job easier” does more for adoption than any memo from management. Champions don’t just promote the change — they catch problems early and bring them to you before they become reasons to abandon the whole thing.

Train on the process, then support through the pain

Training isn’t the day before go-live — it’s an ongoing process:

  • Train on the workflow, not just the screens. People who understand why the process works this way adapt faster than people who memorized click sequences.
  • Have support available after launch — real people who can answer questions, not a FAQ document nobody reads.
  • Expect the first weeks to be slower and rougher. That’s normal. Plan capacity for it instead of pretending the transition is instant.

Quick wins matter more than grand visions

A transformation that promises everything in eighteen months asks people to sustain faith through a long period of disruption with no visible payoff. Most can’t. Energy fades, skepticism grows, and the old ways creep back.

Design the rollout in phases where each phase delivers a visible improvement:

  • Automate the most painful manual process first.
  • Fix the report everyone complained about.
  • Solve the bottleneck that frustrated people daily.

Quick wins don’t just show progress — they build the credibility that lets you ask for patience on the harder changes.

Resistance is information, not insubordination

When people push back, the instinct is to label it resistance and apply pressure. Better: treat pushback as diagnostic data. If people are avoiding the new process, find out what about it isn’t working for them. If they built a parallel spreadsheet, that spreadsheet is probably doing something the system doesn’t.

Listen, fix what’s fixable, explain what isn’t, and give people a timeline for the rest. Handled this way, resistance makes the change better instead of killing it.

Leaders have to go first

Nothing kills a change faster than a leadership team that announces a new process and keeps using the old one. If the system requires approvals through a new workflow but the owner approves by WhatsApp message, the workflow is dead on arrival.

Model the change visibly. Use the new tools yourself. Follow the new process publicly. When people see the boss working the new way, the new way becomes real.

Change is hard enough without making it about blame. Make it about the work getting better — and prove it, one visible improvement at a time.