I first fell for checklists while learning to fly.
Not because they’re clever. Because they’re not. “Fuel: on. Mixture: rich. Flaps: set.” Nothing on the list is something a pilot doesn’t know. That’s exactly the point. The checklist isn’t there for the things you don’t know. It’s there for the things you know so well that you’ve stopped checking them.
Aviation learned this the hard way. On 30 October 1935, the US Army Air Corps put Boeing’s Model 299, the prototype of the B-17, up for a demonstration flight at Wright Field, Ohio. Shortly after take-off the nose pitched up, the aircraft stalled and crashed. Two of the five crew died.
The board of inquiry found nothing wrong with the engines, the structure or the control surfaces. The elevator and rudder were locked.1 The Model 299 was among the first aircraft whose controls could be locked from the cockpit, and nobody had released them. The co-pilot, Lieutenant Donald Putt, later put it simply: they were in a hurry, and “those were the days before the checklists.”2
These weren’t novices. They were highly experienced airmen in an aircraft too new for them to have built the habits it demanded. The Air Corps’ response wasn’t more training or better pilots. It was to order the use of checklists.
What struck me as a student pilot was how quickly you get blasé. Fly the same aircraft a dozen times and your hands start running the checks before your eyes do. The day you skip the card is the day you find out what you’d stopped seeing.
Go / no go
Years later, running product launches, I kept thinking about that card.
Launches fail in boring ways. A feature flag left off. A migration nobody ran in production. Support not told what was shipping. Nobody makes these mistakes because they’re careless; they make them because everyone assumed someone else had it.
So I borrowed from NASA. Before a launch, mission control polls every station: booster, guidance, surgeon, each one answering “go” or “no go” out loud. Mine became Product, Engineering, QA, DevOps, Support. Each owner, in turn, says go or no go.
It sounds theatrical. It works because it removes the assumption. You can’t nod along in a poll. You have to say the word, and if you’re not sure, you say so in front of everyone, which is far cheaper than finding out at 2am.
The first question
Then I worked in healthcare, and the stakes stopped being metaphorical.
The WHO Surgical Safety Checklist begins, before anaesthesia, by confirming the patient’s identity, the site, the procedure and their consent.3 Is this the right person, and are we doing the right thing to the right part of them?
Sit with that for a second. That’s the first item. Someone decided it had to be written down and said out loud, which means it was happening often enough to matter. It’s quietly terrifying.
And it works. In 2008-9 the checklist was trialled at eight hospitals in eight cities, from Seattle and London to Manila and Ifakara in Tanzania. Deaths fell from 1.5% to 0.8%, and complications from 11% to 7%.4 No new technology. A page of questions, said out loud.
Not bureaucracy
Checklists get a bad name because bad ones are bureaucracy: forty items, half irrelevant, ticked from memory afterwards. Good ones share a few traits:
- Short. Only the things that are both critical and easy to skip.
- Owned. Every item has a person, not a department.
- Spoken. Said out loud, at the moment, not ticked later.
- Humble. They assume the expert will forget, because sometimes the expert will.
In the real world, they save lives. In tech, they save the incident nobody needed to have. The dumbest mistakes are the easiest to prevent. You just have to be willing to check.
Sources
- National Museum of the US Air Force, Model 299 Crash (board of inquiry findings, 15 November 1935).
- Schultz, T. P., Where did checklists come from?, Air Combat Command, 2012.
- World Health Organization, Surgical Safety Checklist, 2009.
- Haynes, A. B. et al., A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population, New England Journal of Medicine 360(5):491-9, 2009.