Cargo Cults in Management


I first read about cargo cults in Richard Feynman’s book, “Surely You’re Joking, Mr. Feynman.”

I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land. (p. 310-311)

I was a newly minted biochemist and Feynman’s unique perspective had a significant impact on my critical thinking skills. It established a “cargo cult” sensor in my brain. As my career developed and branched out into other areas of interest, the ubiquity of cargo cult thinking became apparent.

In the work place, “cargo cult” thinking may not necessarily be a bad thing. As a tool, it can be used as an “as if” frame for working out the solution to complex problems or gaining insight into black boxes. By assembling all the known and visible elements and arranging them to match the form as best as possible its easier to see what’s missing.

If an executive’s minions are behaving in a way that reflects his or her approach to management, is that a good thing? Here is where business leaders get into trouble. Are the executive’s minions imitating or implementing?

Less common, executives attempt to adopt practices that are successful at the knowledge worker level. About a decade ago I had worked to implement an Agile software development process with a small and highly capable development team. It was a daunting task: completely re-architect and develop a poorly coded application while supporting the old application. (In 30 years, this was the first and only time I recommended a complete redesign and rewrite of a major application.) Of course, we started each morning with a “daily scrum” meeting – sometimes called a “daily stand-up” – before the team set off to immerse themselves in code. These are very quick (15 minutes or less) meetings where everyone literally stands up for the duration of the meeting. The idea is that by standing, attendees are less likely to drone on about trivial matters or issues that do not require the entire team’s input. Complicated issues are quickly identified and scheduled for more detailed meetings, if necessary.

Six months into the project it was very clear our approach was working and insofar as the coding effort was concerned, we would be successful. The senior executive to this effort seemed impressed and decided to switch to a “stand-up” meeting format for the executive team meetings. They were “stand-up” meetings in name only. Rather than a once a week meeting that virtually always extended way beyond the originally scheduled 60 minutes, I now had to attend daily meetings that went on for 45-60 minutes during which nobody stood.

There were other issues with implementing the executive team scrum meetings. The senior executive did a poor job of modeling the behavior he sought and there was very little control over the clock. Developers are smart people and they notice things like this even though they are not directly participating. Among those being managed, it does little to inspire confidence in the management staff.

Nonetheless, I like the idea of applying Agile methodologies to management meetings. After action reports, as used by the military, would also help. There is also a place for storyboards and retrospectives. But implementing these and other elements would require a significant learning effort on the part of the management team. Not because the methods are difficult to understand, but because the MBA mindset of many management teams would have to loosen up a bit for the requisite unlearning to become possible.

Rethinking the idea of “management” in the context of Agile principles and practices blends quite nicely with many of the things I’ve learned around the idea of “Management as a Service.”


Feynman, R. P. (1985). “Surely you’re joking, Mr. Feynman!”: Adventures of a curious character. New York, NY: Bantam Books.

Image by Free-Photos from Pixabay

Broken Windows and Broken Scrum

Recently, I was in a conversation with a scrum master that was of the opinion that correcting teams on all the small details of practicing scrum was the best way to develop them into a high performing team. They compared this to the Broken Windows Theory of crime reduction. For example, if someone is a minute late to the daily scrum, call them out. Or the daily scrum must not deviate from the “Yesterday, today, and in the way” script regardless how well the team is communicating.

I can see the merits of developing discipline. However, without explanation or coaching that includes the rational for practicing scrum in such a way, there is a real possibility for negative unintended consequences.

  • The broken windows theory was meant to be applied in situations where the goal was to reduce crime. To apply this approach to scrum practices is to imply that any deviation from the scrum framework is criminal.
  • Similar to how the broken windows theory resulted in the emergence of “zero tolerance” laws, applying such an approach to scrum teams and strictly enforcing how they may or may not follow the scrum framework will result in a lot of command-and-control zero tolerance practices. The guides will become rules and, in turn, inflexible laws.

The approach I’ve found to be more effective is to hunt down the root causes to issues, for which being late to daily scrums or poor communication are symptoms. It’s more like being a big game hunger. Seek out the root of the problem, solve that problem, and many of the lesser issues will resolve themselves.

Photo by Tobias Tullius on Unsplash

The Sword of Peritus

[This story was inspired by the expression “double edged sword” and the “Sword of Damocles,” an ancient parable popularized by the Roman philosopher Cicero in his 45 B.C. book “Tusculan Disputations.”]

