Change fails far more often because of how it's introduced than because the idea itself was wrong. Most leaders can point to a new system, process, or tool that made complete sense on paper and still fell apart in practice. The strategy wasn't the problem. The rollout was.
Here's what's actually happening when people resist change: it's rarely stubbornness. It's usually some combination of uncertainty about what's expected of them now, a fear of looking incompetent while they relearn something they used to be good at, and a reasonable suspicion that “change” is something being done to them rather than with them. None of that is irrational. It's how people protect their sense of competence and control, and it shows up in every business, at every level, regardless of how talented the team is.
The fix isn't better messaging about why the change matters, although that helps. The real fix is engagement — bringing in the people who will actually do the work before the decision is finalized, not after.
This matters for a practical reason, not just a morale one: the people closest to the work usually know things leadership doesn't. They know where the current process actually breaks down, which shortcuts exist for good reasons, and what will realistically get in the way of adoption. Involving them early doesn't just build buy-in — it makes the change itself better designed, because it's been stress-tested against reality before it launches instead of after.
In practice, that looks like:
Naming the problem you're solving before you name the solution, so the team understands the “why” and has a chance to weigh in on whether it's the right problem to solve.
Asking the people doing the work how they'd approach it, rather than only asking them to implement someone else's answer.
Piloting with a small group and treating early feedback as real information, not noise to push through.
Being honest about what will be harder in the short term, instead of promising a frictionless transition that no one believes anyway.
The goal of any operational change should be to make the work easier — not just more measurable, more scalable, or more efficient on a spreadsheet. When the people doing the work can see that the change is actually meant to help them, and they've had a hand in shaping how it happens, adoption stops being something you have to enforce. It becomes something the team owns.
At Ops Alchemy, this is how we approach change – from the ground up.
