A Quick Recipe for Lasting Change
Why Change Initiatives Fail the People Who Have to Implement Them
Most change initiatives don't fail because the plan was wrong. They fail because the plan was designed by the wrong people. Not wrong in terms of competence. Wrong in terms of position. The planners didn’t include the ‘Right People’…
They forgot and important fact of life: The people who design and approve changes are almost never the people who have to live with it. And that gap — between the people who drew the map and the people walking the terrain — is where most well-intentioned initiatives quietly collapse.
We've watched this happen enough times to recognize the pattern before it becomes a crisis. It usually looks like this: leadership identifies a problem, assembles a team, builds a plan, and rolls it out. The plan is logical. The objectives are clear. The timeline is reasonable. And then something strange happens — the people it was designed for start working around it instead of through it. Workarounds multiply. Momentum stalls. Six months later, everyone agrees the initiative didn't take, and the post-mortem blames culture, or resistance to change, or the wrong hire.
It was none of those things. It was architecture.
The Plan Worked for the People Who Designed It
Here's what actually happened: the plan was optimized for the outcome, not for the humans in the middle.
When you design a change initiative from the top down, you're solving for the end state. You know what success looks like, you build a path to get there, and you hand it to the people responsible for execution. What you don't always account for is what that path actually requires of the people walking it — the cognitive load, the workflow disruption, the moments where the new process conflicts with the old one in ways that weren't visible from the design room.
The people implementing the change aren't obstacles. They're load-bearing parts of the architecture. When the design doesn't account for them, the structure fails — not because they pushed back, but because the weight was distributed wrong from the start.
This is the same principle that breaks technical programs, product launches, and organizational restructures. It's not a change management problem. It's a requirements problem. You built something without fully understanding what it needed to do for the people using it.
What It Looks Like When It's Fixed
The difference between change that sticks and change that doesn't is usually visible before rollout — if you know where to look.
Teams that get this right do one thing differently: they treat the people implementing the change as primary sources of requirements, not secondary stakeholders to communicate with. Before the plan is finalized, they're asking the people closest to the work: where will this break? What are we not seeing? What does this require of you that we haven't accounted for?
Those conversations are uncomfortable. They surface problems before the plan is locked, which means rework before launch rather than failure after it. Most organizations avoid that discomfort and pay for it later — in stalled rollouts, in workarounds that become permanent, in the slow erosion of trust that happens when people feel like change is something that happens to them rather than with them.
The goal isn't a perfect plan. The goal is a plan that works for the people who have to execute it. Those are different things, and confusing them is where most initiatives go wrong.
The Practical Version
Before you finalize any change initiative, run it through three questions with the people who will actually have to implement it (not the people who designed it):
Where does this break for you? Not hypothetically. Specifically. What part of your actual day does this collide with in a way we haven't accounted for?
What does this assume about how you work that isn't true? Every plan has embedded assumptions. Most of them are invisible until someone who lives the work points them out.
What would make this easier to execute without changing the outcome? This is the question that produces the most useful design changes — because the people closest to the work almost always know a better path that the designers missed.
These aren't feel-good questions. They're load-bearing requirements. The answers change the architecture before it fails in the field — which is the only time it's cheap to change it.
Most change initiatives aren't killed by resistance. They're killed by designs that never accounted for the people they depended on. That's not a people problem. It's a process problem. And process problems have solutions — if you're willing to find them before you need them.
At Leitwolf, we help organizations build the right structure before problems compound — or diagnose what went wrong after they already have. If your initiative is stalling or you want to make sure it doesn't, we offer a free 30-minute assessment.