The Adoption Problem Is People
Two days ago I published our arithmetic — what the tooling we built gave back, caveats and unsolved parts included — and ended on a claim I then refused to develop: the thing worth investing in may not be efficiency at all, but the flexibility to adopt. I said that was the next piece. This is it.
Let me start where everyone else starts, because you have already seen the number.
“95% of enterprise AI pilots fail”
You have read that sentence this year, probably in a board pack. It comes from a July 2025 report, “The GenAI Divide: State of AI in Business 2025”, out of Project NANDA — picked up by Fortune, Forbes and HBR, and it moved markets [1].
Here is what the report’s own data said [1]:
- 60% of organisations investigated custom enterprise AI tools
- 20% actually piloted one
- 5% got one into production
The famous number takes “5% reached production” and calls everything else a failed pilot — so the 80% who never ran a pilot are counted as failed pilots. They did not fail. They never started.
It gets worse the closer you look [1]. It was reported as 150 interviews and 350 employees surveyed; the paper is based on 52 interviews and a paper survey of 153 people — at which sample, as the people who went back and checked put it, the 5% is “probably based on something like two or three actual companies”. It was never peer-reviewed and was never meant to be. Its bar for success was a “marked and sustained” productivity or profit improvement within six months, which most enterprise deployments of any kind would fail. And the four authors named NANDA, the agentic-AI framework they were themselves building, as one of the best paths forward out of the problem they had just described.
So the most-quoted statistic in this debate was manufactured, with a commercial interest attached, and it is still being quoted in rooms where money gets committed. Which matters, because “everyone is failing, hurry up” is exactly the brief that produces the rushed, unowned pilot that later gets counted as a failure.
The pressure is real even though the number is not
Delete the statistic and the problem does not go away, because the real problem was never a success rate. It is speed — not the speed of the technology, which is not the bottleneck, but the speed at which an organisation can change itself.
Think about the sequence. Someone decides who owns AI. Then which committee approves use cases, what the policy says, who writes it, who reviews the draft. Then procurement, legal, the data protection assessment. Every one of those steps is legitimate — I would skip none of them in a regulated engagement, and I sign documents that say so.
And while that is happening, for months, someone smaller who simply started is shipping. Not more cleverly. Just earlier.
Both are true at once, and I have yet to meet anyone who has reconciled them. Most people pretend one half does not exist: the governance camp treats the hurry as hype, the hurry camp treats the governance as bureaucracy.
We have been here before
The best reference point I know is not from software. It is Paul David’s 1990 paper on the dynamo [2].
The dynamo arrived in 1881. Measurable productivity gains from electrification in US manufacturing show up in the 1920s, roughly forty years later — then accelerate sharply, and electrification goes on to account for about half of all productivity growth in US manufacturing in that decade [2].
What took forty years was not the motor. The motor worked. What took forty years was the factory.
Factories were laid out for group drive: one steam engine turning banks of machines through overhead shafts, pulleys and belts, machines positioned by proximity to a shaft because they had to be. When electricity arrived, managers bolted motors onto that layout — David’s phrase is that they “overlaid one technical system upon a preexisting stratum” — and got almost nothing for it. The gains came only once factories were redesigned around what the motor made possible: unit drive, machines placed by workflow rather than geometry, changed work organisation, new skills [2].
The motor was a purchase. The redesign was not.
And we have not been here before
Here I have to stop being confident, because the dynamo cuts both ways.
One reading says the slow part is unavoidable. It was never about equipment; it was about people, process and layout, and those move at the speed people move. If that is the lesson, every organisation compressing the organisational work into two quarters is doing the 1890s thing.
The other says nobody has forty years. Nobody has four. “This historically takes decades” is not advice, it is an excuse.
Both are correct and I cannot collapse them. I do not know how much of that work can be compressed, and I will not put a number on it, because I would be making it up — and this article opened by taking apart a number somebody made up.
What I am confident of is narrower: pretending the work can be skipped is precisely how you produce the pilot that later gets filed as a failure.
What transfers is the capability, not the tool
Back to my own measurement. We got one to two working days a week back, and the hard part was never the code. It was deciding which task was worth automating, getting people to trust the output, changing how a job actually gets done, and knowing when to leave the creative work alone.
The tooling is the least defensible part of it. Tools are purchasable and copyable; in eighteen months most of what we built will be a feature in something you can buy. What is not purchasable is an organisation that can absorb a new one of these every quarter without stopping.
That capability is the asset, and it is made of people.
So the investment is a team, and a specific kind
A small number of people whose only job is to move the organisation forward and bring everyone else with them.
Not a centre of excellence that writes policy. Not a committee that approves things. People who build the first working thing, in production, on real work — and then teach it, patiently, until they are no longer needed for it and can go and do the next one.
Build it, then give it away. Those two halves are the whole job.
Those people are unicorns
This is opinion, from running a software house, and I want it read as opinion — I am not reaching for a talent-shortage statistic in an article that opened by dismantling one.
The combination is genuinely rare. Technical enough to build the thing properly rather than demo it. Patient enough to teach it to people who did not ask for it and are not impressed. Senior enough that when they say “this one is not worth automating”, the decision sticks. And willing to make themselves unnecessary.
That last one is the rarest and the least rewarded. Every incentive pushes the other way: become indispensable, own the thing, be the person who gets called. We ask people to build a capability and hand it over, and we have almost no career ladder that recognises having done it.
And you cannot staff it by promotion or by availability. This is the part I see go wrong most often: the role goes to whoever is loudest about AI in the all-hands, or to whoever happened to have capacity that quarter. Enthusiasm is not the qualification. Being free is not the qualification. It is a specific job with a specific shape, and filling it with the nearest willing volunteer is how you end up with a very energetic person producing things nobody can run.
Even skill on its own is not the qualification, which is the part that surprises people. I have worked with engineers who were technically excellent and still wrong for this, because they used what they knew as a gate: every proposal met a reason it could not be done properly, every shortcut became a standards argument, every request turned into a queue in front of them. That is skill as a blocker. What the job needs is skill as an enabler — the same depth, pointed at making other people able to do the thing, including when their first version is not how you would have done it.
That is a disposition, not a competency. It does not show up on a CV and it does not come out in a technical interview. You find it by watching what someone does when a colleague ships something clumsy that works.
The same rule applies to ownership
Everything above is about the team. It applies at least as hard to whoever owns this, and ownership is where I see the loudest-voice failure most often, because the decision is visible and political.
What the role actually needs is someone who can connect dots quickly and then execute faster than that — see how a capability maps onto a real business problem, and get something real in front of people before the shape of the question changes. Both halves. Connecting dots without execution gives you a strategy deck; execution without the connection gives you a pile of automated things nobody asked for.
That combination is rare, and right now it is extremely hard to recruit for, because everybody has become an expert.
I want to be fair about this, because some of it is legitimate. The field genuinely is new, the demand genuinely is real, and people retraining into it are doing the right thing — I would rather work with someone six months in and curious than someone ten years in and bored.
But somewhere in the excitement we started talking as though this were a new discipline with no ancestors, and it is not. It is still software. It still runs on infrastructure, still has a security boundary, still fails at three in the morning, still has to be maintained by whoever inherits it. None of that was repealed because the code is now written faster.
And that part is not learned from prompting. It is learned from having operated something and watched it break. Without it you get volume — a great deal gets built, and very little of it is secure, scalable or reliable enough for the business to depend on daily.
Which is the whole distinction. There is software a business actually runs on, and there is software that performs beautifully in a Friday demo meeting. The second is much easier to produce, it is what most of this year’s output has been, and you cannot tell the difference from the demo. That is rather the point of a demo.
And it has to be mandated from the top
There is a second way to get ownership wrong, in the opposite direction: name the right person and then leave them to it.
Whoever owns this needs an explicit mandate from the C-level, or the C-level needs to own it outright. Not so that executives make technical decisions — they should not, and the moment a CxO starts choosing models or signing off architectures you have swapped one bottleneck for a slower and more confident one. The mandate exists for something else: clearing obstacles.
Almost nothing that stops an adoption team is technical. It is a budget line waiting on approval. A procurement cycle measured in quarters. A department that will not give up a workflow it owns. A policy written for a different decade. A hiring request that keeps slipping to next quarter. None of that can be cleared by the people doing the work, and all of it can be cleared in an afternoon by someone with the authority to say this is the priority, go.
That is the whole executive job here, and it is not a small one. It is also the one most often substituted with a steering committee.
Underneath it sits an arithmetic nobody enjoys. Succeeding at this now means being fast and reliable at the same time. Fast alone gives you the Friday demo. Reliable alone means you arrive after the window has closed. Both together is expensive — the people are scarce and they are not cheap, and much of the work bills to nobody, because organisational capability has no client to invoice.
So it is a cost decision before it is a technology decision, and it has to be taken by people who can actually commit the cost.
My honest expectation — expectation, not forecast, and I would like to be wrong — is that this is exactly where most companies will pass on their chance. Not by deciding against it. Nobody will hold a meeting and vote no. They will simply never quite fund it, while the pilots keep getting demoed on Fridays and the number at the top of this article gets quoted for another year.
The trust gap is the tell
The evidence that this is a people problem and not a technology problem is in the 2025 DORA report: adoption at 90%, up fourteen points year on year, a median of two hours a day with AI tools, and only 24% reporting substantial trust in it [3].
Adoption already happened — without most of the committees finishing, and whether or not anybody owned it. What did not happen is confidence.
Confidence is not in the licence. It comes from someone demonstrating the thing on real work, failures visible, until the team believes what it sees. That is what the team above produces, and what no procurement process has delivered.
Where is the border?
Two questions I cannot answer. How much governance can you do before you have governed yourself out of the race — and how fast can you move before you are shipping things nobody can honestly stand behind? The second is where the bottleneck in software moved, to review and accountability, and I am not re-arguing it here.
The steep part of the curve
My expectation, not a forecast I can evidence, and I would rather label it than smuggle it in.
I think we are early on a steep curve. If that is right, the distance between organisations that built the capability to adopt and organisations that bought licences does not stay constant — it widens every quarter, because the first group gets faster at it each time and the second starts from zero each time. The window is open now, and I do not expect it to get easier later.
I could be wrong about the steepness. Not about which of the two is harder to buy in a hurry.
The question nobody is asking
Everyone I talk to is asking which tools to buy. Reasonable question, reasonable answers, wrong question.
The question is who — by name — is going to make your organisation able to use them. Not which department, not which vendor. Which person, what they are freed from in order to do it, and how you will know it worked.
And whether that person is already on your payroll.
If you have built this team, or tried and watched it absorbed back into business-as-usual, I would like to hear how it went — including the version where it did not. My day job at WANTED.solutions is where I make this call with money attached, and I am fairly sure I am getting parts of it wrong.
References
- 80,000 Hours podcast — "The story behind the bad AI stat that moved markets and misled millions", on "The GenAI Divide: State of AI in Business 2025", Project NANDA, July 2025
- Paul A. David, "The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox", American Economic Review, Papers and Proceedings, 80(2), 1990
- Google, 2025 — DORA State of AI-assisted Software Development report, and DORA, 2025 — Balancing AI tensions