The checklist manifesto (Dr. Atul Gawande, 2009)

This book advocates for integrating checklists as potent safety and fault-tolerance tools across diverse domains. Atul Gawande, a prominent surgeon, enriches the narrative with numerous surgery cases to emphasize the effectiveness of checklists in handling intricate tasks.

The surgery cases are graphic. The unemotional, matter-of-fact tone of the audiobook paradoxically intensified the emotional impact for me. Listening to those accounts gave me sweaty palms, and I instinctively clenched myself with pain. The graphic details effectively drive home the point. While listening, I couldn't help but lament that a simple checklist could have caught the mistake, averting all the blood and suffering.

The book also delves into how the aviation industry has successfully embraced checklists to reduce errors and improve communication. Gawande argues that disciplined checklist use in aviation significantly enhances safety and reliability. He details how the aviation industry rigorously operationalizes checklists, vetting them through simulations and real-world tests, ensuring they are brutally succinct, and continually improving them for practicality. This stands in stark contrast to other industries, including medicine and surgery.

Perhaps the early and eager adoption of checklists in aviation, compared to medicine and surgery, stems from pilots having skin in the game. Pilots face the same fate as the plane – assigning blame doesn't change the dire outcome of death due to a mishap. In contrast, surgeons don't share the same fate as patients and can shift blame to other factors (as if that matters).

I loved the focus on the operational aspects of making checklists effective. Gawande resisted strongly against making checklists a top-down mandate. Mandating top-down adoption could have backfired; it needed to be a grassroots effort, allowing teams to adopt and customize checklists to make them their own.

I also loved this point: one of the first items on both flight and surgery checklists is the initial debrief and introduction of team members. Numerous studies highlight the significant positive impact this simple practice has in transforming individuals into a more effective and collaborative team. Don't skip on the basics and the human touch. 

Construction and beyond

The book dedicates a chapter to construction as it builds the case for the widespread benefits of checklists across various domains. Given the complex nature of construction projects (involving numerous tasks and collaborators), construction project management benefits from the use of checklists for enhancing communication and coordination.

I found the connection between checklists and construction not as direct as those in aviation or medicine. The absence of specific, concrete examples of checklists for construction projects left me wanting. While the book provides detailed and concrete checklist examples for medicine, surgery, and aviation, there aren't specific checklist examples for construction. Instead the focus is on scheduling meetings between stakeholders, progress tracking, and finalizing decisions.

Could it be that construction is even more complicated than aviation and surgery due to the involvement of numerous stakeholders, a larger surface area, and extended time/duration?

The discussions on construction project management reminded me strongly of software project management, where the multitude of stakeholders, unknowns, extensive interaction surface, and prolonged time duration make it very complex, that in comparison operating a flight or a surgery seems more manageable.  

While we are on this topic, we can also draw parallels to the DevOps field, particularly through practices like runbooks employed by Site Reliability Engineers (SREs). SREs maintain detailed runbooks that serve as systematic checklists for handling routine maintenance tasks as well as for addressing critical incidents. These runbooks ensure that the on-calls or SREs adhere to a well-defined, step-by-step process when dealing with specific issues or tasks.

The runbooks formulate and capture the operational best practices. Similar to checklists, runbooks enhance communication and reduce error risks. These are often automated using tools/templates like AWS CloudFormation, Terraform, or Google Cloud Deployment Manager for consistent and repeatable infrastructure deployments.


The book leaves me pondering: why did people overlook such a simple yet powerful tool for so long? And when checklists were introduced, why did their widespread adoption take so much time? Dr. Pronovost recognized their life-saving potential in 2001 and piloted them in hospitals. However, it wasn't until 2007 that Gawande, collaborating with WHO, pushed for broader adoption. Gowande also protests about this, and contrasts this with the swift adoption of new drugs or surgical tools showing much less effectiveness.

Effecting behavioral change in humans is evidently challenging. Establishing good habits is not easy. Moreover, adopting checklists demands emotional maturity to acknowledge fallibility and the courage to embrace humility. A machismo effect seems at play too, with many doctors and surgeons resisting checklists, feeling reduced to automatons. However, the reality is that brainpower and attention are finite resources. Why waste them on routine tasks when checklists can handle them? Instead we should free up cognitive resources for more challenging aspects of projects! Checklists can get you more creative, because your bottom line is covered. Well-crafted checklists not only reduce errors and omissions but also enhance communication, leading to efficiency and performance improvements.

Why haven't checklists spread across more domains? Why can't we achieve wider adoption? We should try to mistake-proof routine parts of operations, so we can make progress in tackling complexity in the remaining parts. A colleague I admired once told me that the role of a professor/researcher is to simplify complex things and make them boring.

In summary, the book's message is clear: don't be a cowboy. Being a cowboy isn't heroic; it's foolish. Instead, be humble, be smart.


Popular posts from this blog

Learning about distributed systems: where to start?

Hints for Distributed Systems Design

Foundational distributed systems papers

Metastable failures in the wild

Scalable OLTP in the Cloud: What’s the BIG DEAL?

The end of a myth: Distributed transactions can scale

Always Measure One Level Deeper

Dude, where's my Emacs?

There is plenty of room at the bottom

Know Yourself