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.