A book in review: Checklist Manifesto by Atul Gawande

A while ago I read The Checklist Manifesto by Atul Gawande. The book was entertaining to read, it conveyed the usefulness (and life-saving potentials) of checklists in a story-driven way, with some much appreciated data sprinkled in to support its message.

The message of the book is that checklists are good. In fact, checklists can save lives, provided their application is in situations where lives may be at stake.

One of the examples given in the book, where checklists have been used, is US Airways Flight 1549 encountering a bird strike shortly after take off, resulting in an emergency landing in the Hudson river.

The movie Sully is a dramatized retelling of the story. The below video shows what the crew did from after the bird strike until the captain decides that they will have to land in the river (spoilers, I guess)

The main thing to note here (for the purposes of this post, at least) is the captain telling the co-pilot to get the QRH - or Quick Reference Handbook.

It’s a bunch of checklists. Basically, each of them answer one question: “What do we need to do when X happens”. The copilot then goes through the book, performing each step - be it confirming some of the things (e.g.: reading on an instrument, position of a throttle), or doing the steps (e.g.: toggling systems, turning on the APU).

The premise of the book is that the same kind of checklists could be introduced elsewhere, primarily in surgical care, to reduce surgical errors that lead to repeat surgeries, infections, or even death.

The main purposes of checklists are that they can be used as a tool to assist in preventing failures. To quote the book itself:

They supply a set of checks to ensure the stupid but critical stuff is not overlooked

To understand where they can be useful, and how, the book also introduces different kinds of problems: Simple, Complicated, and Complex.

Simple problems are basically sets of steps. They are like a recipe. You may not yet have all the required skills to solve the problems, but once you do, there’s a high likelihood that next time you encounter such problems, you’ll succeed in solving them.

Complicated problems are basically sets of simple problems. Like building a car, or flying a rocket to the moon. You can divide the complicated problem into many smaller, simpler problems, and when you complete each and every one of them, you also complete the complicated problem. It’s important to note that, on a high level, complicated problems are also like recipes, just that there’s a couple orders of magnitude more steps than for simple problems. And once you learn how to solve a problem, you can repeat and perfect the process (like sending the 2nd, 3rd, etc rocket to the moon).

Complex problems on the other hand can’t be reduced into a recipe. Raising a child being the example used by the book. Every child is unique - raising one child does not guarantee that raising the next child will go smoother or easier.

These three pretty much encompass everything that life may throw at us. And when it does, we need to be prepared. Checklists are tools that can help us deal with them, if we (or others) took the time to compile them.

When doing a task, and something ultimately goes wrong, you may ultimately reach for a checklist. That’s fair enough for simple and complicated problems - you have steps you can follow, but what about complex problems? Where there’s no recipe, and every situation is unique?

The book brings up two examples of such cases:

1. Building construction, where something unexpected comes up while building out one of the floors
2. A hurricane hits and people are left without food, water, and shelter

In both cases, the book argues that centralizing the control and decision making does not work, and instead both should be pushed to the people on the field with the expertise.

People, being the ultimate problem solvers, will have to apply their expertise, and work together to come to a solution that befits the problem. More so because in such cases, the complexity of the problem tends to exceed the capabilities / expertise of a single human to solve it.

Building a checklist

The book explores two types of checklists:

• DO-CONFIRM: Perform jobs from memory, and use the checklist to confirm that the right things were done the right way
• READ-DO: Carry out the task as they check them off, like a recipe.

Both have their time and place, and when creating one, it’s important to choose the right type.

Other important aspects are to make sure that the checklist is of appropriate size, contains clear, concise, and unambiguous language, and has a clear cut point when it should be applied.

The appropriate size is necessary because humans are lazy, and, given a checklist with too many items, some will inevitable be skipped either by accident or on purpose. Given a checklist with too few items will lead to people not even bothering to pick it up when needed.

As for the language, it is important as each checklist must be clearly understood by each parties to mean the same thing, otherwise it could create more problems than it tries to solve. This may entail profession-specific jargon used to some extent to aid the users.

The cut-point must also be clearly defined, so that people know exactly when to reach for the checklist.

Lastly, checklists must be tested in the real world. As Helmuth von Moltke the Elder stated in 1871 (translated):

No plan of operations extends with certainty beyond the first encounter with the enemy's main strength

Although he was talking about war, the same applies to trying out any of our plans in the real world.

Summary

Overall, I loved the teachings of the book - it’s something I believe we could all learn from. Although I didn’t quite like the presentation of the book, as it sometimes felt like we were taking the scenic route to get to the point, it was still a book that I enjoyed reading, and would recommend to basically everyone.

But wait, there’s more!

Having read the book, and ruminated over it for a couple of months (most of which I spent never even thinking about it, actually), I decided to write a review-ish of it (hint: you’re reading it). On one hand, it’s because my brother did the same, but on the other, I wanted to also start applying what the book teaches, and what better way to do than… to create a checklist.

And so I did. About writing. Which I am arguably horrible at. Now, I’m not expecting the checklist to magically make me write a lot of posts, nor to make the content interesting. Rather, I’m expecting it to distill down all the steps, however stupid they may be, so that I won’t miss any of them when I try to get my grug brain to push words onto the blog.

So let me end it this way - below you’ll find the current state of the checklist for this very post I’m writing, captured as I’m typing out this line.

Until next time,
Dan