Cargo Cult Process
How useful process drifts into ritual, and the question that catches it
After World War II, islanders in the South Pacific built runways that no plane would ever land on.
During the war, foreign militaries had set up bases on their islands. Planes arrived constantly, carrying food, medicine, and equipment. When the war ended, the bases closed and the planes stopped coming. Hoping to bring the cargo back, the islanders recreated what they had watched the soldiers do. They cleared landing strips, carved headsets out of wood, and lit signal fires along the runways. They copied every visible detail of the thing that had delivered the cargo. Nothing came.
Feynman used this image to describe bad science. It works just as well for engineering teams: you can reproduce the form of something perfectly and still miss the part that made it work.
But the islanders at least had an excuse. They never saw the machinery behind the cargo. Most of our ceremony is sneakier than that, because it doesn’t begin as a copy of something we never understood. It begins as a real solution. Standups surface blockers, retros capture lessons, sprint planning creates alignment. Then the underlying problem shifts, or the team gets good enough that the problem shrinks, and the process stays on the calendar anyway. The justification fades. The meeting continues. Each small accommodation feels reasonable on its own, and the gap between the process and its purpose widens so slowly that no one can name the moment it stopped working.
There’s a second way ceremony takes hold, and it’s the one the islanders would recognize: imitation. A company sees that high-performing teams at Google use OKRs and adopts them, without checking whether it shares any of the conditions that made OKRs work at Google’s scale. The practice travels without the reasoning.
Metrics ritualize faster than meetings. A meeting at least announces its cost. You sit through it, and now and then you resent it. A number just sits on a dashboard and asks nothing of anyone, so nobody thinks to question it.
A metric starts as a question. How long does it take to get a change into production? Useful question. Then it lands on a dashboard, gets tied to a quarterly goal, and stops being a question. People start treating the proxy as if it were the thing it was meant to approximate. Researchers call this surrogation. Story points completed quietly turns into “engineering output”. Time to merge turns into “code quality”. PRs reviewed turns into “mentorship”.
This almost always happens in good faith. People forget there was ever a gap between the proxy and the thing. One bank decided that accounts opened per customer was a fair proxy for the strength of its customer relationships. Employees went on to open thousands of fraudulent accounts, many of them believing they were doing the job well.
The way to resist surrogation is to never let one number carry a whole construct. DORA tracks four metrics for delivery performance (deploy frequency, lead time, change failure rate, recovery time) precisely because any one of them can be gamed in isolation. Track only deploy frequency and you can inflate it by shipping smaller, emptier deploys. The other three make that move visible.
There’s an inverse problem too, which Hubbard documented after years of measurement audits. The variables with the highest information value in an organization are usually the ones getting the least measurement attention. It’s the same habit running the other direction: people measure what is easy to count, not what would tell them the most.
The instinct, once you spot ceremony, is to tear the process out. That instinct is its own trap.
Coordination cost doesn’t vanish when you remove the process. It moves into DMs and the head of the one engineer who “just knows what everyone is doing”. Fine until they leave, the team doubles, or someone has to onboard without their bandwidth as the documentation.
“We move fast, we don’t do process” starts as a tactic and quietly turns into an identity. It shows up in the pitch deck, recruiting copy, the daily pride of not being one of those companies. The cost is identical to ceremony, the gap between practice and purpose widens, just without a meeting on the calendar. The team runs five “quick syncs” a day with whoever holds the context, and calls it momentum. By the time the team needs structure, adding any feels like an admission of failure instead of a normal part of growing. The team postpones the structure conversation until something forces it. A key person burning out, a major incident, a hire quitting. Then it overcorrects.
Three questions I’ve found useful for evaluating any recurring process.
What decision does this process inform?
A specific decision, made by a specific person. “We’ll build x instead of y”, “we need to staff this differently”, “the release cadence has to change.” If the honest answer is something like “alignment”, “visibility”, or “consistency”, dig one layer down for the real decision underneath, or admit there isn’t one.
When was the last time this process changed a decision?
Walk back through the recent instances. If the team would have done the same thing with or without the meeting, the practice has drifted from its purpose. That isn’t grounds to kill it on the spot. It’s grounds to move the burden of proof onto whoever wants to keep it.
Could you get the same result for less?
Sometimes a thirty-minute meeting produces real value that a five-minute async writeup would produce just as well. The meeting isn’t useless. It’s just more expensive than it needs to be.
You won’t always think to ask those questions, though. So it helps to recognize the smells of a drifting process before you’ve thought to interrogate it. A few:
A retro that produces the same action items it produced last quarter. It has turned into a venting structure instead of a learning one. Redesign the format before you abandon the idea.
A metric that trends the “right” way for two quarters while the underlying reality looks about the same. Check whether the number and the thing it stands for have quietly come apart.
A process added after a single incident, with no sunset clause. Incidents create pressure to add checklists; almost nothing creates pressure to retire them. That asymmetry is how you end up with a forty-step deploy procedure everyone follows loosely, which gives the feeling of thoroughness and none of the substance. The fix is cheap: give new process an expiration date the day you introduce it. “We’ll run this for two months and then decide.” It forces a retirement conversation that otherwise never happens.
Someone proposing a process mainly because other teams do it. The question to ask out loud: what does this solve for us, and would we have invented it on our own?
Ceremony accumulates for boring reasons. Adding process is easier than removing it. The person who introduced it has usually moved on. And questioning a ritual spends social capital, while sitting through it only spends time.
So treat process like code. Version it, hold it against current requirements, deprecate what no longer earns its place. A process with no owner is dead code. It does nothing, costs attention, and makes the whole system harder to reason about.
The habit underneath all of it is a single question, asked of every recurring commitment: does this change a decision? When the answer is no, that isn’t a verdict on whoever set it up. It’s information. And information was the point of the whole exercise.