The AI Adoption Number Is Lying to You
(05)
Overview
The "low adoption" of your AI pilot isn't a change-management problem. It's a rational response from people who can read the business case as well as you can. Here's the operating-model fix.
Year
2026
Industry
Operating Model / GenAI
Challenge
The pattern is familiar. The AI pilot launches with leadership endorsement. The training happens. The communications go out. A few weeks in, you check the dashboard and the team isn't using the tool. They've gone back to the old way of working, with the AI sitting in a tab nobody opens. The usual diagnosis is some combination of three things: change management was insufficient, training wasn't adequate, or the team is resistant to change. Programs are commissioned to address each. A new round of comms goes out. Champions are appointed. Adoption metrics are added to performance reviews. Adoption climbs slightly. Then it drifts back down. I want to suggest a different diagnosis, because the conventional one misses what's actually happening. The team isn't stubborn. They aren't refusing to engage with the future. They are doing something far more rational: they are reading the business case for the pilot, which they can read perfectly well, and behaving accordingly. Look at what most AI-pilot business cases say, in plain language. They project headcount reductions, or "FTE-equivalents freed up," or "redeployment opportunities." The savings number that justifies the investment is, in most cases, some version of we will need fewer people doing this work. That's the math. It's stated in the steering committee deck and, often, in the press release. Now imagine you're on the team being asked to train the tool. You sat in the kickoff. You saw the slide that said the projected ROI assumes a 30-40% productivity gain, which, in your organization's language, means roughly that many fewer FTEs needed once it scales. The leadership team is enthusiastic. They're asking for your help to make it work. The question your team is quietly asking is whether they are training their replacement. This is not paranoia. It is reading the memo. And the rate of adoption you are seeing on the dashboard is not a measure of change-management quality. It is a measure of how the team has read the same document you wrote, and what they have concluded about their place in the new operating model. The deeper question is whether the team owns the outcome they're being asked to build, or just the task. In an AI pilot, that question goes further: does the team own a future in the new operating model at all, or are they being asked to participate in the wind-down of their own work? The behavior you see, the routing around the tool, the polite non-adoption, the quiet protectionism around manual workarounds, is the answer. It's the visible signal of a structural question the pilot didn't bother to address.
Impact
Name the cost, because engagement is not soft. Take a 30-FTE operations team running a pilot intended to deliver a 30% productivity uplift. At a fully-loaded cost of roughly $200,000 per FTE in European banking, the team costs $6M per year. The pilot business case projects something like $1.8M in annual savings if the productivity target lands. Now model what happens when engagement breaks down. Adoption stalls at 20% of expected usage. The productivity gain is therefore not 30% but closer to 6%. The projected $1.8M savings becomes more like $360,000. The pilot has not failed in the sense the dashboard shows, it has technically shipped, but it has missed its case by over $1.4 million in year one alone. That is before you count the things that don't fit neatly in the model. A team that has read the memo behaves differently in ways the spreadsheet doesn't capture. Top performers, who have the most options, tend to leave first; replacing one departure costs somewhere between half and full salary, depending on the role. Process knowledge that lived in the team's heads — including the workaround knowledge that kept the real process running, of the kind I wrote about a few weeks ago — walks out the door with them. The remaining team handles their own work plus the work of the departed colleague, plus the pilot, while waiting for clarity. Productivity falls before it rises. Engagement survey scores drop. The next pilot in the same function gets greeted with even more skepticism, because the team has now seen how the last one played out. This is what makes the engagement aspiration sit underneath the productivity aspiration, not next to it. Pilots that fail on engagement also fail on productivity, and they tend to fail on cost-and-risk too, because rushed re-implementations after a stalled rollout introduce control gaps. Engagement is not the soft sibling of the harder business outcomes. It is upstream of them. So what's the fix? It is not better comms, more training, or louder cheerleading. Those address the symptom, not the cause. The fix is structural, and it lives in the design of the pilot itself. Three things change when you take engagement seriously as an operating-model problem rather than a change-management one. First, the team is in the room when the business case is built, not when it's communicated. The savings number that justifies the pilot is not handed down. It is co-designed with the people whose work it touches, and the assumptions are visible. The conversation about what happens to the time the AI frees up is held before the pilot ships, not after, and the answer is something more concrete than "redeployment opportunities." Second, the operating-model future state names roles, not just headcount math. What does this team do six months after the AI scales? What is the higher-value work the freed capacity moves into? Who decides? If the answer is some version of "we'll figure it out," the team has heard that one before and knows what it usually means. A real operating-model design names the destination — the team's destination — with the same specificity as the projected savings. Third, the design owns the truth where it has to. Sometimes the honest answer is that the team gets smaller. Pretending otherwise is worse than naming it; the team can read the memo either way. Naming it lets you talk about timing, redeployment paths, and selection criteria that are fair. That conversation, held early and held honestly, gets more cooperation than the polite fiction does. None of this is new. It is the same operating-model design discipline that defines who the customer is, what the work is for, and what value looks like, applied to the people doing the work, not just the work itself. AI raises the stakes of the question because the outcome the team is being asked to own includes, in many cases, the redefinition of their own role. The dashboard adoption number is a symptom. The real number is whether you've given the team a future in the new operating model worth engaging with. If you have, the pilot moves. If you haven't, no amount of comms will move it, and you'll spend more on the failed pilot, in retention and rework and slipped productivity, than you would have spent on the operating-model work upfront. That's the engagement aspiration named honestly. Cost-without-risk and productivity follow it, not the other way around.