Organisations adopt technology by imitation far more often than by need. They copy what is visible in the companies they admire, the tool, the ceremonies, the vocabulary, and they expect the result that followed elsewhere. What produced that result was never visible, and was never copied. The runway gets built. No aircraft lands.
I want to take a story seriously that is usually told as a joke.
After the Second World War, on several islands in Melanesia, people who had watched military aircraft land and unload cargo built runways out of bamboo. Wooden control towers. Headsets carved from coconut shells, with antennae made of branches. Fires lit along the strip at night. Someone standing in the tower, repeating the exact gestures of the man they had observed.
The usual telling makes them ridiculous. That telling is wrong, and it is also the least interesting reading available.
These were people reasoning correctly from the evidence they had. Everything they had observed was true. A strip appears, a tower appears, a man with a headset appears, and the aircraft arrives. The inference is sound. The variables they could not observe, fuel supply, radio frequencies, a wartime economy on the other side of the planet, a logistics chain thousands of kilometres long deciding elsewhere that an aircraft would depart and land here, were not available to them in any form.
The runway was the last hundred metres of a system nobody on the island had access to. Copying the last hundred metres does not reconstitute the system.
Richard Feynman borrowed the image in his 1974 Caltech commencement address and applied it to research. He described work with every outward feature of science, the stated method, the vocabulary, the publications, the apparatus, missing only the thing that makes science work. He called it cargo cult science. The name stuck because the mechanism is general.
It is extremely general. It is the single most reliable pattern I encounter in technology decisions made by people who do not build technology.
Copying what you can see is a rational move, and it fails anyway
Imitation is not stupidity, which is exactly why it is so hard to stop.
When you lack information about a decision, observing what comparable actors do is a legitimate heuristic. They may hold information you do not. Their survival is evidence of something. A manager who follows a widely adopted practice is behaving the way a rational agent under uncertainty is supposed to behave.
The failure mode appears when everyone runs the heuristic at the same time. Each actor treats the neighbour’s adoption as evidence. Nobody has verified anything. The evidence circulates without ever touching the ground.
Sociologists gave this a name in 1983. Paul DiMaggio and Walter Powell described institutional isomorphism: the tendency of organisations in the same field to converge on identical structures, not because those structures are efficient, but because of coercive pressure from regulators and large customers, mimetic pressure under uncertainty, and normative pressure from shared professional training. Their central claim is uncomfortable and well evidenced. Organisations become similar to each other for reasons that have nothing to do with performance.
Mimetic isomorphism is the one that governs technology adoption. Under ambiguity about means and ends, organisations model themselves on organisations they perceive as successful. The model is chosen for its legitimacy, not for its fit.
That is the whole mechanism. An executive adopts because peers adopted. The peers adopted because their peers adopted. Somewhere at the origin there may have been an organisation for which the thing actually solved a problem. By the fourth copy, nobody remembers what the problem was.
The incentives reward adoption, not results
The asymmetry of career risk explains why this is stable rather than self-correcting.
A chief executive who adopts an expensive technology and gets nothing has done what everyone else did. The board understands. The market understands. The failure is collective and therefore survivable.
A chief executive who declines to adopt, and turns out to have been wrong, has personally been behind. That failure is individual, legible, and attributable. It appears in a single name.
These two outcomes do not cost the same, and every executive knows it without having to articulate it. The rational individual choice, given that asymmetry, is to adopt. The rational collective outcome is a field full of bamboo runways.
Add the machinery that exists to amplify the signal. Gartner’s hype cycle, whatever one thinks of it as a predictive instrument, is a reasonably good description of a social phenomenon: a technology trigger, inflated expectations that run far ahead of demonstrated results, disillusionment, and then slow genuine productivity for the subset of use cases where the thing actually fits. Most organisations buy at the peak, because the peak is when everyone is talking about it, and everyone talking about it is the input the mimetic heuristic feeds on.
The vendors are not villains in this. They sell a product that works. It demonstrably works somewhere. The question of whether it works here is not their question to answer, and it would be strange to expect them to answer it against their own interest.
Nobody in the room is paid to ask whether the conditions are present.
A case: eighteen months of visible activity, and nothing underneath
The following is a composite. It is assembled from a pattern I have watched repeat across different sectors and different sizes, deliberately stripped of anything that would identify a specific organisation. The shape is what matters, and the shape is remarkably consistent.
An industrial distributor, several hundred people, a long-standing business with real operational complexity. Decent margins under slow pressure. A chief executive who is not technical and has never pretended otherwise.
The sequence starts the way it almost always starts. Not with a problem. With an observation. A competitor communicates about artificial intelligence in customer service. A board member asks, in session, what the company is doing about it. The question is not hostile. It is a reasonable governance question, and it has no good answer prepared, because nobody had been asked it before.
Within a quarter, there is a programme. Budget allocated. A tool selected, one of the most visible on the market, chosen partly because it is the one everybody has heard of, which is a genuine advantage when you have to present it to a board. An internal lead appointed, taken off their previous work. A steering committee with a fortnightly slot. A dashboard. An integrator on a time-and-materials basis.
The vocabulary changes within six months. People say things in meetings they did not say a year earlier. Slides go to the board. A line goes into the annual report. From the outside, and from the inside, this looks exactly like a company that is doing artificial intelligence.
The intended use case: an assistant that drafts answers to incoming customer requests, pulling from product data, order history and past correspondence.
It is a good use case. It works elsewhere. It did not work here, and the reasons were all present before the first euro was committed.
The product data lived in three systems that had drifted apart over a decade of acquisitions. Same reference, different descriptions, different units in two of them. Nobody considered this a problem, because the humans handling customer requests had learned the discrepancies and corrected for them silently, every day, for years. That correction was undocumented and unpriced. It existed entirely in the heads of eleven people.
The order history was clean, but access to it required a decision nobody wanted to make, because opening it to a third-party tool raised a question about customer data that the legal function had no mandate to settle alone, and the chief executive had not been told the question existed.
The past correspondence, the richest material of the three, had never been retained in a structured form. It sat in individual mailboxes.
None of this is exotic. All of it is normal. It is what an ordinary company that has grown by acquisition looks like underneath, and there is no shame in any of it.
What matters is that none of the three was checked before the budget was approved. The question was never asked, because the project was not launched to solve a problem. It was launched because everyone was doing it, and that reason does not generate the question of conditions. It generates the question of schedule.
The assistant was deployed to a pilot group. It produced drafts that were fluent, confident and wrong often enough that the eleven people checking them found it faster to write the answer themselves. That is the single most common outcome I see. Not catastrophic failure. Quiet non-adoption by the people who were supposed to benefit, who are too polite to say it in the steering committee and too busy to fight about it.
The programme was not killed. It was renewed once, because killing it in month twelve would have required someone to say in front of the board that the thing announced last year had not worked. It was renewed for a second licence year, with a revised scope, which is the organisational equivalent of lighting the fires again.
Now the cost, which is the part that is never on a single line.
Two years of licences at enterprise pricing. The integrator’s invoices. Training delivered twice, once at launch and once after the scope revision. The internal lead, a good one, who spent eighteen months on this instead of the two operational projects on their list, both of which had a clear owner, a clear problem, and a measurable effect on working capital. Those two projects did not get done. They are still not done.
And a cost that nobody enters anywhere. The next time someone in that company asks for a budget for a technical project, the memory in the room will be this one. The internal credit for technology spending was spent on a runway. That cost lands on whoever makes the next proposal, including the proposals that would have worked.
The tool was never the problem. The same product, bought by a company with clean reference data, one defined question, and a named person entitled to override the three services that would object, would have paid for itself. The difference between the two companies is not the software. It is a set of conditions that are invisible from the outside, that do not appear in any case study, and that nobody checked.
The conditions that produce the result are the part nobody photographs
Everything that makes a technology work in a given organisation is structurally harder to see than the technology itself.
You can photograph the tool. You can photograph the ceremonies, the committee, the standing meeting, the board slide. You can transcribe the vocabulary, and people do, which is why entire industries start using the same words within eighteen months of each other.
You cannot photograph the quality of the data going in. You cannot photograph the precision of the question being asked. You cannot photograph the fact that one named person, in the company you are copying, has the standing to overrule three functions when they object, and uses it.
That last one is the most frequently decisive and the least frequently discussed. Most technology programmes that fail inside organisations do not fail technically. They fail at the point where the new way of working contradicts an existing process, and nobody in the room has both the authority and the appetite to break the existing process. The programme then routes around the obstacle, which means it stops touching anything that matters.
The companies that get results from a given technology almost always had those conditions beforehand. The technology revealed the value; it did not create the conditions. Copying the technology without the conditions copies the visible half of a two-part system.
That is the bamboo runway, precisely. Not a failure of effort. A failure of the theory of what was producing the result.
Three questions separate a fit from a copy
Before any budget is committed, three questions do most of the work, and none of them is technical.
The first: what, specifically, would be different in this company if this worked. Not better served customers. Not improved efficiency. A named output, in a named process, that someone can look at in six months and say yes or no. If the answer cannot survive that level of specificity, the project is being launched as a signal, not as a solution, and it should be costed as a signal.
The second: what state is the input in, verified by someone who has opened it. Not described by the vendor, not described by the team that owns it, opened. The gap between what an organisation believes about its own data and what is actually in it is the single largest source of overrun I encounter, and it is almost always discovered in month nine instead of week two.
The third: who, by name, decides when this contradicts an existing process, and will they. This question is uncomfortable because it is a question about power rather than about technology, which is exactly why it gets left out of every specification document I have ever read.
Three questions. A few weeks of work, properly done, by someone who has nothing else to sell. Against a programme that will run eighteen months and consume a year of a good person’s attention.
There is a fourth question, which is really the first one in disguise: if nobody else in our sector were doing this, would we be doing it.
If the honest answer is no, that is not a reason to abandon the project. It is a reason to find out what the conditions are before building anything, because the mechanism that selected this project did not check them, and will not.
Sources
- Richard P. Feynman, Cargo Cult Science, Caltech commencement address, 1974, published in Engineering and Science: https://calteches.library.caltech.edu/51/2/CargoCult.htm
- Cargo cult science, overview and reception: https://en.wikipedia.org/wiki/Cargo_cult_science
- Paul J. DiMaggio and Walter W. Powell, The Iron Cage Revisited: Institutional Isomorphism and Collective Rationality in Organizational Fields, American Sociological Review, 1983: https://www.jstor.org/stable/2095101
- Cargo cult, historical and anthropological overview: https://en.wikipedia.org/wiki/Cargo_cult
- Hype cycle, description and criticism: https://en.wikipedia.org/wiki/Hype_cycle
FAQ
What is institutional isomorphism, and why does it explain so many failed technology adoptions?
Described by Paul DiMaggio and Walter Powell in 1983, it’s the tendency of organisations in the same field to converge on identical structures — not because those structures are efficient, but because of coercive, mimetic, and normative pressure. Mimetic isomorphism governs technology adoption: under ambiguity about means and ends, organisations model themselves on peers they perceive as successful, chosen for legitimacy rather than fit. By the fourth copy, nobody remembers what problem the original adopter was solving.
What three questions separate a genuine technology fit from a copy of what a competitor did?
What specifically would be different in this company if this worked (a named output, in a named process, verifiable in six months); what state is the input data in, verified by someone who has actually opened it rather than described by the vendor or the owning team; and who, by name, decides when this contradicts an existing process, and will they. The third is a question about power, not technology, which is exactly why it gets left out of nearly every specification document — and why it’s most often the decisive factor.
