‍The problem isn’t willingness

Employees aren’t opposed to change. Seventy-four percent of employers and employees agree it’s extremely valuable to help people learn, grow, and experiment with new ways of working. People want to adapt. What they want is a stake in how it happens.

AI makes the gap unmistakable. Forty-one percent of US workers already use generative AI for work, while only 18% of firms have formally adopted it. Employees aren’t behind the transformation‚ they’re ahead of it, often hiding it. One localization worker mentioned they’re obsessed with finding better ways to work, but no one at the company can help them institutionalize what they’ve figured out. Ninety-three percent of employees say they’re dissatisfied with how their company is bringing AI into the workplace. When the technology is already in people’s hands and satisfaction is that low, you can be sure the failure is the rollout.

Traditional organizational change management frameworks like ADKAR, Kübler-Ross, or McKinsey 7-S were designed for a slower era. They treat change as something to be managed, and employees as subjects to be moved through stages of acceptance. The consultative rigor is real. What’s missing is the creative spark that makes anyone actually want to move.

The result is forced compliance instead of genuine adoption: rejected initiatives, underperforming technology investments, burned-out teams.

Borrow from the discipline that has always had to earn attention

In persuasive advertising, no one gets to mandate. You cannot compel a person to download an app, switch brands, or change a decade-old habit. You have to understand their motivations, frustrations, daily workflows, and aspirations.

That’s the transferable skill. When you understand employees the way a great brand understands its audience, you can build communications and experiences that drive voluntary action rather than mandated compliance. Every person instinctively asks the same question when change arrives: What’s in it for me? Most change programs never answer it. A campaign has to answer it in the first four words or it dies.

Example - Hatch: stop sending messages, build a coach‍

Hatch had mandated a new set of digital project delivery tools. Adoption didn't move.

The research surfaced why they were stuck. Employees were fluent in their old tools, their
old workflows, and the workarounds they’d built around both. They couldn't see how the
new tools fit or what value they created for one person on one project. The benefits were
real, but when leadership delivered that message, it fell flat. Leadership was the wrong
voice.

What employees needed was a coach. Someone who inspires the team to work together,
teaches new skills, and shows people how specific changes help them get where they
already wanted to go. Not an announcement; a voice with a stake in their success.

We built a coach inside Microsoft Teams where employees already were, rather than on a
microsite they’d barely visit. The personalized invitation named the employee in the first
four words. Teaching and testing happened seconds apart, with wrong answers written as
jokes so the quiz could never punish anyone for not knowing yet. And the reward was
deliberately cosmetic and collective: a new kit for the whole team, never just one person.
The tool’s value came from everyone using it together, so the incentive had to work the
same way.

We also built an AI layer into the tool, using it for intake rather than a feature. One
question, with the system telling you upfront what it would do with your answer. The
output was a reconfigured dashboard, not a chat transcript.

The result was personalized, engaging, and rewarding. This approach was built to pull
employees into new ways of working instead of pushing them away from what was
familiar.

Change enablement is a design decision, not a comms deliverable.

The pattern in both cases is the same. Enablement didn’t get bolted on after launch. It
was built into the experience, because the interface is where trust is earned or lost.

That means the highest-leverage decisions in a change program are often not engineering
decisions at all. Where the checkpoint sits and how many there are. How a person's
authorship stays visible. What the system may never do. What gets logged, and who can
read it. The microcopy at the moment of consequence.

That last one sounds trivial. On a Hatch task card, we could have written "Action required."
Or "3 overdue." We wrote "so that." Same information, same pixel count‚ but "action
required" tells you there’s a rule, and "so that" tells you there’s a person on the other end
of your delay. Two entirely different products.

That decision took about four minutes. That decision is the job.