Friday Fun: The Great Corporate Cargo Cult

When the aeroplanes stopped coming

The expression cargo cult entered Western vocabulary through observations of religious and social movements in Melanesia, particularly around and after the Second World War. The real history is considerably more complicated than the caricature subsequently adopted by business literature, and the movements themselves cannot honestly be reduced to people naïvely building wooden aeroplanes in the hope that cargo would fall from the sky. They emerged from colonial disruption, enormous asymmetries of wealth and power, encounters with industrial logistics on an almost incomprehensible scale, and existing cultural and religious traditions. The simplified metaphor nevertheless survived because it describes a genuinely seductive error in human reasoning: observing the visible characteristics of a successful system, reproducing them, and assuming that the mechanism responsible for success has therefore also been reproduced.

The Pacific theatre provided an extraordinary demonstration of how misleading visible causality can become. Airfields appeared. Runways were cleared. Towers, warehouses and communications equipment surrounded them. Uniformed people performed highly specific activities. Signals were exchanged. Aeroplanes arrived carrying quantities of food, machinery, clothing and equipment that seemed almost miraculous compared with local productive capacity. From outside the industrial system that connected American factories, mines, oilfields, ports, railways, military procurement, shipping, meteorology, radio communications and aviation, the observable sequence looked deceptively simple. People performed rituals around a runway; enormous machines appeared carrying wealth.

The runway certainly mattered. The control tower mattered. The radio mattered. The procedures mattered. None of them, however, caused the cargo to exist.

Somewhere thousands of kilometres away, somebody had mined the aluminium, refined the fuel, manufactured the engines, trained the pilots, scheduled the flights, maintained the aircraft, forecast the weather, loaded the cargo and financed an industrial economy capable of doing all of this simultaneously. The airfield represented the final visible interface to an immense productive system whose causal machinery remained mostly invisible from the runway.

Corporate management has spent several decades perfecting exactly this epistemological achievement, although we have improved the terminology considerably.

We have observed Google

Successful companies provide irresistible objects of study. Google used OKRs. Amazon organised teams around particular ownership principles and famously discussed the number of pizzas required to feed them. Toyota developed an extraordinarily sophisticated production system. Spotify published material describing squads, tribes, chapters and guilds. Netflix became associated with freedom and responsibility. High-performing technology organisations practised continuous delivery. Others invested heavily in internal platforms. More recently, successful technology companies started using generative AI extensively.

Naturally, we studied them.

Unfortunately, studying complicated systems requires patience, whereas copying nouns requires approximately one quarterly planning cycle.

Soon organisations had OKRs, squads, tribes, chapters, guilds, two-pizza teams, DevOps teams, Platform Engineering teams, Communities of Practice, paved roads, product operating models and enough transformation terminology to make a medium-sized airport jealous. The arrival of AI has accelerated the process magnificently because we can now imitate successful companies before anybody has had sufficient time to determine why they are successful.

The reasoning rarely sounds ridiculous when expressed individually. This matters. Most organisational absurdity emerges from locally reasonable decisions rather than collective stupidity. If successful engineering organisations invest in developer platforms, investigating platform engineering makes sense. If another company dramatically improves alignment using OKRs, learning from its experience seems rational. Engineers themselves constantly reuse patterns because rediscovering every solution from first principles would make civilisation unnecessarily exhausting.

The problem begins one layer deeper, where observation quietly mutates into causality. Google has OKRs and performs well, therefore OKRs contribute to high performance. Spotify has autonomous squads and innovates quickly, therefore autonomous squads create innovation. Elite engineering organisations deploy frequently, therefore increasing deployment frequency will make our engineering organisation elite. AI-native companies use large quantities of AI, therefore counting tokens consumed by engineers gives us an AI transformation metric.

At this point the wooden control tower has already been erected. Nobody has yet noticed because it has excellent branding and appears prominently on the transformation roadmap.

The Corporate Runway Programme

Imagine a company called CargoCorp. CargoCorp has noticed that its software delivery performance remains disappointing despite employing intelligent people, modern technology and approximately seventeen dashboards explaining why everything should theoretically work.

Management commissions a benchmarking exercise. The results prove encouraging. Every high-performing organisation studied possesses autonomous teams, OKRs, a developer platform, DevOps practices and an AI strategy. CargoCorp possesses some of these things, but not consistently, which immediately provides a plausible explanation for the performance gap.

A transformation programme begins.

Teams receive autonomy. This initially creates confusion because most important decisions still require approval from functions outside the teams, but an updated organisational chart resolves the discrepancy by placing the word autonomous underneath each team name. OKRs arrive next. Because objectives need measurable key results, every department develops measurable indicators for activities previously performed without measurable indicators. The number of measurable indicators increases substantially, providing the first measurable evidence that the transformation is succeeding.

