During the Pacific campaign of World War II, Japanese and American forces occupied a wide swath of islands. In an area as vast as the Pacific Ocean, these islands were often the only way to reliably deliver supplies and material to the front lines. Thus these islands were of vital strategic importance to both sides.
Little known to these newcomers was the fact that many of these islands were populated. Often the occupants were primitive tribes that had little to no exposure to such technologically advanced peoples. The ships, the planes, the weapons, and even the rudimentary supplies seemed like the tools of gods.
During the war, occupying forces would regularly share supplies with the native population. This was a significant leap in technology for a population that had no knowledge or skills to create such supplies on their own. For all intents and purposes, these goods were the result of magic.
After the war, the militaries left and the supply routes stopped. No longer were crates of food, tools, medical supplies, and weapons being airdropped from the sky. Without an understanding of the geopolitical situation, the native populations created highly choreographed rituals to lure the “foreign gods” to return to deliver their cargo once again. Some of these rituals were quite elaborate, including building mockups of planes and mimicking Western clothing styles.
The term “cargo cult” came to be used to describe this social phenomena. It is formally defined as a belief system in which followers practice rituals to cause a more technologically advanced society to deliver goods. Without the knowledge to create the very technology they observed, they reverted to beliefs they were already familiar with, namely the worship of tribal gods.
Over the years, the term has also made its way in fields such as science. Renowned physicist Richard Feynman coined the term “cargo cult science” to describe how some scientists rely too heavily on past results or flawed research to force unfounded conclusions. The reasoning for this behavior is often described as “it has been observed to work in the past”.
In tech, we know this phrase “it worked in the past” all too well. How often does a product leader come in to lead a project, leaning heavily on past success as a reason for using a technology or methodology clearly inappropriate for the current project? The rationale is that it always worked before, so the problem must be the people.
We see this cargo cult of technology manifest in several ways. Perhaps the most common is the avoidance of bad news. No one likes to hear things are not going well, which is often the reason for unexpected project slippage. Because IT projects are notoriously difficult to estimate, there is pressure to paint a rosy picture only to realize well into the thick of things that the estimates were off by a wide margin.
Governments are all too familiar with scourge of project delays. Over fifteen years ago, the U.S. Air Force embarked on an ambitious quest to consolidate 240 systems into one, consolidated ERP platform. Nevermind the fact that they had 240 systems to manage. Dubbed the ECSS, the project accrued over $1 billion in costs over seven years. It was canceled in 2012 when it was determined that there was no way to build the system without adding another $1 billion in costs.
Why would a project be allowed to fail for seven years without any accountability, course correction, or intervention? Fear of failure and lack of ownership as laid out in a Department of Defense report analyzing why their ERP projects often failed to deliver results:
“Program managers are unable to deliver a completely factual version of their status to leadership if it contains any element that could be considered significantly negative”
In the technology cargo cult, fear of failure is perhaps the most obvious result of the “worked in the past” mindset. Because the approach being taken is often the one advocated by the person with the most power in the organization, any negative reports are immediately suppressed or whitewashed, as the report goes onto further explain:
“To do so is perceived as weakness in execution even though the root causes may be out of the control of the program manager.”
There is no safety in an organization overrun by technology cargo cultists. This leads to a blame culture where no one takes ownership, silos emerge, and employees stay silent when things go wrong. In this environment, innovation and transformation die.
Another common behavior seen in technology cargo cults is the “circle of futility”. This is where a new idea is introduced, either because a new senior hire or executive mandate. I have often seen this in companies that jump onto the digital transformation bandwagon. They excitedly reverse course on decades of outsourcing to build their own internal engineering group.
Very quickly the excitement starts to dissipate. Years of outsourcing leaves the organization with no experience in building or scaling engineering teams. They do not have any established engineering practices, so the teams are woefully inefficient. The result is a series of failed product launches that leads to a retreat back to outsourcing.
The biggest failing of the cargo cult however is the fact that there is only ever one solution for everything, their solution. This is the proverbial “to a hammer, everything is a nail” or also known as the Law of the Instrument. It is a cognitive bias where we become over-reliant on a reliable and familiar tool. Driven by the comfort of past success, the tool becomes a hammer to solve every future problem, no matter what the context.
We see this today with debates about architecture. If you are not building with a microservices approach from day one, the cargo cult thinks your application will fail dismally. If you are not using Kubernetes, you are missing the boat. It reminds me of this quote about how everyone wanted to be like Google:
“People got kinda Google mania in the 2000s: we’ll do everything the way Google does because we also run the world’s largest internet data service.”
This is not all that different from the South Pacific tribes mimicking the actions and props of colonists they encountered. They think that if they religiously go through the motions copying some advanced tech giant, they will also magically prosper.
The reality is that what has been created is overly engineered, complicated, and expensive. These decisions blind teams from realizing more efficient and sensible directions. Maybe instead of orchestrating a bunch of microservices, maybe some of that can be rewritten to be serverless? Or perhaps instead of building everything as services, you build a monolith because you simply need to get a prototype or MVP out the door.
Context matters. Every decision made when it comes to technology should be put under the lens of the current situation, not whether a favored approach worked elsewhere. When someone does push a particular technology or process, question why they think it works in the current setting and push back on strong opinions that cannot be supported with facts.
What are some experiences you have had with technology decisions made because of a cargo cult? How did you course correct to adopt a more appropriate approach?
Community Update
It has been a long while since I wrote any community updates. The pandemic has upended things in a profound way for all of us. The loss of loved ones, the disruption of jobs, the impact to businesses, and the isolation experienced with all the lockdowns has taken a mental and emotional toll.
I have held off on talking about community stuff and events for that reason, most of us are simply trying to bring some normalcy to our lives and that of our families. There are more important things to sort out than attending more virtual things over Zoom.
That being said, while the pandemic still continues, the prospects of a vaccine and more effective treatments are offering some signs of hope. Also some parts of the world have started to see a reversal in infection rates and slowly opening up travel between countries. We are not out of the wood yet, but there is some positive news.
I am starting to be more involved in events though in my work at AWS and because of my book Community-in-a-Box. To that end, I wanted to share some upcoming talks in case you were interested and wanted to join:
CMX Connect Fireside Chat - Thursday, Nov 19 at 11:30 AM EST - a talk to share lessons learned from my book Community-in-a-Box and how you can build & scale your own community.
Ask a VC: How 5G Drives Startup Investments for T-Mobile - Friday, Nov 20 at 11 AM EST - a series for The Startup Show hosted by the AWS Startup Advocate team looking into how Corporate VC’s operates, this episode focuses on T-Mobile Ventures and their 5G focus.
Stack 2020 - Building Internal Developer Communities - Tuesday, December 1 at 9:55 PM EST - this is a conference hosted by GovTech Singapore with some all-star speakers, I will be giving a short talk on building developer communities.
YOW! Conference - Launching an Internal Developer Community - Monday, December 7 at 8:20 PM EST - overall this is one of my favorite developer conferences with many excellent speakers that I am honored to be included in, where I will talk about launching and scaling thriving internal developer communities.