A brash young man named Tenaci strode into the courtyard of a famous swordsman named Peritus and proclaimed, “You are old and have not yet designated an heir to your school! You will teach me how to wield a sword and become a powerful warrior. It will not take long as I am already an expert swordsman. I will be the heir to your school!”

Peritus looked long and hard at Tenaci, sizing him up, but the expression on his face revealed he was not impressed by what he saw in the noisy youth before him.

“Expert, are you?” queried Peritus. “Very well, let’s see your metal.” Gesturing across the courtyard to a table that displayed an impressive array of many types of swords, Peritus instructed Tenaci, “Chose one to your liking and teach me a lesson.”

Tenaci strode confidently to the table and scanned the choices like a hungry gladiator at an Emperor’s feast. In short order, he selected a hefty broadsword. Examining it closely, he marveled at the craftsmanship that must have gone into it’s creation. Holding the sword in the ready position, Tenaci approach Peritus.

“Ah, you have chosen a powerful sword, indeed. That is ‘Vindicta,’ the sword of revenge!'”

The two faced each other for a tense moment, Tenaci in full battle posture and Peritus standing as if he were waiting for foot traffic to pass before crossing a road. Like a bolt of lightning, Tenaci made his move. As he lifted Vindicta above his head and prepared for a mighty blow, Tenaci cried out in surprise and pain and let the sword drop from his grasp. What strange magic had switched the sword end-for-end in his hands? No longer was he tightly griping the hilt, but the blade!

“Perhaps not the blade for you. Please, chose another,” offered Peritus.

Tenaci walked over the the table and examined his choices more closely. Peering back at Peritus with a suspicious eye, Tenaci chose a much lighter sword. The hilt looked the same as his previous choice, but the blade was thinner and flexible. Again, he marveled at the craftsmanship. The balance in this blade was remarkable.

“Interesting choice,” said Peritus. “That is ‘Invidia,’ the sword of envy.'”

Again, the two faced each other as before, Tenaci in full battle posture and Peritus casually waiting. Maneuvering into position, Tenaci prepared for a whip strike across Peritus’ face. Faster than an eye can blink, he made his move. But again, before he scarcely began to swing Invidia, Tenaci cried out in pain and released his grip on the sword which sailed harmlessly across the courtyard, clattering to rest at the main gate. As with Vindicta, Invidia had switched end-for-end while in his grasp.

“Chose another?”, suggested Peritus.

Looking down at his bleeding hands, “I think not,” replied Tenaci. “Your table full of tricky swords.”

“Here, then, is your first lesson. You know much less than you think you do,” stated Peritus. “And for your second, look at the table once again and tell me what you see in this collection of swords that is common to all of them.”

Tenaci stood before the table for many hours. Scrutinizing every detail, but the blades were all different – length, thickness, weight, edge, shape. He could discern no common element. As the sun set, the waning rays of light struck the table in a way that illuminated a simple inlay of gold and silver on the hilt of each sword. Only then did Tenaci see that every hilt was identical.

“I see the common element!”, exclaimed Tenaci.

“That handle goes by many names,” explained Peritus. “‘Misericordia’, ‘Gratia’, ‘Remissio’, to name a few. Compassion, gratitude, and forgiveness. It isn’t the blade you hold. You hold the handle and the handle holds the blade. Unlike all the other swords in the world, these are honest and virtuous. If your heart if filled with revenge or anger or hate, then the weapon transforms so that you are holding the end that matches your wishes.”

“I don’t see the sense in that,” snorted Tenaci. “What good is such a weapon? If I am angry or vengeful or afraid or feel the need to deliver justice, then those blades should serve me! If the blade turns on me than I’m the only one hurt! If I can only use a sword with forgiveness or compassion in my heart, why would I ever draw such a sword?”

As he turned to leave, Peritus nodded to Tenaci and said, “Lesson three.”

Image credit: Richard Westall – own photograph of painting, Ackland Museum, Chapel Hill, North Carolina, United States of America, Public Domain,

Frameworks, theoretically speaking…

Figure 1
Figure 1

Theoretical frameworks are defined more by what they do than what they are. To understand this, consider a physical framework for a house (Figure 1.) Its purpose and function is, quite literally, easy to grasp. It solves problems in the physical world and it’s easy to understand how such a framework can add value to our lives. It’s also easy to assess the limitations of a physical framework. The house framework reveals the underlying structural of beams, joists, rafters, and such. With this structure, it is easy to imagine this as an ideal solution to protecting a family from the weather. It is equally obvious that this same framework would be wholly inadequate as a sports stadium. The structure in Figure 1 adds value to the eventual solution for protecting a family from the weather, but as a solution for hosting a large sporting event it leaves much to be desired.

