The Adoption Paradox: Why Employees Adopt Tools They Help Shape

A logistics company we worked with once, spent nine months building an internal tool meant to help dispatchers route shipments faster. It launched with a polished demo and a training rollout. Within a month, most dispatchers were back to their old spreadsheets, using the new tool only when someone was checking.

That kind of quiet abandonment is not what most people mean by resistance to change. Prosci’s research shows that change initiatives with strong change management practices are seven times more likely to meet their objectives than those without it. The dispatch tool had a launch plan and a training deck. What it never had was the dispatchers themselves in the room while it was being built.

People Don’t Resist Tools, They Resist Not Being Asked

The dispatchers on that team had years of judgment the tool never captured. Which routes looked fine on paper but caused delays every winter? Which customers needed a phone call before a shipment, not just a notification? None of that had been asked of them before the tool went live, so it routed around exactly the problems they already knew how to avoid, and they stopped trusting its suggestions within weeks.

Oak Engage’s 2024 research on this is specific: 23% of employees say being excluded from change-related decisions makes them more likely to resist the change itself. That number reframes what looks like stubbornness as something closer to a rational response. The dispatchers were not rejecting new technology. They were rejecting having no part in shaping something that now told them how to do their job.

What Shaping a Tool Actually Looks Like

The company redid the rollout. Instead of a finished product, they gave five senior dispatchers the roughest working version and two weeks to break it. The dispatchers fed it every seasonal pattern, every customer exception, every route that looked efficient on a map but never worked in practice. Each one became a rule the tool had never had before.

Prosci’s research names employee engagement as one of the top three contributors to whether a change effort succeeds at all. That is not a soft metric tracked for its own sake. It is a leading indicator of whether people actually use what gets built once it is theirs to use.

Ownership Changes the Psychology, Not Just the Workflow

When the rebuilt tool relaunched, the same dispatchers who had quietly ignored the first version started doing something nobody asked them to do. They flagged new exceptions as they found them. They walked newer colleagues through the tool instead of around it. Nobody had to request that behavior. Ownership produces it on its own.

Gallup’s research on engagement backs up why this matters beyond one team. Organizations in the top quartile of employee engagement see 10% higher customer loyalty, 23% higher profitability, and 18% lower turnover than those in the bottom quartile. The dispatch team’s second rollout was not a bigger technical achievement than the first. It succeeded because the rules inside it belonged to the people using them.

Where This Breaks Down

Not every attempt at involving employees produces this result, and the failure mode is worth naming plainly. A single survey sent before launch, a feedback session that never changes a single design decision, a rollout email thanking people for input nobody acted on: this does more damage than skipping consultation altogether. It teaches people that being asked and being heard are not the same thing, and once they learn that lesson once, they stop believing it the next time either.

The dispatch team’s first rollout had technically included a stakeholder review. Nothing the dispatchers flagged in that review changed the tool before launch. That is why it failed exactly like a rollout with no consultation would have. Token participation reads as exclusion to the people on the receiving end of it, because functionally, that is what it is.

What Good Looks Like

What made the second rollout stick was not a longer survey. It was a visible loop: a dispatcher flagged an exception, the exception became a rule, and the next version of the tool showed that rule working. People do not need to be told their input mattered. They need to see it did.

Conclusion

The dispatch team’s second tool did not succeed because it was smarter than the first. It succeeded because the five people who rebuilt it had a real stake in whether it worked. Tools survive daily use when the people relying on them helped build the version they are now expected to trust. Every leader wants adoption without a fight. The only reliable path there runs through the room where the tool gets built, not the memo that follows once it ships.