The Checklist Manifesto, or Why Smart People Still Forget Things

When someone joined Square, Jack Dorsey used to take the new employee on a walk through San Francisco and explain his vision for the company. The welcome package waiting for them included a Square reader, a Field Notes notebook, a small card describing the company's four principles, and a mysterious red book.

The principles were known as the Four Corners of Square:

We start small. We collaborate in commons. We round the square. We craft the entire span in a breathtaking way.

The red book was always the same: The Checklist Manifesto: How to Get Things Right, by Atul Gawande. Reports about Square’s onboarding described both the walks and the welcome kit, including the copy of Gawande’s book. As soon as I learned about this, I bought the Kindle edition. My reasoning was impeccable: if the founder of Square gave the same book to every employee, there was a reasonable chance it contained something more useful than the average corporate welcome document, where “move fast” is usually followed by a twelve-step approval process. A few seconds later, I was reading it.

We usually know what to do

Atul Gawande is an American surgeon and writer. In the book, he makes an important distinction between two kinds of failure. The first comes from ignorance. We fail because we do not know enough. The necessary knowledge does not exist, is unavailable to us, or has not yet been discovered. The second comes from ineptitude. We possess the knowledge, but fail to apply it correctly. That word sounds harsher than it needs to. Gawande is not saying that everyone making these mistakes is incompetent. He is describing a much more uncomfortable problem: capable, experienced people can know exactly what needs to be done and still skip a critical step.

A surgeon can forget to confirm a patient’s allergy. A pilot can overlook a control. An engineer can deploy to production without checking the database migration. A product team can release a feature without verifying whether analytics events are actually being recorded.

The knowledge exists. The people involved may have performed the task hundreds of times. Nobody woke up that morning with a plan to cause a disaster. Something was simply missed. This is the category of error that worries me most because experience does not eliminate it. In some cases, experience makes it easier to believe that the checklist is unnecessary. You have done this before. You know the system. You remember the sequence. You are also answering a message, thinking about the next meeting, and wondering why the deployment script has begun printing something in red. Nothing to worry about, surely.

Complexity defeated memory

Modern work often exceeds what a single person can reliably keep in their head. This is not an insult to human intelligence. It is a consequence of complexity. A software release may involve code changes, infrastructure, database migrations, feature flags, monitoring, security, communications, backups, rollback plans, and several services maintained by people who are currently asleep in another time zone. Every individual step may be simple. The complete system is not. The more experienced the team becomes, the more tempting it is to perform the process from memory. Nobody wants to be the senior engineer reading a list that says:

• Confirm the backup exists.
• Verify the migration.
• Check the health metrics.
• Test the rollback procedure.

It feels embarrassingly basic. That is precisely why it works. The checklist does not exist to explain the job. It exists to protect the job from memory, interruption, stress, and confidence. A checklist is not a replacement for expertise. Someone who has never flown an airplane cannot become a pilot by finding the correct PDF. Someone who has never operated a production system should not receive root credentials and an encouraging laminated card. Expertise tells you how to perform the work. The checklist makes sure you remember to perform the important parts.

Checklists are older than they look

When I first read the book, I came away with the impression that formal checklists were a surprisingly recent invention. That needs clarification. People have used lists and written instructions for a very long time. What became especially important during the twentieth century was the formal operational checklist, designed to help trained professionals manage increasingly complicated systems. One famous aviation example followed the 1935 crash of Boeing’s Model 299. The aircraft was more complex than previous planes, and investigators concluded that the experienced pilot had left a critical control engaged. Boeing’s test pilots responded by developing a checklist for takeoff, landing, and other phases of flight.

The lesson was not that pilots lacked training. The lesson was that the machine had become too complicated for memory alone. Software crossed that line a long time ago. We continue pretending otherwise because our machines do not usually fall out of the sky. They fail more discreetly. A payment stops processing, a queue grows silently, a backup has not worked for three months, or a configuration file is overwritten by someone who believed they were connected to staging.

Nobody dies, which is good. Everyone spends the weekend on a video call, which is less good.

A checklist is not a procedure manual

One of the strengths of Gawande’s book is that it does not pretend a checklist should contain every instruction required to perform a task. That would be a manual. A checklist must be short enough to use and specific enough to catch the steps most likely to be missed. It should focus on what Gawande calls the “killer items,” the details that are essential but vulnerable to being forgotten. This distinction is important.

I have seen checklists that became internal documentation projects. The author began with ten verification points and ended with a small novel involving every possible state of the system. Nobody used it. The team still claimed to have a checklist, in much the same way that owning exercise equipment technically counts as having an exercise plan. A useful checklist does not explain every command. It identifies the moments when the team must stop and verify something.

Before the deployment:

Is the backup complete?

Has the migration been tested?

Is the rollback procedure available?

During the deployment:

Are errors increasing?

Are response times changing?

Are the workers processing jobs correctly?

After the deployment:

Has the critical user flow been tested?

Are the dashboards healthy?

Did someone remember to turn off the temporary feature flag?

The precise items depend on the system. The principle does not. The list should be short, clear, and connected to real failure modes.

