The Adoption Paradox

The engineer who automated herself out of the room, and the compact that would have kept her building

I want to tell you about a pattern, through a person. She is a composite of several people I have worked alongside over the years, because the story is too common to belong to just one of them.

She was the best engineer on the team. Not the flashiest, the most useful. When the organisation announced its AI transformation, she did what she always did. She took it seriously. While others attended the workshops and quietly went back to working the old way, she rebuilt her team’s entire deployment pipeline around the new tools. Work that took the team a week began taking a day.

Leadership noticed. Her work went into the town hall deck. The transformation office used her pipeline as the case study that proved the programme was working.

Six months later, her team of eight became a team of four. The logic was impeccable. The pipeline she built meant the same output needed half the people. She survived the cut. Her four closest colleagues did not.

Then something interesting happened, and it is the part most leaders never see.

She stopped. Not visibly. She still used the tools, still attended the sessions, still said the right things. But the next three automation opportunities she spotted, she kept to herself. The clever fix for the testing bottleneck stayed in her head. When asked in a retro whether anything else could be streamlined, she said she would think about it.

She was not bitter. She was rational. The organisation had taught her, precisely and unforgettably, what happens to the surplus her ingenuity creates. It does not flow to her. It flows out the door wearing her colleagues’ badges.

Multiply her by every engineer, analyst, project manager, and finance professional who has watched this sequence play out, and you understand why AI transformations stall in ways no dashboard can explain. The tools are deployed. The training is complete. The adoption metrics look fine. And the compounding gains that the business case promised simply never arrive, because the people who could deliver them have quietly withdrawn from the bargain.

Leaders often describe this as resistance to change. It is the opposite. It is a workforce that understood the change perfectly.

The uncomfortable truth is that she would have kept building if the deal had been different. And the deal is the part leadership actually controls.

So let me talk about the deal.

The Adoption Compact

After watching this pattern repeat across enterprise clients in media, technology, and the public sector, I stopped treating it as a change management problem and started treating it as a design problem. What follows is the framework I now use when advising leadership teams. I call it the Adoption Compact, and it has four parts. Each one exists because its absence is precisely what taught our engineer to stop.

Part one: Name the destination before asking for the journey.

Most organisations ask people to adopt AI without ever saying what happens on the other side. The silence is not neutral. In the absence of an answer, people assume the worst, and they are often right to. The compact starts with leadership stating clearly what the efficiency gains will fund. Growth into new markets. New products. Redeployment into work that was never resourced. Or yes, in some cases, a smaller organisation. Any of these answers is workable. No answer is not. Our engineer never heard one. She filled the silence with the evidence in front of her.

Part two: Separate the efficiency decision from the headcount decision, visibly.

These are two different decisions made by two different logics, and when they collapse into one, trust collapses with them. In her story, the pipeline win and the team cut arrived in the same quarter, from the same logic, signed by the same hand. That proximity was the lesson. The organisations that navigate this well create explicit distance between the two. Efficiency gains are measured and celebrated in one forum. Workforce planning happens in another, on its own timeline, with its own rationale. When people can see that automating their work does not directly trigger a review of their role, they stop hiding their best ideas.

Part three: Make redeployment real, not rhetorical.

Every leadership deck says people will be freed up for higher value work. Almost none of them can name what that work is, who will manage it, or what budget it sits under. If the higher value work does not have a name, a leader, and a line in the plan, it does not exist, and your people know it before you do. The test I give leadership teams is simple. Show me the job that the freed up capacity flows into. If you cannot, you are not redeploying. You are queuing people for exit. Her four colleagues were never queued for anything else. Everyone on the team understood that, even before the announcement.

Part four: Let the people closest to the work own the automation agenda.

The deepest version of the paradox is that the people best placed to find automation opportunities are the ones with the most to lose from finding them. You cannot fix that with reassurance. You fix it with ownership. When the team that automates a workflow keeps a stake in the gains, whether through scope, advancement, or genuine input into what happens next, the incentive flips. The threat becomes an asset they control. The three opportunities our engineer kept in her head were worth more than the entire pipeline she built. Under a different compact, she would have brought them forward within the month.

The part leaders control

None of this is soft. It is the hard mechanics of keeping a workforce willing to build the thing that changes their own jobs. The organisations that get this right will compound. Their people will surface automation opportunities faster than any consultant could find them. The organisations that get it wrong will get one round of easy gains, and then silence.

The next time an AI transformation stalls somewhere in your organisation, resist the urge to ask what is wrong with the adoption metrics. Ask instead what your best people learned the last time they automated something. Their answer is running your programme now, whether you can see it or not.

The technology was never the problem. The compact is.