Staying with the physical framework for a moment, several useful rules become apparent.

  • The problem defines what framework should be used. Frameworks ideally suited to solving one problem may result in disaster if applied to a different problem. A corollary could easily be that there is no single framework that can solve all physical structure problems. Rather, frameworks can be composed of a wide variety of materials and can come in all manner of shapes and sizes.
  • The choice of physical frameworks defines the tools, techniques, and materials to be used during construction of the overall solution.
  • Frameworks necessarily limit focus. By focusing the crew in this way the contractor can better controls quality, cost, and scope.

Similar to how a structural frame (or framework) to a house provides underlying support in the physical world, a theoretical framework provides an underlying conceptual structure in the world of ideas. Scrum and SAFe are examples of theoretical frameworks. The rules for physical frameworks apply equally well to theoretical frameworks. However, when the conversation shifts to theoretical frameworks, people often struggle with how to apply these rules. Being less tangible, it is easier to inadvertently select a theoretical framework that results in a sub-optimal solution for a particular problem. Without a clear understanding of the problem and the capabilities of a selected theoretical framework, a manager may inadvertently select a set of tools, techniques, and practices that are unsuited to the task. The framework won’t support the desired solution.

Just as with a building designer, the challenge for the leader tasked with implementing Agile is that he or she must first have a clear understanding of the problems they are trying to solve. They must also have a solid understanding of the possible Agile frameworks from which the optimal choice can be made.

As with physical frameworks, theoretical frameworks define the tools and techniques employed during the actual work effort. When the theoretical framework is appropriately matched to the business problem, leadership can more easily identify and define variables and constants, design define meaningful metrics, and make more effective decisions for reaching desired outcomes.

Expert 2.0

A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this “Linus’s Law.” (P. 41)

So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.

This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.

Imagine, around 1440, a gentleman from Verona named Luigi D’vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent “movable type.” This last guy actually existed in the form of Johannes Gutenberg.


Assuming D’vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg’s interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.

But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the “magic” to happen. Quality “thinking outside the box” doesn’t happen without a lot of prior preparation. You will need to know something about what’s outside the box. And note, there aren’t any limitations on what this “what” may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn’t guarantee that it will be useful. It only enhances the possibility for innovative thinking.

There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the “magic” of innovative thinking, as defined by Haskell (2001, pp. 45-46).

  • Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
  • Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
  • An understanding of the history of the transfer area(s) is vital.

