On October 30, 1935, the Army Air Corps gathered at Wright Field in Ohio to watch the future of aviation take off. The Boeing Model 299, the prototype that would become the B-17, was faster, carried more, and flew farther than anything the Army had seen. It climbed a few hundred feet, stalled, rolled, and crashed. Two experienced pilots died, including Boeing’s own chief test pilot.
The investigation found no mechanical fault. The crew had simply forgotten to release a lock that held the elevator and rudder in place on the ground. As Atul Gawande recounts the episode in his 2007 New Yorker piece “The Checklist”, the verdict at the time was that the new bomber was “too much airplane for one man to fly.” The obvious fix was more training. Nobody was better trained than the man who died at the controls.
So the Air Corps did something else. Rather than pile more hours onto already expert pilots, they wrote a short list of the steps a crew had to confirm before takeoff, before landing, and after. As Air & Space Forces Magazine documents, that list, not additional instruction, is what let the plane fly safely. The B-17 went on to fly 1.8 million miles without a serious accident of that kind.
That is the uncomfortable lesson for anyone running a team. The work that fails is rarely the hard, novel, once-a-year work everyone treats with care. It is the routine work your best people know cold.
Competence hides the failure, it does not remove it
Here is what makes this counterintuitive. We assume errors come from ignorance, so we treat them with knowledge: train harder, hire smarter, explain more. That works for problems of ignorance. It does almost nothing for problems of attention.
The pilots at Wright Field knew about the control lock. They knew it the way you know your own phone number. That is precisely why they missed it. When a task is deeply familiar, your brain stops allocating conscious attention to it and runs it on autopilot, which is efficient right up until the one time the autopilot skips a step and nothing in your head flags the gap. The more expert you are, the more of your work runs this way, and the less you can feel it happening.
I watched a version of this play out for years running operations at a large enterprise telecom. The maintenance windows that went wrong were almost never the exotic ones. Those got a bridge call, a runbook, three senior people watching. The incidents came from the routine change a competent engineer had done fifty times and did on muscle memory the fifty-first, skipping the one verification step that mattered because nothing in the moment told him he had skipped it. Knowledge was not the missing ingredient. He had the knowledge. He had a lapse of attention on work too familiar to command any.
The evidence is not subtle
If this were only a story about airplanes, you could file it under “safety-critical work, not my job.” Then medicine tested the same idea, and the numbers are hard to argue with.
In 2009, a team led by Gawande published a study in the New England Journal of Medicine on a nineteen-item surgical safety checklist tested across eight hospitals worldwide, from Tanzania to Seattle. After the checklist was introduced, the rate of death fell from 1.5 percent to 0.8 percent, and inpatient complications dropped from 11 percent to 7 percent. A better than one-third reduction in complications, from a one-page list of things everyone in the room already knew to do.
A few years earlier, Peter Pronovost had tested a five-step checklist for inserting central lines in intensive care units across Michigan. The steps were things every clinician knew: wash your hands, clean the skin, use full sterile barriers. The infection rate dropped by 66 percent, and over the project’s span the state’s ICUs were credited with saving more than 1,500 lives and roughly 175 million dollars. A later ten-year analysis found the gains held.
None of this happened because the checklist taught anyone something new. It worked because it caught the moments when trained, capable, busy people skipped a step they knew perfectly well, under exactly the load your team operates under every day.
Why your best people will resist it
If checklists are this effective and this cheap, why does almost nobody on your team want one?
Because a checklist feels like an accusation. To a skilled person, being handed a list of steps reads as a statement that you are not trusted to do your own job, that management thinks you might forget how to do the thing you have done a thousand times. The reaction is not irrational. It is a status reflex, and it is the single biggest reason good checklists die in a drawer.
The way past it is to change what the checklist is a comment on. A good checklist is not a comment on whether you are smart. It is a comment on the fact that human attention is unreliable under load, and yours is no exception, and neither is mine. Surgeons resisted the WHO checklist hard at first, and the ones who came around were often the ones who caught themselves, personally, about to skip a step the list stopped them from skipping. You are not protecting your team from their incompetence. You are protecting good work from the predictable ways attention fails.
That reframe only lands if the checklist is genuinely good, which is where most teams get it wrong.
Two kinds of lists, and managers reach for the wrong one
Gawande draws a distinction worth stealing. There are two kinds of checklists, and they are used at different moments.
A read-do list works like a recipe. You read a step, you do it, you read the next. This is for complex, high-stakes, infrequent work where the order matters and nobody has it memorized: a database failover, a year-end close, spinning up a new client’s environment for the first time. You want the list driving the work in real time.
A do-confirm list works differently. The team does the work from memory and experience, the way experts should, and then stops at a defined moment to confirm out loud that the critical steps actually happened. This is for routine work that competent people already know how to do. You are not walking them through it. You are catching the one skipped step before it becomes an incident.
Most teams build read-do lists for everything, then wonder why senior people ignore them. A step-by-step recipe for work an expert does daily is insulting and slow, so it gets routed around, and the routing-around becomes the new normal. For familiar work, you almost always want do-confirm: a short pause at a defined point, a handful of items, said aloud.
What actually belongs on the list
The failure mode after “we should use checklists” is a forty-item document nobody reads. The whole value collapses if the list is long enough to feel like paperwork. The research and the aviation practice converge on the same discipline: keep it to the killer items, roughly five to nine, the critical steps most often skipped and most costly when they are. Not every step. The vital few.
Two questions decide whether something earns a checklist at all:
- Is it high-stakes and infrequent? The consequences of a miss are large, and you do it rarely enough that nobody has it truly memorized. Disaster recovery, offboarding a departing employee’s access, a production deploy after a long freeze.
- Is it routine but expensive when a step is skipped? You do it constantly, competence is not the issue, but the occasional skipped step costs real money or trust. Client onboarding, incident handoffs between shifts, closing a change ticket.
Work that is neither, the genuinely novel problem you are solving for the first time, does not want a checklist. It wants judgment. Checklists protect the parts of the work you have already figured out so your team’s attention is free for the parts you have not. That is the point people miss: the list is not there to make your team think less. It is there so they can spend their thinking where thinking actually helps. This is the same logic behind cutting the repetitive work that quietly drains a team’s capacity, and it is a direct hedge against the single-owner risk of knowledge that lives in one person’s head.
Building one your team won’t route around
A checklist that gets ignored is worse than none, because it creates the illusion of a control that is not actually operating. A few things separate the lists that stick from the ones that die.
Draft it from real failures, not from imagination. The best source material is your own post-incident notes. What step actually got skipped last time something went sideways? That belongs on the list. A checklist assembled from “everything that could theoretically go wrong” is long, generic, and dead on arrival.
Cut it until it hurts, then cut once more. If it does not fit on one screen and cannot be run in under a minute, it is too long and will be abandoned. Every item you add to protect against a rare edge case dilutes attention on the items that matter. Ruthless subtraction is the skill here.
Name the pause point. A checklist with no defined moment to run it does not get run. “Before you hit deploy.” “At shift handoff.” “Before the client goes live.” The trigger has to be unambiguous, or the list becomes optional, and optional means invisible.
Give it to the team to own, not to enforce. The version imposed from above gets tolerated. The version a team builds from its own scar tissue gets used, because they wrote it, they believe every line, and they will defend it. Your job as the manager is to insist that a checklist exists and to protect the pause point, not to author every item yourself. This is the same reason the processes you write get ignored while the ones your team shapes get followed.
Revise it when it fails. A checklist is a living record of how your team fails. When something slips past it, the answer is not to abandon the list. It is to ask what item was missing and add it. Aviation’s checklists are still being edited ninety years later.
The point was never the list
The instinct, when a capable team keeps making the same small preventable mistakes, is to question the people. Retrain them, watch them closer, wonder if they are the right hires. Almost always, the people are fine. What is missing is a cheap, unglamorous control that catches the predictable ways good attention fails on familiar work.
The pilots who died in 1935 did not need to be better pilots. The surgeons in that 2009 study were not bad surgeons. In both cases the fix cost almost nothing and worked anyway, because it was aimed at the real problem: not what your team does not know, but what they know so well they have stopped seeing it.