The difficult part is discipline

Gawande argues that successful teams need more than skill and good intentions. They need discipline. This is where checklists become uncomfortable. Most professionals do not object to the idea of avoiding mistakes. They object to the small ritual that makes avoidance possible. Reading the list feels slow. Confirming each item feels bureaucratic. Asking another experienced person to verify something can feel insulting. The team is under pressure, the change is urgent, and everyone already knows what to do. This particular release is special. We can skip the process just this once.

Production incidents often begin with the phrase “just this once.” Discipline is difficult because it is repetitive. There is no novelty in confirming the same five things every Friday. Nobody receives applause for verifying that the backup works. The reward is that nothing dramatic happens. This makes operational discipline difficult to sell. Companies celebrate launches, growth, redesigns, and heroic recoveries. They rarely celebrate the engineer who prevented the incident by quietly following a process.

Preventing a disaster produces no screenshot. Heroically repairing one produces a very impressive incident report. Given enough time, organizations can accidentally build cultures where causing a crisis and fixing it looks more valuable than avoiding the crisis in the first place.

A checklist pushes in the opposite direction. It makes boring reliability repeatable. Boring is underrated.

It also improves communication

The surgical checklist developed through Gawande’s work with the World Health Organization did more than remind people to verify equipment or medication. It created specific moments when the surgical team had to stop and communicate. Before the procedure, team members confirmed the patient, the operation, and anticipated risks. They introduced themselves and made sure critical information was shared.

That may sound almost too simple to matter. In a 2009 international study, implementation of the 19-item checklist was associated with complications falling from 11 percent to 7 percent and inpatient mortality falling from 1.5 percent to 0.8 percent. Those results were important, but they should not be turned into magic.

Later research involving mandatory implementation across Ontario did not find the same significant improvements. A checklist can support better work, but merely placing one in the room does not guarantee that the team will use it properly or that the surrounding culture will change. Software teams should understand this distinction. Adding a checkbox to Jira does not create discipline.

A checklist is useful when it interrupts the process at the correct moment, makes responsibility visible, and forces the team to exchange information that might otherwise remain inside someone’s head. For a production release, this might mean naming the person responsible for the deployment, confirming who is monitoring the system, and agreeing on the conditions that will trigger a rollback. Without that conversation, everyone may assume someone else is watching. The application goes down. Six people are present. All six are waiting for one of the other five to do something. Excellent collaboration.

My own checklists are boring text files

The book did not give me a ready-made checklist for deploying software, maintaining servers, or shipping a mobile application. That is not what it is for. It explains why checklists work, what makes them fail, and how they can bring discipline to complex tasks. The actual list must come from the work itself. After reading it, I began creating my own. I did not buy a specialized application. I did not establish a Checklist Transformation Committee. I created a folder containing a few text files. Each file covers a task I perform regularly and do not want to perform carelessly. Some have ten items. Others have fifteen. I open the relevant file, follow it, and close it when the work is complete. That is all.

The format is not important. A plain text file works. Paper works. A shared document works. The checklist only needs to be available at the moment it is required and simple enough that people will actually use it. The effect has been practical. I work faster because I do not have to reconstruct the process every time. I make fewer avoidable mistakes. I spend less energy wondering whether I forgot something. Most importantly, the list absorbs part of the anxiety.

There is a difference between thinking, “I probably remembered everything,” and knowing that you completed the same verified process used the last twenty times. The first is confidence. The second is evidence.

Write checklists from failures

The best source for a checklist is often a previous mistake. Whenever something goes wrong, ask whether a simple verification could prevent the same failure from happening again. If the answer is yes, add it to the list. This is not about creating a line item for every possible failure. A checklist that grows without limit eventually becomes another system nobody can operate. It is about identifying recurring, expensive, or dangerous mistakes.

Perhaps the team repeatedly forgets to update a configuration value. Perhaps deployments happen without checking available disk space. Perhaps nobody confirms that scheduled jobs are still running afterward. Perhaps releases are announced before the application is actually available in the store. These are good checklist items because they represent known weaknesses in the process. A postmortem should produce more than an explanation. It should improve the system. Otherwise, the team has not learned from the failure. It has merely documented it beautifully.

Checklists protect competent people

Some people still see checklists as tools for beginners or fools. That attitude usually lasts until they forget something expensive. The checklist is not an admission that you lack intelligence. It is an admission that intelligence is not available in unlimited quantities, under all conditions, without interruption. We become tired. We rush. We assume. We are distracted. We skip the obvious step because it is obvious. Then the obvious step brings the system down.

A good checklist protects competent people from the predictable weaknesses of competent people. It gives teams a small amount of structure when the work becomes complex, stressful, or routine enough to invite carelessness. That is why I recommend The Checklist Manifesto. It is not a book about making lists. It is a book about accepting that knowing the correct thing is not enough. We need a method that helps us do it consistently, especially when we are busy, confident, or convinced that this time the process is unnecessary.

You do not need special software. You do not need an expensive framework. Start with a text file. Write down the ten things that must not be forgotten. Then, and this is the surprisingly difficult part, read it.