Leadership Reflections from Apollo at 50: Failure, Complexity, and Control

This post is #WorkingOutLoud, sharing a draft chapter from my upcoming Social Age Guidebook on ‘Apollo: Leadership Reflections from the Space Race’. It’s not proofed or finalised yet, so please treat it kindly.

Failure is not an option” is the title of Gene Kranz’s book, providing a comprehensive overview of Mission Control, from it’s inception, through his time as Flight Director. Today it is a rather jaded expression: more a machismo assertion of power than a guiding principle. Jaded by it’s application in contexts that do not justify it, or to systems that can never guarantee it. Failure is always an option, possibly the default one.

Of course, in one of those narrative ironies, Kranz never used the phrase himself: it was written by the screenwriters for the Apollo 13 film, and then sounded so good that Kranz took the fictitious words that he never uttered and made them his own [1].

But even if he never used the words, the statement reflected a real mindset of the time. Mission Control was built around a new paradigm: an approach of systematised problem solving and connected knowledge hitherto unknown. It’s one of the most fascinating aspects of Apollo: the way that they had to invent the rocket, and invent the systems of oversight and control to actually use it.

Before it, the Manhattan Project had tamed, then unleashed, the power of the atom bomb: a programme of great complexity, and secrecy, with the ultimate aim to take life away. Apollo worked on a different, scale in both directions: it needed more people to design and build it, but it aimed only to affect three people as a result. And it was designed to keep them alive [2].

When the Saturn V rocket launched, it had the potential to detonate with one twenty sixth the power of the atomic bomb that destroyed Hiroshima: a not inconsiderable challenge to life and limb if you were sat atop it [3].

Assuming the craft survived launch, a mission to the moon may last a number of weeks: during all that time, there was the constant need to monitor systems, identify and mitigate risks, dynamically adapt the schedule, and react to emergent issues, be they human or mechanical.

Travelling on earth is risky because of dangers that turn up and kill us, but broadly, the default state is life: to starve, dehydrate, or succumb to illness usually takes time. Life can be lost suddenly to accidents, but even then there is a chance of extraction or treatment for broken limbs. Beyond the limits of our atmosphere though, the default state is death, with no prospect of rescue, or resuscitation. Any leak, or mechanical failure, one single wrong decision, can instantly cause a disaster. Space is very unforgiving like that.

In such situations, we rely on protective systems: the technology of Apollo can, in that sense, be seen in two contexts. The first is transport, to get us to the moon and back, with the various permutations of craft, and staged launch. The second is to preserve life, through life support systems (when things are going well), and emergency protocols (to recover when they don’t). Apollo can, in this sense be seen as a project that lofted a small bubble of our earth’s atmosphere safety to the moon, and retrieved it days later. The entire programme represents a series of connected, and nested, bubbles. Space suits themselves are small space ships, capable of preserving life.

Gene Kranz, as Flight Director, was responsible for the systems that facilitated both those ends: to successfully propel three men to the moon and back, and to ensure they stayed alive whilst making the journey. And to do so meant inventing an entire discipline of Mission Control.

Whilst images of the Control centre show lines of desks, and serried ranks of white shirted men, the reality for the astronauts in the Command Module was somewhat different: for them, it was largely a conversation with a friend.

The hierarchy of Mission Control relied on principles of specialism (experts on hand), aggregation (the interaction between disciplines: combinant effects), filtering (signal from noise, and both the timeliness, and relevance to the matter at hand [4] ), structured decision making (reporting lines that accounted for dependencies and causality, in the days before computers could do this), and flow (the right knowledge or decision points in the right hands, ‘just in time’, before JIT was a thing).

The entire apparatus was intended to funnel down to two individuals: the Flight Director, and CapCom (the Capsule Communicator). The Flight Director made the calls, and the CapCom was the only person who routinely could speak to the astronauts. There was no free for all, no cluttered radio chatter, but rather one voice, and a voice that they could trust.

The CapCom was typically a fellow astronaut, maybe from the backup team, who would have trained alongside the men in space, and who would know what they needed, what they were feeling, and how to convey complex information fast, but with empathy. Sometimes the role of CapCom was to know what not to ask: the astronauts were superb, but not super-human. Sometimes they got tired, annoyed, frustrated, probably even scared. In these times, the CapCom had his finger on the balance of the scales.

