Book Review: The Checklist Manifesto by Atul Gawande
My thoughts on the content of the book summarized into a single blog post.
I got the recommendation to read this book from several different places all at once who did not know each other. I just finished reading it, 2 minutes have maybe passed between putting down the book and writing these words. I have mixed feelings about this, but I want to summarize what I learned from it. I find this book to have very little actual core value, and lots of very entertaining and useful stories that go with the core value. I suppose different people will relate and see this differently, but reading the book I was sometimes frustrated because I wanted it to get to the point!
The point
Checklists are good and can help by removing cognitive stuff from humans. There are a few nuances. Basically the book says there are three different kinds of problems:
- simple, it’s a bunch of steps, easily turned into a checklist, like a recipe
- complicated is a bunch of simple problems, a lot of straightforward individual steps grouped into separate units, like launching a rocket. Most rockets will launch the same, but have a lot of distinct steps, but they are the same
- complex, with unknown unknowns in them, like building a skyscraper and dealing with random problems that come up at random times
Checklists are supposed to enhance work by being a crutch. They should be short, to the point, and unambiguous on what they want to achieve.
When dealing with complex problems, one of the goals is to get all the different people / departments / disciplines present and talking to each other at regular intervals and give them autonomy so decision making is not bottlenecked some levels above in a single point far removed from where the problems actually need solving are.
Checklists are either DO-CONFIRM or READ-DO types. DO-CONFIRMS allow people to complete the tasks separately on their own time, and when the items come up, they confirm they’ve done what was needed. READ-DO types read off the item, then wait until the person completes the task that’s currently being asked of them before moving on to the next item. Different situations need one, others need the other type.
All checklists need to be adapted to the local culture / organization / industry / whatever. A checklist that isn’t getting used is not a good checklist.
Using checklists needs discipline and trust that the checklists actually work and help. Collecting data from before checklist and after checklist is useful, though people tend to have more visceral reasons for not wanting to use them. Some feel that using them makes them look not smart enough, which isn’t something people want to feel.
When writing the checklists, don’t overexplain, and don’t include every single item. There will be items that are rare and low impact, they aren’t needed. There are items that are rare, but critical if gotten wrong, include those. Items that can get lost in the routine or where the consequences are bad if gotten wrong should also be on it.
No checklist works in a team setting if the team isn’t working as a team. A short refocus of at least the team members introducing themselves and a short recap of what they’re about to do and any concerns they have and the role they’re taking on is enough to get them together. The examples were almost exclusively either surgery or flight deck related here.
At the end of the day the role of a checklist is to get people to focus and offload their knowledge from their brains out onto paper / spoken word, so hopefully the collaborative effort can yield better results.
The end.
Photo by Glenn Carstens-Peters on Unsplash