Just over a month ago, I read The Checklist Manifesto and I’ve been meaning to write up my thoughts on it ever since. Since I’ve waited so long to write this, I’m going to rely on the notes I typed up one night when I was thinking about this book as well as a another related article that I read along the way.
I first heard about this book a couple of years ago from a review I read in Powell’s now discontinued review-a-day. Based only on the reviews I read and my initial experience developing MediaWiki, I started MediaWiki’s Pre-commit checklist. Last month, when Guillaume Paumier told me he had started reading the book after looking over the checklist, I decided I really should read the book myself.
Atul Gawande wrote the book to write about how worked with the WHO to introduce checklists into the surgery room. He talks about the history of checklists, starting with the pre-flight checklists that were developed after a tragic accident involving an experienced test pilot and a new, more complex, B-17 in 1935.
In each of these situations, you’re dealing with complexity and helping a person with superior domain knowledge avoid silly mistakes.
In the surgery room, this involves empowering nurses and anesthesiologists to call the surgeon out if they see something amiss. Everyone agrees, and even gets the patient to agree to what procedure will actually be performed. Getting surgeons to use these checklists wasn’t easy, but when they did, errors were caught.
The past century (even the past 30 years) has seen great strides in what we can do. Our ability has jumped exponentially. At the same time, the amount of complexity that we have to deal with has grown exponentially. We are only starting to develop are ways to manage the complexity but those who have managed to master some of the it are treated like rock stars. It isn’t uncommon to hear someone use the term “rock star” to refer to a really proficient person. Even they can make mistakes, though, and so we have things like code review where all code written is examined and critiqued by others.
I’m no where close to a rock star programmer, so those code reviews would turn up some of the same things every time. As a result, the checklist was born and has been adopted and maintained by the community since then.
But back to the book. The Checklist Manifesto outlines the successful use of checklists to enable communication between the expert and people around him. This is one the real benefit of checklists. Recognizing that everyone makes mistakes and needs to be open to correction from others that they are working with is one thing that checklists are really good at whether they are used in the cockpit or the surgery room.
Other activities still benefit from cooperation and communication, but as Susan Cain says in her editorial “The Rise of the New Groupthink”, it is dangerous to fetishise cooperation and team work. Her piece ends with this great bit of insight, though:
Before Mr. Wozniak started Apple, he designed calculators at Hewlett-Packard, a job he loved partly because HP made it easy to chat with his colleagues. Every day at 10 a.m. and 2 p.m., management wheeled in doughnuts and coffee, and people could socialize and swap ideas. What distinguished these interactions was how low-key they were. For Mr. Wozniak, collaboration meant the ability to share a doughnut and a brainwave with his laid-back, poorly dressed colleagues — who minded not a whit when he disappeared into his cubicle to get the real work done.
Collaboration is important, but the surgeon still needs to be the one holding the scalpel.