Hey friends!
You ever notice how people sometimes copy the shape of a good practice without actually understanding the reason behind it? We have a name for this phenomeon: it's called cargo culting.
The name comes from the Pacific theater of the Second World War: throughout the region, U.S. and Japanese militaries built airstrips as they occupied various islands. Soon after, planes landed... full of supplies. After the war, the planes left, but some of the native islanders wanted more cargo to come. They had observed the occupiers building the airstrips and made a logical leap to cause-and-effect, so they built bamboo runways, carved wooden radios, even lit fires to look like landing beacons. They outfitted platoons of their friends with bamboo "rifles" and marched in close-order drills. They did everything that looked like what had brought the cargo, but the planes weren’t coming back.
When Technologists Create Cargo Cults
I've encountered many examples of Cargo Cults in my career:
Management announces an initiative to "be more Agile", but as Jez Humble famously put it, "nothing changes except that we have our meetings standing up".
Teams adopt DevOps practices by creating a "DevOps team" instead of involving Dev in Ops and Ops in Dev.
A requirement for Test Automation, or static analysis testing, or some other development practice is announced, and the team complies, but nobody trusts the tests or the scan or whatever to release (or block) deployment pipelines.
Not all of the examples are about the software development lifecycle, either...
There's recently been a surge in companies announcing Return-to-Office mandates and an often-cited reason for the mandate is "because other major tech companies are doing it".
Another recent trend has been "flattening the org" and eliminating lots of middle-management positions.
Please hear me on this, y'all... I'm not here to hate on these ideas. (Ok, well maybe I'm hating a little bit on RTO... alright I'll stop for now! 😏). The reason these are bad ideas is because they're implemented without reasoning or data beyond "well $SOME_OTHER_COMPANY is doing it so we need to do it as well".
The real danger of cargo culting isn’t the bamboo runways; it’s the false sense of progress. You feel busy, you look official and professional (and maybe even knowledgeable), but nothing’s actually moving. Your organization isn't getting measurably better... and when nothing moves, cynicism creeps in. Your engineering teams roll their eyes behind your back at “the new thing,” leaders lose their credibility, and suddenly even good ideas get lumped in with the failed rituals.
How to Escape the Cargo Cult
So should we just never look at other organizations again? That's absurd! We don't need to avoid practices from elsewhere, but we do need to ensure that we only borrow with understanding. We shouldn't adopt practices until we really grok what's going on underneath the surface! Here are a few quick moves that can help us:
Ask “why?” twice. If your leadership is rolling out a new initiative, or framework, or mandated practice, push back and ask for the problem it’s meant to solve. If they can’t name it, you might be about to build a bamboo runway. And I say to ask twice because the first why can often be packaged as corporate platitude... "to increase synergy!" Asking why a second time gets you beyond that surface-level response and nudges toward actual thought.
Run small experiments. Instead of dropping a whole framework into place across the whole organization, test one piece in a low-stakes corner of your org. The first push is going to have bumps, so we should aim to learn, then scale. I have a friend who says it's like the warning on carpet cleaning products: "test in an inconspicuous area first".
Measure outcomes, not rituals. This one might be the most important item on the list: you absolutely have to measure the right things! Don’t count how many stand-ups you held, count how much faster decisions or releases happened. Don't measure how many helpdesk tickets you closed, measure how often a change caused a failure that affected your customers.
Adapt to context. Some things that worked at Amazon with 10,000 engineers won’t have the same effect on a team of five. Yes, some of them will directly translate, but you need to be thoughtful about it... and the more disruptive your change is, the more certainty you must provide that the change is needed.
Wrapping up
Reminder: copying someone else isn’t bad. It’s actually how we start almost everything. Kids learn language by repeating sounds before they understand grammar. Junior devs copy Stack Overflow snippets before they understand the architectural patterns. But at some point, growth means asking why.
Because if all you’ve got is a bamboo rifle and a wooden radio, you’re not building an airstrip. You’re playing soldier.
Top comments (0)