Platform Engineering follows. A central team builds a platform intended to eliminate friction for developers. Unfortunately, developers continue using their existing tools because those solve their immediate problems, so adoption becomes the platform team's principal challenge. A Platform Adoption Initiative therefore begins to encourage teams to use the capability created to make their lives easier. When encouragement produces insufficient adoption, standards appear. The paved road gradually acquires barriers preventing anybody from leaving it.

None of this necessarily fails. That would actually make the problem easier.

Some of it works.

Delivery improves in several teams. Dependencies fall. A few sensible platform capabilities remove genuine toil. Better objectives expose previously invisible priorities. Teams make decisions locally that once travelled through four management layers. The organisation records the improvement, quite reasonably concludes that the transformation contributed to it, and institutionalises the practices responsible.

The crucial question receives considerably less attention: which mechanism actually produced the improvement? Perhaps autonomy worked because teams finally owned coherent domains. Perhaps OKRs worked because executives had previously communicated priorities poorly. Perhaps Platform Engineering worked because infrastructure provisioning had required six tickets and three weeks. Perhaps deployment frequency improved because somebody finally removed an unreliable integration test suite that had terrorised engineers since 2019.

CargoCorp does not urgently need to know. The aeroplane arrived, the quarterly review contains several encouraging arrows pointing upwards, and causality can therefore wait until the next transformation.

The Coffee Excellence Programme

Success creates a new problem: successful practices need protecting.

CargoCorp's coffee provides an excellent opportunity. Employee feedback suggests considerable variation in coffee quality between offices. Some machines produce acceptable espresso. Others produce something whose relationship with coffee remains principally contractual. Management correctly identifies inconsistency and establishes the Coffee Excellence Programme.

The programme begins sensibly. Good beans, maintained equipment, clean machines and somebody occasionally tasting the result would probably solve most of the problem, but CargoCorp has matured considerably since those primitive days.

A Coffee Process Owner documents the brewing lifecycle. Procurement establishes an Approved Bean Supplier List. Facilities defines machine availability SLOs. Finance requests cost-per-cup metrics. Sustainability adds water-consumption objectives. Security becomes involved after discovering that several connected coffee machines run unsupported firmware. Enterprise Architecture reasonably asks whether offices should continue operating independent coffee solutions when the organisation has committed strategically to shared capabilities.

The Coffee Platform team appears shortly afterwards.

Its mission centres on enabling autonomous beverage consumption through standardised, self-service coffee capabilities at scale. Rather than every office solving coffee independently, the platform provides a paved road from bean procurement through grinding, extraction, cup provisioning and telemetry. Early documentation describes Coffee-as-a-Service, although Legal asks that the term remain internal until trademark implications have been investigated.

The platform works surprisingly well, except that several offices continue using local machines.

This threatens standardisation.

A Coffee Architecture Review Board establishes approved brewing patterns. Exceptions remain possible through a lightweight governance mechanism involving a four-page Coffee Deviation Record reviewed every second Thursday. Nobody intends to create bureaucracy. The process exists specifically to preserve autonomy while maintaining alignment.

Coffee quality continues declining.

Fortunately, the dashboards look excellent.

Machine availability reaches 99.97%. Approved-bean adoption exceeds 91%. Mean Time to Espresso falls by 14%. Coffee Platform adoption becomes a company-level key result. Ninety-eight per cent of employees complete mandatory Beverage Security Awareness training. An internal survey records a 12% improvement in awareness of the Coffee Strategy.

Someone eventually asks whether anybody likes the coffee.

The question creates considerable methodological difficulties because taste is subjective and therefore difficult to incorporate into the existing measurement framework.

When the ritual becomes the result

This is where cargo cults become dangerous rather than merely funny. The first mistake consists of assuming that because successful organisations perform an activity, reproducing that activity will reproduce their success. The second mistake proves subtler: once we have reproduced the activity, its existence itself becomes evidence that success should eventually follow.

CargoCorp now has autonomous teams. Therefore autonomy cannot explain poor delivery. It has OKRs. Therefore strategic alignment has received appropriate treatment. It has Platform Engineering. Therefore developer experience has an owner. It has adopted AI. Therefore productivity improvement should emerge as adoption increases. Each installed practice progressively removes a question from legitimate investigation.

The organisation has not merely copied answers. It has reduced its capacity to ask questions, while simultaneously increasing the number of people professionally responsible for defending the answers already selected.

