Vol. IV · No. 04 Monday · 29 June 2026
Now writing — Why Your Index Scan Is Slower Than a Sequential Scan: When the Planner Is Right to Ignore Your Index dispatches · 3 streams
← All dispatches
Systems Gone Strange Dispatch 8 min read · 12 Jun 2026

The Cargo Cults That Built Runways for Planes That Never Came

On cargo cults, bamboo control towers, and why your company's "AI strategy" might just be a scar in the ground.

The Cargo Cults That Built Runways for Planes That Never Came
Cargo Cult Runway (AI-Generated Historical Reconstruction)

Imagine you're a young man on Tanna Island in the 1940s. Life is, by the standards you've always known, pretty consistent. Fishing. Farming. The rhythm of the seasons. Then one day, the sky opens up and starts raining miracles. Planes the size of whales descend from nowhere. Ships arrive stuffed with radios, trucks, canned peaches, medicine, and a fizzy brown drink the foreigners seem to worship called Coca-Cola. Men in matching outfits march around in formation, talk into small boxes, wave their arms at the sky — and more cargo appears. Every. Single. Time. It's the most reliable magic system anyone has ever witnessed. Then the war ends. The men in matching outfits pack up. The sky goes quiet. The ships stop coming. What would you do? If you're honest with yourself, you'd probably do exactly what some islanders on Tanna did. According to *Smithsonian Magazine*'s account of the John Frum movement in what is now Vanuatu, devotees began honoring a ghostly American figure they believed would one day return — and with him, the goods.¹ The radios. The trucks. The medicine. The Coca-Cola. Here's the detail that always sounds invented but isn't: they built a runway. Smithsonian reports that men carved an airstrip out of the jungle, by hand, to tempt the American planes back down from the sky. Elsewhere across the South Pacific, other followers constructed bamboo control towers and aerials, faithfully reproducing the shapes they'd observed.¹ A runway. Hand-carved. Waiting. No planes came, of course. But before you smirk — and I say this with genuine affection — let me introduce you to some people you may recognize. — ## We're All on the Runway I once watched a three-person startup spend six weeks building an internal design system. Three people. They could have communicated their entire design language by turning around in their chairs and talking. But Airbnb had a design system. Linear had a design system. Notion had a design system. Clearly, that's what real companies do. They built it beautifully. Figma components. Tokens. A whole Notion page documenting the spacing scale. It was, genuinely, impressive work. Then they ran out of runway — the financial kind — before shipping a product anyone used. I've seen a solo founder copy Stripe's famously meticulous API documentation, in full, for a product with zero users. I've watched a pre-revenue SaaS add enterprise pricing tiers ("Contact Sales for custom plans!") with no sales team, no enterprise prospects, and no product that enterprises would conceivably want to buy. I've sat in meetings where teams with eight people and no revenue run quarterly OKR planning sessions with colored spreadsheets and confidence that would impress a Fortune 500 CFO. The rituals are performed with total sincerity. The control towers face the right direction. The aerials are the right height. The sky remains empty. — ## The AI Runway The current vintage of this behavior has a specific flavor, and it's worth naming directly. Right now, thousands of teams are adding "AI features" not because their users asked for them, not because there's evidence their users want them, but because real companies have AI strategies. OpenAI has an AI strategy. Microsoft has an AI strategy. The startup that just raised a Series B has an AI strategy in their deck. So a tool built for plumbers gets an AI assistant that can "help you manage your schedule." A recipe app gets an AI that "generates personalized meal plans." An invoicing tool gets an AI that "provides intelligent insights on your cash flow." Users ignore them at roughly the same rate the planes ignored the bamboo towers. This isn't an argument against AI. It's an argument against copying the visible shape of a thing before understanding why the thing exists. The teams doing genuinely interesting work with AI started from a real, specific, painful user problem and discovered that a model could solve it in a way nothing else could. The teams building runways started from "we should have an AI feature" and worked backwards toward any problem that would justify it. The sequence matters enormously. Almost nobody talks about the sequence. — ## What They Saw vs. What Actually Existed The islanders made no observation errors. Their fieldwork was impeccable. Planes *do* land on runways. Towers *do* direct them. Uniformed men *do* perform rituals before cargo appears. Every data point they gathered was accurate. The inference was just missing a crucial variable: everything else. Factories. Procurement chains. Military logistics. Shipping lanes. Fuel depots across three oceans. War finance. An industrial civilization humming away ten thousand miles to the east. The runway was a real thing. But the runway wasn't why the planes came. The runway was the last inch of a system that stretched around the entire world. The shape of the system was local and observable. The cause of the system was vast and invisible. Modern businesses make the exact same error constantly, and the mechanism is identical: we see a successful company, we catalog its visible artifacts, and we reproduce the artifacts. We skip the archaeology. > You can copy the shape of success without copying the cause of success. The shape is always more visible. The cause is usually boring. The cause is almost always something deeply unsexy: a product that solves a painful problem better than anything else. Distribution that took years to build. Customer trust earned through ten thousand small interactions. Cash flow discipline. Operational rigor. A team that stays when it gets hard. The shape is a design system, a pricing page, a brand system, an "AI strategy." The shape photographs beautifully for the deck. — ## The Most Dangerous Sentence in Business "That's how successful companies do it." This sentence has killed more good products than bad code ever will. Successful companies leave behind an archaeological record — artifacts from every stage of growth, visible to anyone who goes looking. Process documents. Brand guidelines. Org charts. Hiring loops. OKR templates. Values pages with six bullet points and an ampersand. All of it looks like evidence of what made the company successful. Most of it is just what the company looked like *after* it became successful, which is a completely different thing. A process designed for 500 people will quietly suffocate a team of five. Not dramatically — just slowly, through friction and overhead and meetings about meetings, until everyone is very busy and nothing is getting done. A dashboard that helps a mature company understand a complex business will hypnotize an early team into staring at numbers that don't mean anything yet, optimizing metrics that don't drive growth, feeling productive while the actual problem — that nobody wants the thing — goes unaddressed. A complex permission system that protects an enterprise product with 200 customers will make your tool so annoying to use that you never get your first 10. The artifact made sense in its original context. Transplanted, it becomes a bamboo tower. ### The questions worth asking before you copy anyone Before reproducing a tactic from a company you admire, try these: - **What problem was this originally solving?** Be specific. "Airbnb built a design system" is not specific. "Airbnb built a design system because inconsistency across 40 engineers was causing weeks of rework per quarter" is specific. - **Do we actually have that problem yet?** This is the one people skip. - **What invisible infrastructure made this work?** What were the hidden conditions — team size, maturity, market position, capital — that made this a good idea for them? - **What's the cheap version?** If Airbnb's version required a three-person team for six months, what would solve 80% of the problem in a week? - **What happens if we just... don't?** Sometimes nothing happens. Sometimes that's the data you needed. The last question is the one that stings. — ## When Copying Works To be fair to the bamboo towers: sometimes the mimicry is exactly right, and it would be dishonest to pretend otherwise. Copying works when you understand *why* the original worked and your situation rhymes with theirs. A company at Series B has legitimate reasons to look at how other Series B companies structured their sales org — not to copy it exactly, but to understand the design space. A team that's just hit 100 customers has real reasons to look at how other teams handled the transition from founder-led sales. The error isn't learning from others. The error is treating visible artifacts as recipes rather than clues. A recipe you follow. A clue you investigate. The difference, practically, is the archaeology. You don't copy the artifact. You study it until you understand what problem it was solving, under what conditions, and whether those conditions exist in your situation. Then you decide. That takes longer and feels less satisfying than downloading a template and filling in your company name. Which is, of course, precisely why most people don't do it. — ## The Runway Test Here's a simple filter I've found useful for nearly every "we should build this" conversation: **Does it bring the planes?** Not eventually. Not theoretically. Not "it will signal maturity to investors." Right now, for your actual users, with your actual product, at your actual stage: does building this bring the planes? A roadmap does not bring customers. A dashboard does not create insight. A mobile app does not create demand. A pricing page does not create willingness to pay. A brand system does not create trust. An AI feature does not create value. A process does not create discipline. Every single one of these things *can* help — when the underlying machine exists, when the real problems they solve are actually the problems you have. Without the machine, they are bamboo control towers: lovingly constructed, structurally sound, directing nothing. The most useful version of this test is the negative: if you stripped this away tomorrow and replaced it with nothing, would the planes stop coming? Would customers leave? Would growth slow? If the answer is no, you might be building theater. — ## The Uncomfortable Part The cargo cult story is usually told with a kind of affectionate condescension. The anthropologists have a slightly amused tone. The business writers who reference it — and there are many — tend to chuckle warmly at the islanders while implying their readers are too sophisticated for such confusion. This is, to put it gently, the wrong lesson. The islanders were not stupid. They were doing exactly what every human does when confronted with a successful system they don't fully understand: identify the symbols, reproduce the symbols, hope the system responds. This is pattern-matching under uncertainty, and it is often how learning *begins*. Children do it. Scientists do it with preliminary hypotheses. There's nothing embarrassing about the mechanism itself. The difference between them and us is that they had genuinely limited information. They'd never seen a factory. The industrial supply chain was completely outside their epistemic frame. They were working with everything they had. We have Google. We have postmortems and case studies and first-principles frameworks and entire books about hidden infrastructure. We have people who will *explain the whole system to you on a podcast, for free*. We build the bamboo towers anyway, usually with a Figma file, a sprint plan, and a very confident slide in the investor deck. That's the uncomfortable conclusion: it's not that the islanders were naive and we're sophisticated. It's that we have every tool needed to do the archaeology, and we usually choose not to, because the artifact is faster and the cause is boring. — ## The Difference Between Infrastructure and Theater The serious builder's job isn't to avoid copying. It's to become good at the distinction between infrastructure and theater. Infrastructure is the thing that, if you removed it, the machine would stop. Theater is the thing that, if you removed it, you'd feel embarrassed at first and then nothing much would change. Most companies, if they're honest, are running more theater than they think. Most of it got added because another company had it. Most of it has never been tested against the question of whether it actually does anything. That test is uncomfortable to run. It tends to implicate things people are proud of. It requires admitting that the six-week design system sprint and the quarterly OKR planning and the AI assistant nobody uses might be, in some technical sense, a runway with no planes. But that's the work. Because a runway without logistics isn't a strategy. It's just a scar in the ground, waiting for a sky that owes you nothing. — *¹ Smithsonian Magazine, ["In John They Trust"](https://www.smithsonianmag.com/history/in-john-they-trust-109294882/)*