Book Review - The Checklist Manifesto

I was talking with some friends the other day about the state of our industry, as we often do, and someone mentioned various problematic metaphors that people use. In particular, the metaphor that software teams should work like a surgical team led by a surgeon. That led to a book recommendation for The Checklist Manifesto. I picked it up, read through it, and thought I’d share my major takeaways.

In a Nutshell

The book’s author is a surgeon who eventually stumbles on the concept that checklists save lives in his profession, but there are also enough bad examples that he searches numerous industries to find what works and doesn’t.

This search leads him to lead a WHO initiative that has striking results in healthcare, and he even goes so far as to implement the same checklists for his surgeries as well.

What he describes as crucial to the success of checklists are that they need to be short, they need to emphasize communication and teamwork, they need to be clear, and they need refinement.

Short Checklists Win

The bottom line is that a checklist needs to be between 3-9 items. Any more than that, and the brain can’t keep it straight.

The book uses pilots and surgical checklists examples and highlights how useful short checklists are. The author even winds up in a flight simulator where his co-pilot, an airline checklist author, has him through an emergency situation that previously killed people. Using the checklist, he not only successfully flies the plane for the first time but navigates the emergency as well.

To keep checklists short, they need to emphasize the most critical aspects of the situation. Only focus on the things that, if forgotten, are disastrous. Don’t put things that people will do habitually.

Emphasize Communication and Teamwork

At no point in the book does the author encourage or have an example showing where checklists to manage individual performance are helpful. Instead, the author shows time and time again that checklists that promote teamwork and communication are the best ones with stellar results.

Pilots and co-pilots work the checklists together often in a call and response. The surgical checklists involve introductions, reviewing the case and situation, and the ability for people to call out if something gets missed. For construction, there are checklists across the different disciplines for people to review the emerging issues.

The book is clear that checklists that help create teams out of individuals are the way to go.

Clear, Concise, and Refined

The author spends a lot of time describing the airline industry’s meticulous behavior around investigating instances and creating checklists.

The process is straightforward. They investigate a failure, produce a checklist, test it in a simulator, refine it, and continue this testing and refinement until they perfect it.

That perfection comes from attention to every detail in the list, from font choice, size, word choice, and of course, which details are in the list and which they omit.

The lesson I’d encourage here is that good checklists are born through repeated use, testing, and refinement. Checklists created by someone disconnected from the situation don’t work very well. The author experiences this himself with their huge WHO initiative. The checklist he created with the WHO didn’t work at all the first few times they tried it in actual surgeries.

Parting Thoughts

The author is also quick to point out that he felt conflicted the day he brought his checklist to his theater for use. On the one hand, he knew checklists had already saved countless lives, and on the other, his ego told him he didn’t need it.

He did.

He told stories numerous times that the checklist saved people in his surgeries from ineptitude. Not intentional, but details get lost in a rush, and the checklist saved his patients’ lives.

Still, even if one creates a checklist, expect that you will have to go against egos. I’ve seen this first-hand numerous times.

In the software world, we have many opportunities to apply the lessons here. One obvious one is an artifact from Scrum called the Definition of Done. It lends itself well to this checklist treatment, and I’ve used it for years in that capacity. Yet, every time development teams bristle at the idea in the beginning and eventually admit they’d never want to work without it.