A factory in 1890 ran on one enormous steam engine. It turned a shaft that ran the length of the building, and every machine hung off that shaft by a belt. Everything about the building followed from that: where machines stood, how close together, what order the work moved in. The shaft was the plan.
Then electric motors arrived. Factories bought them, and did the sensible thing: they took out the steam engine and put a big electric motor in its place. Same shaft. Same belts. Same building. It worked. It saved a bit of coal. It changed almost nothing.
The gain only turned up when somebody stopped replacing the engine and started replacing the plan— a small motor on each machine, machines arranged in the order the work actually happens, no shaft at all. That took roughly forty years.1 The motors had been fine the entire time.
They did not have a technology problem for forty years. They had a floor plan, and nobody could see it, because a floor plan is just what the building looks like.
The same puzzle came back with computers: enormous spending, visible everywhere, and no matching movement in the output figures.2Robert Solow’s line about seeing the computer age everywhere except in the productivity statistics is the whole thing in a sentence.3 The lag was not capability. It was that nobody had changed the work.
You are standing in the 1890s version of this, right now, with AI.
What actually happens in week three
Pilots rarely die in a meeting. They die quietly, and the shape is almost always the same.
Week one, everyone is interested. The thing works in the demo, because the demo was built on the tidy example. Week two, real work goes through it and some of it comes out wrong, which is normal and expected. Week three, one person is busy, has a customer waiting, and does it the old way instead, because the old way is still there and still works.
Nobody decides anything. There is no meeting. The old route was never switched off, so on any busy day it wins, and every day is a busy day. By week six the new tool is something a couple of people use when they remember, and by week ten it is a login nobody has.
And the story that gets told afterwards is “it wasn’t accurate enough” or “the team needed more training.” Both of those are describing week one. The thing that killed it happened in week three, and it was a floor plan.
Why the owner is the last to know
There is a second thing going on, and it is about who is in the room.
An owner-operator running a pilot usually has nobody to check the diagnosis against. No board, no technical partner, no peer who has done this and will say the unwelcome thing. So when the pilot fails, the available explanations are the ones the vendor and the staff supply. The vendor says the scope was wrong. The staff say the tool was wrong. Neither of them is going to say “the workflow is the problem and changing it is your job,” because that is nobody’s comfortable sentence to say to the person paying.
So the owner buys a different tool. Which is exactly what a factory owner in 1905 did when the new motor did not help: bought a better motor.
What a pilot that survives looks like
Reasoned from the mechanism above rather than counted across a population, but it holds up every time I have watched it:
- The old route is switched off, on a date, in writing. Not discouraged. Off. If it cannot be switched off, the pilot is a demonstration and should be called one.
- One job, end to end, not one step of many. A tool that does the middle of a job hands the work back to the old process at both ends, and the old process reabsorbs it.
- Somebody owns it whose week gets worse if it stops. Not the owner, and not the vendor. The person the job actually belongs to.
- It is measured against the week before, not against perfect. A pilot judged against a demo fails. A pilot judged against last Tuesday usually passes.
The question to ask before you buy anything
Not “is this tool good.” The tool is almost certainly fine, and it will be better again in six months whether you buy it or not.
The question is: what are we switching off?
If the answer is nothing, you are buying a motor and keeping the shaft. It will work. It will save a bit of coal. And in a year somebody will say the technology was overhyped, when what actually happened is that nobody was willing to move the machines.
How this paper was made
The historical account of electrification and the productivity lag is drawn from Paul David’s 1990 paper and the productivity-paradox literature that followed it, cited below. Those are claims about American manufacturing between roughly 1890 and 1930, and about American computing in the 1980s and 1990s. They are not measurements of anything in India in 2026, and this paper does not present them as such — they are here because the SHAPE repeats, not because the numbers transfer.
The argument about why pilots die is reasoning from that shape plus what we see in our own work. It is not a study. Where the outline for this paper originally called for post-mortem data across fifteen to twenty businesses, that data does not exist yet and the pillar says so rather than estimating it.
No client is named, described or implied.
On the date at the top of this page. This paper is dated 20 July 2026 because that is its slot in the series. The writing and the working were done on 26 August 2026, when the series was compiled and released together. We would rather say that here than have you find it in the page history.
References
- David, P. A. (1990). The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox. American Economic Review, 80(2), 355–361. The electrification account this paper leans on. No DOI is registered for it, so no link is given rather than a guessed one.↩
- Brynjolfsson, E. (1993). The productivity paradox of information technology. Communications of the ACM, 36(12), 66–77. The same puzzle one technology later: spending visible everywhere, output nowhere.↩
- Solow, R. (1987). We’d better watch out. The New York Times Book Review, 12 July 1987, p. 36. Where “computers everywhere except in the productivity statistics” comes from.↩