The PowerPoint-Killer

This post by James Thomas struck a chord with me. The post details the loss of the space shuttle Columbia (including 7 humans) in 2006.

The fact is we know that PowerPoint kills. Most often the only victims are our audience’s inspiration and interest. This, however, is the story of a PowerPoint slide that actually helped kill seven people.

• ​What happened
• How was the decision made?
• How was this critical data so badly mis-interpreted?
• The PowerPoint-killer: a simple document
• Real-world example of the triumph of words vs slides

​What happened

The shuttle suffered accidental damage on launch, but made it safely into space. The subsequent tragic loss resulted from the decision to attempt re-entry. The re-entry decision was significantly influenced by the presentation of technical data using PowerPoint, which lead to mis-interpretation of the risks…

At eighty-two seconds into the launch a piece of spray on foam insulation (SOFI) fell from one of the ramps that attached the shuttle to its external fuel tank. As the crew rose at 28,968 kilometres per hour the piece of foam collided with one of the tiles on the outer edge of the shuttle’s left wing… It was impossible to tell from Earth how much damage this foam, falling nine times faster than a fired bullet, would have caused when it collided with the wing… There were a number of options.  The astronauts could perform a spacewalk and visually inspect the hull.  NASA could launch another Space Shuttle to pick the crew up.  Or they could risk re-entry.
​

How was the decision made?

NASA officials sat down with Boeing Corporation engineers who took them through three reports; a total of 28 slides.. The salient point was whilst there was data showing that the tiles on the shuttle wing could tolerate being hit by the foam this was based on test conditions using foam more than 600 times smaller than that that had struck Columbia.

Despite the data showing that the “production fault” was 600x more significant than any previous test “in dev”, NASA felt confident that the data showed there was not enough damage to put the crew’s lives in danger, and went ahead with re-entry.

On re-entry, the wing overheated, the shuttle disintegrated and was lost, along with the lives of all 7 crew.

How was this critical data so badly mis-interpreted?

Edward Tufte, a Professor at Yale University and expert in communication reviewed the slideshow the Boeing engineers had given NASA, in particular the above slide. His findings were tragically profound.

​Read the entire post, or better yet, read Tufte’s full report. To be concise, the way that facts are presented via powerpoint (spacing, font sizing, intendation, titles, etc), and our “powerpoint fatigue” leads us to misleading or lazy conclusions. In this case, the (poor) formatting and presentation of the data led NASA to conclude that the Boeing engineers’s data showed minimal risk on re-entry.

The PowerPoint-killer: a simple document

Jeff Bezos enforces a “no Powerpoint, narrative memos only” rule for Amazon execs (he makes attendees read memos at the start of the meeting). ​

Basecamp has a similar strategy - new ideas must be written down as “pitches”, and given time to percolate.

I enjoy writing (obviously, you’re reading my blog!), and the act of writing and editing helps me to clarify my own thoughts / arguments far more effectively than creating a handful of slides with bullet points would do.

Real-world example of the triumph of words vs slides

I was recently asked to present technical recommendations to a client re how to reduce their AWS bill while improving their database I/O performance. The client specifically prioritised content over presentation. I spent a few days preparing / “percolating” two carefully-structured, technically sound papers detailing my recommendations. The recommendations were supported by calculations in a simple spreadsheet. I delivered the documents to the client a day ahead of our presentation / Q&A session (via video).

All of the Q&A attendees read my documents in preparation for the presentation - we spent about 30 seconds introducing the topic, and jumped directly into a technically deep discussion about the proposed solution, backed by the facts.

In summary, pre-presenting carefully prepared (and internally reviewed) “narrative” technical documents was universally praised by attendees as being “easy for non-technical audience to understand”, and delivering lasting value (since the documents now form the basis of a scope of work).