This produces a peculiar inversion. Practices originally created to solve problems become things that problems must conform to. Instead of asking which constraints prevent teams from delivering, we ask how teams can improve compliance with the operating model. Instead of asking why developers avoid the platform, we ask how to increase platform adoption. Instead of asking whether AI improves economically meaningful output, we ask how to increase AI usage. Instead of tasting the coffee, we investigate why employees have not embraced the strategic beverage capability.

The representation gradually replaces the system it supposedly represents.

This replacement carries an economic consequence that organisations rarely place on transformation dashboards. Every representation needs maintaining. Processes acquire owners. Platforms acquire teams. Standards acquire governance. Governance acquires reporting. Reporting acquires tooling. Tooling acquires licences. Metrics acquire analysts. Exceptions acquire review boards. Eventually the organisation spends a meaningful proportion of its productive capacity maintaining the machinery intended to increase productive capacity.

At that point removing an ineffective practice becomes considerably harder than introducing it. The practice now has a budget, a roadmap, employees, executive sponsorship and perhaps a conference presentation describing its success. Evidence that contradicts the practice threatens more than an idea. It threatens an organisational investment.

If twelve people now operate the Coffee Platform, discovering that employees prefer a kettle and a cafetière no longer constitutes an interesting empirical observation. It constitutes a stakeholder-management problem, followed shortly afterwards by an adoption problem and, with sufficient executive attention, a change-management opportunity.

Fragility loves a good process

A copied system can operate remarkably well while environmental conditions remain favourable. This makes the problem difficult to detect. Rituals do not necessarily produce immediate failure. Sometimes they preserve yesterday's successful response extremely efficiently.

Engineering disciplines learned to distrust this comfort long ago. Bridges experience loads outside everyday conditions. Electrical grids encounter failures. Aircraft lose instruments. Manufacturing lines receive imperfect materials. Networks lose nodes. Reliable systems cannot merely perform correctly when reality resembles the assumptions embedded in their design. They need enough feedback, redundancy, adaptability and local intelligence to respond when reality refuses to cooperate.

Organisations face the same problem, except their operating environment changes continuously and occasionally attends the quarterly business review.

A company that understands why a practice works can modify it when conditions change. A company that merely knows that successful companies use the practice faces a more difficult problem. Removing the practice feels dangerous precisely because nobody understands which causal function it performs. The organisation has inherited the solution without inheriting the model of reality from which the solution emerged.

The copied practice therefore survives.

Soon the organisation accumulates layers from successive generations of success. The 2018 Agile transformation remains underneath the 2020 product transformation, which supports the 2022 platform transformation, subsequently integrated into the 2024 efficiency programme and now enhanced through the 2026 AI transformation. Each layer addressed genuine concerns. Each introduced terminology, governance, metrics, tools and organisational structures. Very few disappeared when the circumstances that created them changed, because organisations have excellent processes for approving new initiatives and surprisingly immature processes for declaring old ones dead.

This produces an impressive organisational geology. Future corporate archaeologists will identify historical periods by Jira workflow, while finance continues paying software subscriptions corresponding to several extinct civilisations.

More importantly, the organisation becomes increasingly dependent on conditions it no longer understands. It can execute its operating model extremely consistently while losing the ability to distinguish the parts that create value from those that merely accompany value creation. Efficiency inside the ritual then makes matters worse: the organisation becomes increasingly proficient at reproducing a response whose relevance nobody continues to test.

That is where fragility hides. Not necessarily in chaos, incompetence or lack of process, but inside a highly ordered system whose confidence grows faster than its understanding.

Somewhere beyond the runway

The interesting thing about genuine engineering standards, patterns and procedures is that competent engineers rarely treat them as magic. A standard usually encodes accumulated experience about known failure modes. A checklist protects human attention from predictable mistakes. A design pattern provides a known solution to a recurring class of problems. Engineers borrow constantly, but engineering begins rather than ends with the borrowed solution: under which assumptions does this work, what constraints shaped it, where does it fail, and do those conditions resemble ours?

Organisations sometimes reverse that sequence. They select the practice first and discover the problem it solves afterwards.

The modern corporate runway consequently looks magnificent. The squads have assembled. The OKRs align neatly. The platform has launched. AI adoption climbs. Dashboards glow reassuringly across enormous screens. Governance confirms that everybody follows the approved operating model, and the quarterly transformation report shows an encouraging quantity of green.

At CargoCorp headquarters, Coffee Platform has just announced 100% paved-road adoption. Mean Time to Espresso has reached an historic low. Process compliance has never looked stronger, and the Coffee Transformation Office has begun preparing a case study for the next all-hands meeting.

Across the street, three engineers are drinking coffee from a small independent café.

Nobody has yet added that to the dashboard.