Things I learned from The Checklist Manifesto

ZZ012EED1E

This post is a summary of things I’ve learned and thought about after reading The Checklist Manifesto, by Atul Gawande. The book was given to me by my father following a conversation we had about how to develop effective operational systems that don’t get in the way of people’s creative, strategic and innovative flow. As you can imagine – we’re the life and soul of any family get together.

Everyone, as we know in the age of Buzzfeed, loves a list (there are some lovely musings that Brainpickings about why we love them so much).  But The Checklist Manifesto advocates using lists as teams in our professional lives. It begins with aircraft crews and surgical teams, types of work where overlooking details can be fatal and yet check-lists haven’t always been, and sometimes –  surprisingly – still aren’t universal.

The three most important things I took away from reading the book were:

  1. The use of checklists dramatically raises effectiveness and reduces errors. This is true even when experts are in charge. This has been proven in surgical medicine and commercial airlines. Mainly this is because of “necessary fallibility” in our complex age – no one person can always remember all the essential steps to do something well. We expect the impossible from ourselves
  2. Checklists are not just lists. They become a way of doing things: an organisational habit. Everyone needs to understand and accept them – including, in some cases partners and contractors (this was stressed in some interesting case studies about communication checklists on large-scale construction projects).
  3. To be effective, checklists need to fulfil a few key criteria. They must be:
    • Concise. Five to nine points per section is recommended in the airline industry.
    • Clear. They need to address a few key points – not every step in the process.
    • Collaborative. Anyone in the team can pause a project/procedure if one is not completed, regardless of seniority. Also, checklists can be improved and iterated after use.

There’s a lot more to the theme – examples from Atul Gawande’s work with the World Health Organisation, the idea’s use in healthcare systems around the world, including the NHS, with the data to back it up – and this is not a book that felt padded out, as many management works do.

It shows how checklists were first used in complex systems during the Second World War, when the first B17 bombers crashed in test-runs, not because they were faulty designs but because in the four or five decades since the invention of flight, these were the first airplanes that were too complex for one person to fly. Essential tasks during take-off would be missed and cause sometimes fatal problems later on.

Gawande says this level complexity is widespread:

Much of our work today has entered its B17 phase. Substantial parts of what software designers, financial managers, fire-fighters, police-officers, lawyers, and most certainly clinicians do are now too complex for them to carry out reliably from memory alone. Multiple fields, in other words, have become too much airplane for one person to fly.

Checklists act as guards against our cognitive biases, he continues:

Four generations after the first aviation checklists went into use, a lesson is emerging: checklists seem to be able to defend anyone, even the experienced, against failure in many more tasks than we realised. They provide a kind of cognitive net. They catch mental flaws inherent in all of us – flaws of memory and attention and thoroughness. And because they do, they raise wide, unexpected possibilities.

It’s an idea we’re using at Brilliant Noise as we develop our operational systems and ways of working. This book is about meeting complex challenges, but it is interesting how everyday processes can be made much more effective with the use of brief checklists – for instance, simple team or project meetings.

Some of us have been experimenting with a checklist to start and end each meeting – purpose, how we’ll be working, how notes and actions will be taken, that sort of thing. It sounds so simple, but when you’re working at pace, it’s easy to start a meeting by diving in to whatever seems most important, rather than checking some essentials – like who is there and why, how we will work and what we want to achieve. These things can seem self-evident and obvious to everyone present – and in fact they are, just in subtly different ways for everyone present. Those subtle differences of perception can lead to avoidable errors and misunderstandings if we don’t catch ourselves early on – hence check-lists.

Checklists are being worked into our emerging processes as the company grows quickly (we’ve doubled each year for the past couple of years) and demands effective ways of working as a larger group. They seem to fit really well – not as prescriptive as heavy-duty ISO-style quality systems that I’ve worked with in the past. Much clearer, lightweight and easy to use.

5 responses to “Things I learned from The Checklist Manifesto”

  1. There’s a danger, here, though – and I’d be interested to know to what degree the book addresses it. Most of the examples you give are processes that are highly complex, frequently repeated and prone to high impact if something goes wrong. Here, a degree of inflexibility is a price well worth paying for the safety that comes with it.

    In a less demanding environment, while I can see them helping protect against some error and cognitive bias, I worry that you also start encoding cognitive bias into them in the long-term, especially as new people arrive and start working to checklists developed before they were ever involved.

    How do you employ them productively without them leading to corporate calcification?

  2. We use several internally. They complement automation quite well, one can’t replace the other, and they must be kept fairly simple. We’ve got a lot more in the pipeline. I’ve not read this particular book, but coming from an Engineering background they’re key. Also, US Airways Flight 1549 landing in the Hudson River is a great example of these being used in flights, and NOT during the takeoff stage. The first officer was going through the checklist of what to do in an emergency when you lose power to both engines, while the pilot was using his gut and his last words were “We’re landing in the Hudson” after having clearance to land at two airports, but realised they had no hope of getting those engines started or reaching the airports, but saw the river. And all survived. So there’s also the way they help you stay calm in a life or death situation.

  3. You raise a sound concern.

    I use two Brilliant Noise values, discipline and curiosity together to make sure checklists and other processes encourage supportive rather than sclerotic behaviours. Discipline is about following the process / checklist you’ve laid out (doing what we say we will, in effect). Curiosity means you should critique the process and propose or try out changes to make it work better.

    I note that in the case studies around aviation and construction in the book, that the checklist approaches are open to challenge by everyone. That’s how it works in my workplace – new joiners are encouraged to challenge and suggest new ways of doing things – as good processes become habits it tends to be either fresh eyes or new challenges that give us the opportunity to change and refine our ways of working.

    I think it is the apparently mundane things that have big aggregate consequences in wasted opportunities and energy – e.g. too many meetings, poorly chaired working groups, unclear objectives or unrecorded actions, miscommunication etc.

  4. Yes, the book covers the Hudson River incident in some detail – you’d find it interesting, Scott.

    And absolutely – simplicity is key.

    It’s interesting also that checklists can help when we feel under threat in non-life-threatening situations. Unfortunately, we get similar kinds of threat responses – adrenaline, cortisol, increased heart rate etc. – to being in a plane that’s crash-landing to when we realise we’ve made massive error in a website build, for instance (where, despite the looks on our faces, no one is likely to die). Checklists don’t always give us the answers, but they can get us out of a flight-fight state and into a more helpfully rational problem-solving mode.

Leave a Reply