"The Planes Don't Land"
The term "Cargo Cult" comes from a famous warning by physicist Richard Feynman in his 1974 Caltech commencement address. During World War II, American forces built airstrips on remote Pacific islands to receive supply drops. Indigenous islanders observed that when runways existed and people spoke into radio equipment, planes arrived with valuable cargo (food, medicine, tools).
After the war ended and the Americans left, some islanders built replica runways out of cleared dirt, "control towers" out of bamboo, "headphones" out of coconut shells, and "antennas" out of sticks. They performed the rituals they had observed—standing on the runway, waving landing signals—and waited for the planes to return.
The Lesson: They copied the form (what it looked like) but missed the function (the aerodynamics, radio frequencies, logistics networks, and fuel infrastructure that actually made planes land). The form was visible and easy to replicate. The function was invisible and required deep understanding.
Cargo Cult Symptoms in Software Engineering
This pattern is pervasive in our industry. Here are common examples:
| Symptom | Form (What You Copied) | Function (What You Missed) |
|---|---|---|
| "Spotify Squads" | Team naming convention and org chart structure | Years of cultural evolution, specific scaling pain at 100+ engineers, internal tooling for cross-squad coordination |
| "Google SRE" | Error budgets, SLOs, and on-call rotations | Massive automation investment, 10:1 developer-to-SRE ratio, custom internal platforms (Borg, Monarch, etc.) |
| "Netflix Chaos Engineering" | Running Chaos Monkey in production | A culture where engineers own their services end-to-end and are empowered (and expected) to fix what breaks |
| "Microservices" | Splitting a monolith into 20 services | Organizational scaling needs (independent team deployment), operational maturity (distributed tracing, service mesh), and the Conway's Law dynamics that made it necessary |
| "GitOps" | Storing manifests in Git | Reconciliation loops, drift detection, and the operational discipline to never make manual changes |
A Real-World Diagnostic
Here is how to spot Cargo Cult Engineering in practice:
- The Artifact: A startup builds a complex Kubernetes cluster with Istio service mesh, Argo CD for GitOps, and active-active failover across two cloud regions.
- The Reality: They have 50 daily active users, 3 backend services, one developer who understands Kubernetes, and no dedicated operations team.
- The Result: They have the appearance of a tech giant's infrastructure, but they spend 60% of their engineering time debugging Istio configuration and managing Kubernetes upgrades instead of building features. The "cargo" (users, revenue, scale) never arrives because the product can't iterate fast enough.
The Root Cause
Cargo Cult Engineering happens when teams optimize for legibility (looking like they're doing the right thing) rather than effectiveness (actually solving their problem). It is driven by:
- Fear of being wrong. "No one ever got fired for choosing Kubernetes" is the modern version of "No one ever got fired for buying IBM."
- Conference-driven development. Teams adopt whatever was presented at the last KubeCon without evaluating whether the presenter's context matches theirs.
- Resume-driven development. Engineers push for technologies that look good on their resume rather than technologies that solve the business problem.
Key Point: The cost of Cargo Cult Engineering isn't just wasted effort—it's opportunity cost. Every hour spent maintaining unnecessary complexity is an hour not spent on what actually matters: shipping features, improving reliability, and understanding your users. The most dangerous Cargo Cults are the ones that feel productive because you're always busy—busy maintaining the bamboo control tower.