To summarize, in your field of interest you must be an expert of both technique and history (lest your “innovation” turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.


Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.

Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O’Reilly & Associates, Inc.


Image by István Kis from Pixabay

Tools for Practice

Building the tools you need to develop a skill will also deepen your understanding of that skill.

The pandemic has offered unprecedented opportunity for reflection and self-improvement. Unsurprisingly, most people don’t see it this way and therefore have failed to take advantage of the opportunity. Upsetting the status quo and the familiar – however slight – leads to a disproportionate amount of stress and anxiety for many people. The prospect of getting to know their families or themselves better proves uncomfortable enough to drive people toward bing-watching TV, over-eating, alcohol, or any number of other distractions. Anything to avoid introspection. My theory is that this happens because most people have either lost or never had the skills for self-reflection. External validation is the way of the 21st century. That usually ends up with them expending exorbitant amounts of effort justifying their shortcomings or assigning blame to the nearest face they can put on their problems – an “annoying” partner, an “uncooperative” co-worker, etc.

I also believe it takes very little effort to begin the work of reflection, introspection, and self-improvement. Start simple.

When it was clear the pandemic lock-downs were going to go on longer then the “experts” kept saying – evidenced by the weekly movement of the goal posts – I began to wonder how I might use this newfound flexibility for how I organize time. No longer confined to the hours during which I would normally be in the physical office, I could now complete my 8 hours of work – broken into pieces – at almost at any time during my waking hours. Plus the distance I had to commute back and forth from home and work shrank to an incredibly small fraction of what it used to be. This, too, opened up more time. This change didn’t just occur in my world, but globally. And since everyone else still needed to stay employed, many creative people found ways to continue their professions in a virtual environment. Suddenly, engaging in things of interest but were unattainable because of time and space requirements became available.

I had been wanting to rekindle my interesting in playing cello for years. I hadn’t had a lesson in over 10 years and practice had fallen by the wayside. Now, connecting with an instructor was not only possible, but the number of options had exploded. There are now many on-line videos and instructors available. After a little research, I connected with an instructor in New York City and have been taking weekly lessons for the past three months.

The re-introduction of live music – particularly music that I’m playing – has had a surprisingly positive impact on my disposition. As a card carrying introvert, I thought I’d been handling the pandemic lock down pretty well, especially when compared to many of my peers. Yet this small change, focused on personal development, brought warmth and light to mid-winter days.

So that’s the back story. Now that I’m in the groove again with playing cello, I can describe several things about this experience that I’ve learned with respect to practice, particularly deliberate practice.

Along with playing cello, I wanted to deepen my understanding of music theory and learn how to sight read music. During one of my lessons, the instructor and I kicked around the idea of using flash cards. The card would show a single note and the student would play that note. Searching later for such an application was unsuccessful. It probably exists, but it wasn’t something I wanted to spend more than 30 minutes trying to find.

All the flash card programs I looked at are designed to teach things in a question – answer format. They work well for subjects like history or learning a new language. But nothing that would simply show a new card after a time delay. So I wrote my own program to accomplish this. In the process, I developed my understanding of the cello’s range of notes and music keys in general. Here’s a screen capture of the first iteration’s MVP:

At an adjustable interval, a new note within the cello’s range is displayed in the selected key. For my skill level, this is immensely challenging. And I can tell it is developing my skills for sight reading and quickly finding a particular note on the instrument.

Developing tools like this is second nature to me and the result of many years of experience working with wood and solving business problems with software. Each of these activities has a tenet that if you can’t find a tool you need, you build what you need from scratch. This tenet is all the more powerful by having stewed in the mindsets associated with hand tools and open source software. In a very real sense, creating tools that support acquiring a new skill are part of the practice. To build an effective tool, you must fully understand the problem it is intended to solve. An effective tool is the result of having asked and answered many good questions. And, of course, all this is driven by an Agile mindset (iterations, tests, experiments, redesign, retest, etc.) design thinking, and understanding the context in which the tool will be used (systems thinking.)


Image by endri yana yana from Pixabay

The Team Hero

Very good article from Margaret Heffernan, “It’s Finally Time to Retire ‘Good to Great’ From the Leadership Canon.” This quote stands out:

Collins insists that great companies get the right people on the bus and the wrong ones off. But how do you identify them proactively? Collins is thin on detail. Their values matter more than skills, but how can you tell? They’re unafraid to face brutal truths — but we all avoid unpleasant realities, so how do serious leaders foster candor? There’s evidence that what distinguishes high-achieving teams is the quality of connectedness between people rather than the individuals themselves, but such systemic thinking is absent from Good to Great, which inhabits a strictly linear universe. You either are Level 5 or somewhere lower on the ladder. The people on the bus are right or wrong. The toughest parts of leadership are, apparently, easy.

This reminds me of the the 1998 Sydney to Hobart yacht race as described by Dennis Perkins and Jillian Murphy in their book “Into the Storm.” Larry Ellison’s purchased professional crew on his yacht, “Sayonara,” put in a mighty fine performance. But the race was won by the scrappy and tight knit little crew on the “Midnight Rambler.”

If the quality of connectedness between people is a distinguishing characteristic of high-achieving teams, what does that say about the team “hero” – that individual who insists on outperforming everyone else on the team? In my experience, the team hero’s contribution to the team effort is much more likely to be disruptive than productive. I’ve observed the following qualities:

  • They manufacture crisis that only they can solve.
  • They work outside the team, pleasing others – particularly people with status – while progress on work assigned to the team suffers.
  • They hoard information and work assignments.
  • Show little interest in mentoring or helping others on the team succeed.
  • Are acutely sensitive to criticism and dismissive of feedback.
  • Display many of the attributes of a fixed mindset.

Managing a team with a hero on it usually means you spend most of your time managing the hero or scrambling to mitigate the adverse effects of their behavior. The team suffers and second order effects soon follow. I’d much rather manage a team of solid performers who understand how to work together.


Photo by Javier García on Unsplash

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and erodes morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the story line.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough for now” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

Photo by juan pablo rodriguez on Unsplash