If the Flight Director sat at the centre of the web, with CapCom by his side, the lines that radiated out represented each unique function, or specialism, that was needed to launch and retrieve the capsule. Each line, each individual, was referred to by their acronym [5], so to listen to the recordings of the missions is to hear a terse to-and-fro, peppered by the jargon and terminology that enabled efficiency and accuracy in flow.

  • CONTROL was a Lunar Module engineer, with responsibility for propulsion, abort guidance, navigation, and the onboard computers.
  • EECOM was responsible for electrical, environmental, communications, cryogenic, fuel cells, pyrotechnic, and structural systems.
  • FIDO was the flight dynamics officer, who specialised in launch and orbit trajectories (which may dynamically change as issues emerged).
  • FOD was the flight operations director.
  • GNC looked after guidance, navigation, and control systems for altitude, as well as aspects of computer hardware.
  • GUIDO was a specialist in navigation and software.
  • INCO looked after instrumentation, communications, command, and the live television systems for the Command Module, Lunar Module, any Extra Vehicular Activities, and for the Lunar Rover in later missions.
  • PAO was the public affairs officer, whole job was to filter and release information to the press and public.
  • RETRO, the retrofire officer, specialised in the final re-entry trajectories for return.
  • SimSup led the training team, who tested both astronauts, and the entire Mission Control team, to the limit.
  • SPAN, the spacecraft analysis team, could access the broader design and manufacturing teams spread around the country.

It’s worth noting that many of the men who held these positions were in their early twenties, literally making up the rules as they went.

Kranz described how, when he joined the precursor Mercury programme, he was tasked with creating the Mission Rules, and training approaches, which simply did not exist. It was a monumental effort, equal to the technology taking shape in the laboratories, and through a series of conflagrations on the launch pads.

Manned space flight is just that: manned. The men in the capsule, and the men (and very small number of women) in Mission Control and beyond.

From inception, NASA was military in approach, but civilian in operation. Certainly many people fell out of assorted aviation programmes to land at NASA, but when there, they were thrust into new jobs in new disciplines. Apollo was all about learning.

Space Flight is risky, but success does not lie in avoiding, or mitigating, all the risk: it’s typically about understanding how risk flows and, critically, cascades. When does one failure lead to another, and when does it sit in isolation. When is one failure acceptable, and when is it not an option. What is the critical path, and how do we navigate it without the system, freezing up.

Things didn’t start out complex, but they sure as heck got that way in the end, partly because of the mechanisms by which lessons were learnt, and codified.

In 1960, when Kranz was tasked with writing those first Mission Rules, he literally started with a blank sheet of paper. By 1969, when Apollo 11 launched, things had changed: they worked to a 1,700 page launch plan. Similarly, the approach to rockets had evolved, from the early rocket clubs, that took their charges out into a field and lit the fuse, to the Saturn V, which was subjected to every test known to man, and then some. In total, each craft underwent 587,500 forms of inspection through it’s lifecycle [6].

When a lesson was learnt, it was documented, and appropriate procedures captured and codified, and each lesson built upon the last. The effort was additive. By the time Apollo 11 flew, over thirty thousand printed pages were needed to check out the vehicle. Rocco Petrone, the launch operations director, said, “In our testing we had a building block approach, very logical, very methodical; you built each test on the last test, and the whole sequence expanded in the process“ [7].

It’s worth noting that the Saturn V was engineered to tolerate failure: built to an engineering reliability target of 99.9%, a pragmatic recognition that failure is always an option. With six million parts, that meant that at every launch six thousand elements may statistically fail. And still the rocket would fly.

Triple redundancy, and an engineering approach that tried to bypass cascade failures meant that in all thirteen missions that Saturn V flew, not one blew up on the launch pad. A matter of considerable surprise to all involved.

Leadership Reflections

  1. Complexity is engineered, and can be additive. Without the correct webs of sense making, it can be crippling.
  2. Systems are themselves engineered, they do not necessarily operate within a known paradigm. Conversely, extant systems can trap us within known paradigms. The context of Apollo gave explicit permission to bring the best of the old, but create something new.
  3. Creating more noise is easy: filtering, and communicating, effectively, is the hard part.
  4. Failure is always an option, and may be the default state.

