A launch checklist with sixty items is not a safety tool. It is a record of every bad day your team has ever had, and nobody reads it all the way through.
Most product teams build their release checklist the same way. Something goes wrong in production, the retro produces an action item, and the action item becomes a new line on the list. Nobody ever removes a line, because removing one feels like inviting the old failure back. Two years later the checklist is four screens long, the person running it scrolls to the bottom, ticks everything, and ships. The list still exists. The checking stopped a long time ago.
The industries that take checklists most seriously learned this the hard way, and what they concluded is close to the opposite of how most software teams operate.
A short list was the answer to a complicated airplane
On October 30, 1935, Boeing’s Model 299 prototype took off at Wright Field in Ohio during the Army Air Corps bomber evaluation, climbed to a few hundred feet, stalled and crashed. Two of the five men aboard died, including Boeing’s chief test pilot. The Army board traced the crash to an internal control lock that had been left engaged on the elevator. An experienced crew had forgotten one step.
The Air Corps did not respond by writing a thicker manual. It wrote short checklists for four specific moments: takeoff, flight, before landing and after landing. The insight, as that account puts it, was that human memory, not the size of the aircraft, was the limiting factor. The airplane went on to become the B-17.
Notice what the fix was. Not a list of everything a pilot should know. A list of the few things a skilled pilot is most likely to skip, tied to the exact moment they need checking.
Fifty years later aviation was still relearning the second half of that lesson. In August 1987, Northwest Airlines Flight 255 crashed on takeoff from Detroit, killing 154 of the 155 people aboard and two people on the ground. The NTSB’s probable cause was the crew’s failure to use the taxi checklist to confirm the flaps and slats were extended. The checklist existed. The crew skipped it. Afterward, NASA funded Asaf Degani and Earl Wiener to study how normal checklists are actually designed and used, because, remarkably, almost nobody had researched it. Their report treats the non-use and improper use of checklists as a recurring cause of accidents, and it spends real attention on length, format and the production pressure that pushes crews to rush them.
That is the trap your sixty-item launch list is in. The existence of the list is not the control. The use of the list is.
What the surgical checklist got right
The best modern evidence comes from medicine. In 2009 a team led by Alex Haynes published a study of a 19-item surgical safety checklist in the New England Journal of Medicine, run across eight hospitals in eight countries. Inpatient deaths after major surgery fell from 1.5% to 0.8%, and the rate of major complications dropped from 11% to 7%. It was a before-and-after study, not a randomized trial, so read the numbers as a strong association rather than proof. Still, nineteen items moved mortality.
Nineteen items, split across three pause points: before anesthesia, before the incision, and before the patient leaves the room. Each pause covers a handful of checks and takes about a minute. Atul Gawande, who helped design it, later described the craft behind it in The Checklist Manifesto: define a clear pause point, decide whether the list is READ-DO (do each step as you read it) or DO-CONFIRM (work from memory, then stop and confirm), keep each pause short enough to hold in working memory, and cover only the steps that are both critical and easy to miss.
The phrase that matters is “easy to miss.” A good checklist does not teach anyone their job. It assumes competence and guards the specific gaps that competent people fall into under pressure. Surgeons know how to operate. They forget to confirm the patient’s allergies when the room is busy.
Your release checklist is probably a liability log
Run your own launch checklist through those filters and most of it fails.
Items that describe the job rather than the gap. “QA has tested the feature” is not a check. It is the definition of a process step. If QA did not test it, you have a problem a checkbox will not catch.
Items nobody can verify in the moment. “Performance is acceptable” with no threshold or dashboard link gets ticked on faith every time.
Items that apply to one launch in twenty. The checklist line written after the payment integration incident still sits in front of every copy change to a settings page.
Items with no owner. When a list belongs to “the team,” a tick means someone believed someone else did it.
I ran into this pattern in my own operations work. At a large telecom, our change approval checklist for network maintenance windows had grown, incident by incident, into a multi-page form. Every line had a defensible origin story. In practice, the engineers who knew the network best filled it out fastest, which meant they were reading it least. The incidents that still got through were almost never caused by something missing from the form. They were caused by something on the form that had been ticked without being checked. When we finally cut it down, we kept the steps that had actually burned us more than once and that a tired engineer at 2 a.m. would plausibly skip: confirming the rollback path was tested, confirming the customer notification had gone out, and confirming who was on call if the window ran long. Everything else moved into the runbook, where it belonged, as reference rather than ritual.
Google’s site reliability engineers reached a similar place at far larger scale. Their launch coordination team was handling up to 70 launches a week, and within two years their launch checklist “grew long and complex.” The fix was structural. Adding a question required a vice president’s approval. Every item had to be justified, ideally by a previous launch disaster. Someone reviewed the whole list once or twice a year to remove obsolete items, and low-risk launches got a lighter checklist. The governing principle in their own words: “Get the basics right. Don’t plan for every eventuality.”
A vice president’s signature to add a line is a deliberately expensive gate. It forces the question every retro skips: is this failure likely enough, and invisible enough, to deserve sixty seconds from every future launch?
Cutting the list without losing the lessons
If you own a release process, the work is mostly subtraction. Here is the version I would run with a product team this week.
Pull the last year of incidents and near misses. For each checklist item, ask whether it would have caught something on that list. Items that never would have are candidates to cut or move.
Split the list by pause point. A pre-merge check, a pre-release check and a post-release check are three different moments with three different people. One giant list run at the end mixes them and guarantees half of it is answered from memory. The release readiness review is one pause point; the 48 hours after you ship is another, and it deserves its own short list.
Keep each pause to roughly five to nine items. If you cannot get there, you are probably listing tasks instead of checks.
Make every item binary and verifiable. “Error rate on the new endpoint is under 0.5% on the canary dashboard (link)” can be checked. “Monitoring is in place” cannot.
Put a name on each pause, not on the list. One person reads, one person confirms aloud. Aviation does this for a reason: a spoken challenge and response is much harder to skim than a checkbox.
Tier by risk. A feature behind a flag at 1% of traffic does not need the same pause as a pricing change. Google’s lighter low-risk path is a model; so is treating feature flags as something to clean up afterward, not a reason to skip checks before.
Give the list a budget. Decide that it may not grow past a fixed size. Adding an item means retiring one. That single constraint does more than any amount of retro discipline, because it makes every addition a trade.
Move knowledge to the runbook. A lot of checklist bloat is really documentation. Instructions, background and edge cases belong in a reference doc linked from the item, not in the item itself.
The hardest part is cultural rather than procedural. Deleting a checklist line feels like admitting the old incident does not matter. It does matter. The lesson just lives better in a runbook, a test or an automated gate than in a line that the twentieth reader ticks without looking.
If your launch checklist takes longer to read than it does to scroll, the checklist has already failed. Make it short enough that someone actually checks.