Most AI programs do not fail in the model. They fail in the three feet between the tool and the person who was supposed to use it.
I have watched it happen more than once. The build is clean. The evaluation numbers are good. The demo lands in the steering committee and someone important says the word "transformational." Six weeks after launch, you pull the usage data and the truth is quieter: a small cluster of enthusiasts logged in a lot, everyone else looked once, and the old spreadsheet is still open on most desks. Nothing broke. The thing simply did not take.
We have gotten good at shipping AI. We are still bad at the part that decides whether shipping mattered. That part is not technical. It is human, and it is where the return actually lives.
The pilot that nobody used
The pattern is consistent enough to name. A team identifies a high-value workflow, builds an AI tool that genuinely does it well, runs a pilot with a friendly group, sees strong numbers, and declares victory. Then they roll it out to the wider population and adoption flatlines.
The reason the pilot looked good is the same reason it did not generalise. Pilots self-select for the people who want the tool to work. Early volunteers are curious, tolerant of rough edges, and already bought into the premise. They are not a sample of your organisation. They are the least representative group you could have chosen, and their enthusiasm hid every obstacle the median user was going to hit.
So the dangerous moment is not the pilot that fails. It is the pilot that succeeds for the wrong reason, because it buys confidence you have not earned and sends you into a full rollout with no plan for the people who were never going to volunteer.
Adoption is not a training problem
When adoption stalls, the default reflex is to schedule more training. Another webinar, a better quick-start guide, a lunch-and-learn. This almost never works, because lack of knowledge is rarely the real blocker. People are not failing to use the tool because they cannot find the button. They are choosing not to, and the choice is rational from where they sit.
Treating adoption as a training problem is comfortable because it keeps the fault with the user: they just need to learn. The fact is usually the reverse. If capable people who understand the tool still will not switch, the signal is about the tool and the workflow around it, not about their diligence. More training on a tool people are deliberately avoiding just adds resentment to inertia.
The useful question is not "how do we teach them?" It is "why is the rational choice, for this specific person on a busy Tuesday, to keep doing it the old way?" Answer that and the path forward stops being a curriculum.
The three reasons people don't switch
In practice the resistance almost always reduces to three forces, and they compound.
The first is trust. The old process is a known quantity. The person knows its failure modes, knows when to double-check it, knows how to explain it when it goes wrong. A new AI tool is an unknown quantity that occasionally produces something confidently incorrect. Until the user has calibrated when to rely on it, the safe move is not to, and one bad early experience sets that calibration for months.
The second is effort. If the new tool is even slightly more work than the habit it replaces, in clicks, in context-switching, in the tax of checking its output, people revert. The threshold here is brutally low. A tool that saves ten minutes but adds two minutes of friction at the point of use will lose to the frictionless habit, because the ten minutes is abstract and the two minutes is right now.
The third, and the one leaders underweight most, is identity. For many people, the task you are automating is part of how they understand their own value. The analyst who is proud of their modelling, the writer who is proud of their first draft, the support agent who is proud of knowing the answer. A tool that does that part for them does not feel like a gift. It feels like a question about why they are still here. People do not resist AI because they misunderstand it. Sometimes they resist it because they understand it perfectly.
Redesign the workflow, not just the tool
The mistake underneath most stalled rollouts is dropping an AI capability into an unchanged process and expecting the process to absorb it. It will not. A workflow is a settled arrangement of steps, handoffs, checks, and responsibilities, and it will route around a new tool the way a river routes around a rock unless you actually change the channel.
Adoption succeeds when the new tool becomes the path of least resistance, not an optional detour off the existing one. That means redesigning the surrounding work: removing the manual step the tool replaces rather than leaving it as a fallback, putting the AI where the work already happens instead of in a separate destination people have to remember to visit, and changing what "done" looks like so the old method is no longer the thing being graded.
This is the expensive, unglamorous part, and it is why adoption is an operating discipline rather than a launch event. The model was the easy 20 percent. Rebuilding the workflow so the model is load-bearing is the 80 percent that most programs never budget for, and it is the only part that produces the return.
Incentives and the manager layer
People do what they are measured on. If an organisation says it values the new AI-assisted way of working but still rewards the metrics the old way optimised, everyone correctly ignores the speech and follows the scoreboard. Misaligned incentives will beat any amount of enthusiasm, every time.
The layer that decides this is middle management, and it is the layer most AI rollouts forget. Frontline staff take their real cues from their immediate manager, not from an all-hands. If that manager quietly believes the tool is a threat, a distraction, or a stick to beat their team with on headcount, no top-down mandate survives contact with them. They do not have to resist openly. They just have to not push, and the rollout dies in the gap between the strategy deck and the daily standup.
So the manager layer has to be the first adopter, not an afterthought, and the incentives have to change before the tool arrives, not after adoption disappoints. If using the new way is not visibly the thing that gets someone a good review, it is a hobby, and hobbies lose to deadlines.
How to measure adoption, not activity
Most adoption dashboards measure the wrong thing because the wrong thing is easy to count. Logins, active users, queries run: these are activity metrics, and activity is not adoption. A spike of logins in week one followed by a long decline is the signature of curiosity, not change.
The metric that matters is displacement: is the new way actually replacing the old way, or running alongside it as extra work? The questions to instrument are harder and more revealing. What share of the target task now goes through the tool versus the legacy path? Is usage still climbing in week eight, or did it peak and fade? When people use it once, do they come back, and does the second use look more confident than the first? Are the people using it the median population or still just the original enthusiasts?
Displacement also forces an inconvenient truth: if the old path is still fully available and fully used, you have added a tool, not changed a process, and your adoption number is measuring theatre. Instrument the replacement, not the activity, and the real picture arrives early enough to act on.
The rollout that sticks
None of this is an argument against building. It is an argument for treating the human layer as part of the build rather than as something that happens to the finished product.
In practice that means a few commitments made before launch, not after it disappoints. Choose the first workflow where the pain is real and the user actually wants relief, so the tool is pulling against a felt problem rather than pushing against a comfortable habit. Redesign the process so the new way is the easy way and the old way quietly goes away. Win the manager layer first and change the incentives before the tool lands. Measure displacement, not logins, and expect the real number to be lower than the pilot promised. Then close the loop: watch where people fall back to the old way, and treat each fallback as a defect in the rollout to fix, not a failure of the user to comply.
The organisations pulling real value from AI are not the ones with better models. Models are rented from the same handful of providers by everyone. The difference is that they treated adoption as the actual product and the model as a component of it. Shipping was never the finish line. It was the point where the hard part started, and the hard part is, as it has always been, people.
If your AI program is measured by what was deployed, you are measuring the easy half. The half that pays is what changed in how people actually work, and that half is won or lost in the three feet between the tool and the person. Build for that gap, or keep funding pilots that demo well and die quietly.
I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.
Top comments (0)