Notes

[1] https://en.m.wikipedia.org/wiki/Gene_Kranz

[2] The Manhattan Project [https://en.m.wikipedia.org/wiki/Manhattan_Project] employed an estimated 130,000 people, whilst Apollo is reckoned to have taken over 400,000 [https://en.m.wikipedia.org/wiki/Apollo_program].

[3] To create a safety margin around the Apollo launches, the two launch pads were situated in a remote area, surrounded by marshland, and far from habitation. Even so, had a rocket detonated on the pad, it would have excavated a significant crater. Studies were carried out to ascertain just how large, predominantly to inform the design of the escape system, intended to carry the Comma Module away from the inferno in the event of catastrophic failure. By their own admission, the authors of the final report admitted that much of their work was based on calculated guesses (Day, 2006). In the dynamic context of an exploding rocket, there were just too many variables at play.

[4] Apollo 13, the story told in the Tom Hanks film of the same name, reflected this in great detail: not all problems were solved at once, but rather the most critical for life were solved first, despite not knowing if subsequent issues were solvable at all. One of the most interesting observations is how some factors were just accepted as risk e.g. the SR1 motor that would lift from the moon had no backup, hence no contingency, hence could not be modelled for anything other than a success of failure state.

[5] Definitions and roles derived from Kranz (2000).

[6] Tests included fire, ice, collision, shock, vibration, dust, and rain.

[7] Quoted in Nelson (2010)

Bibliography and further reading

Chaikin, Andrew (1994): A man on the moon: the voyages of the Apollo Astronauts. Penguin, London.

Aldrin, Buzz (2009): ‘Magnificent Desolation: the long journey home from the moon. Bloomsbury, London.

Riles, Christopher, and Dolling, Phil (2009): ‘NASA Mission AS506, Apollo 11, 1969 (including Saturn V, CM-107, SM-107, LM-5), Owners’ Workshop Manual’. Haynes, Somerset.

Woods, David (2016): ‘NASA Saturn V, 1967-1973 (Apollo 4 to Apollo 17 & Skylab), Owner’ Workshop Manual’. Haynes, Somerset.

Morton, Oliver (2019): ‘The Moon’. Profile Books, London.

Lovell, James, and Kluger, Jeffrey (2015): ‘Apollo 13’. Hodder and Stoughton, London.

Mailer, Norman, (2009): ‘Moonfire’. Taschen, Germany.

Muir-Harmony, Teasel and Collins, Michael (2018): ‘A history in 50 objects – Apollo to the moon’. National Geographic, Washington DC.

Day, Dwayne (2006): ‘Saturn’s fury: effects of a Saturn 5 launch pad explosion’. http://www.TheSpaceReview.com (retrieved 23rd July 2019) http://www.thespacereview.com/article/591/1

Kranz, Gene (2000): ‘Failure is not an option: Mission Control from Mercury to Apollo 13 and beyond’. Simon and Schuster, New York.

Nelson, Craig (2010): ‘Rocket Men: the epic story of the first men on the moon’. John Murray, London.

About julianstodd

Author and Founder of Sea Salt Learning. My work explores the Social Age. I’ve written ten books, and over 2,000 articles, and still learning...
This entry was posted in Apollo and tagged , , , , , , , , , , . Bookmark the permalink.

7 Responses to Leadership Reflections from Apollo at 50: Failure, Complexity, and Control

  1. César Awad says:

    Thanks so much Julian for this Leadership reflection around Apollo! It is very fun to read and straight to the point in terms of analysis. There is definitely a lot to learn from these cases including the way they select their leaders and talents.

  2. Pingback: Apollo Leadership Reflections: A Rough Path Leads To The Stars | Julian Stodd's Learning Blog

  3. Pingback: Learning Science: Mapping Learning | Julian Stodd's Learning Blog

  4. Pingback: Trends in Organisational Learning | Julian Stodd's Learning Blog

  5. Pingback: Domain to Dynamic: A New Model of Organisational Design [Pt 1] | Julian Stodd's Learning Blog

  6. Pingback: Blast Off: ‘To the Moon and Back’ – Launching Today | Julian Stodd's Learning Blog

  7. Pingback: The Nature of Leadership | Julian Stodd's Learning Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.