This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
If you’ve been following my CPD reading, you’ll know I often find the most valuable lessons in places you might not expect. Atul Gawande’s The Checklist Manifesto: How To Get Things Right is ostensibly a book about medicine and aviation, but its central argument applies directly to the world of software development. As our systems grow more complex, the question is no longer whether individuals are skilled enough; it’s whether we have the right processes to support those skills.
This book changed how I think about the relationship between expertise and process. It’s not that one replaces the other; it’s that they are most powerful together. Here are the quotes and ideas that resonated most strongly with me as a developer and consultant.
We’ve Outgrown Our Own Brains
Substantial parts of what software designers, financial managers, firefighters, 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.
Gawande doesn’t mince words here, and the phrase “too much airplane for one person to fly” should hit home for anyone working in modern software. Think about the number of things you need to hold in your head when deploying a change: database migrations, feature flags, cache invalidation, downstream service compatibility, monitoring, rollback plans. No one can reliably remember all of it every single time; and that’s perfectly fine. The solution isn’t to be better at remembering; it’s to stop relying on memory alone.
Faulty memory and distraction are a particular danger in what engineers call all-or-none processes: whether running to the store to buy ingredients for a cake, preparing an airplane for takeoff, or evaluating a sick person in the hospital, if you miss just one key thing, you might as well not have made the effort at all.
Deployments, security reviews, and incident response are classic all-or-none processes. Missing a single step in a deployment pipeline can bring down a production system. Forgetting one check in a security audit can leave a vulnerability wide open. These aren’t hypotheticals; they’re the kind of mistakes that happen to experienced professionals every day, not because they lack knowledge, but because they’re human.
Collaboration Over Heroics
In the face of the unknown; the always nagging uncertainty about whether, under complex circumstances, things will really be okay; the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do.
This is code review. This is pair programming. This is the architecture decision record that gets circulated before a big change goes in. The best teams I’ve worked with don’t rely on a single brilliant individual to catch everything; they build systems and cultures where multiple pairs of eyes are the norm. It’s not a lack of trust in any one person; it’s an acknowledgement that complexity demands collective attention.
No, the real reason is that under conditions of true complexity; where the knowledge required exceeds that of any individual and unpredictability reigns; efforts to dictate every step from the centre will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either; that is anarchy. Instead, they require a seemingly contradictory mix of freedom and expectation; expectation to coordinate, for example, and to also measure progress toward common goals.
This is the tension every tech leader navigates daily. Micromanage your team and you’ll stifle innovation and drive away your best people. Give them complete autonomy with no structure and you’ll end up with fragmented systems and duplicated effort. The answer lies in shared expectations: agreed-upon standards, clear communication channels, and yes, checklists that capture the “must dos” while leaving room for professional judgement on the “how.”
The Silent Killer: "That’s Not My Problem"
The more familiar and widely dangerous issue is a kind of silent disengagement, the consequence of specialised technicians sticking narrowly to their domains. "That’s not my problem" is possibly the worst thing people can think, whether they are starting an operation, taxiing an airplane full of passengers down a runway, or building a thousand-foot-tall skyscraper.
In software, this manifests as the backend developer who doesn’t consider the frontend implications of an API change, the infrastructure engineer who doesn’t flag a configuration drift that affects application behaviour, or the product manager who signs off on a feature without considering the operational burden it creates. Checklists that include cross-functional checkpoints (“Has the ops team reviewed this?” or “Have downstream consumers been notified?”) actively combat this kind of silent disengagement. They make shared responsibility explicit rather than assumed.
What Makes a Checklist Work (and What Doesn’t)
Bad checklists are vague and imprecise. They are too long; they are hard to use; they are impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on.
And:
Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything; a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps; the ones that even the highly skilled professionals using them could miss. Good checklists are, above all, practical.
If you’ve ever seen a pull request template with 30 checkboxes that everyone ignores, you’ve seen a bad checklist in the wild. If you’ve seen a deployment runbook that tries to document every possible scenario, you’ve seen another one. Bad checklists are worse than no checklist at all because they breed contempt for the process itself.
Good checklists in software look like this: a concise PR template that asks “Have you tested the unhappy path?” and “Are there migration steps?”; a short incident response card that reminds you to communicate status before diving into debugging; a release checklist that flags the three things most likely to go wrong. They assume competence and supplement it, rather than trying to replace it.
Rethinking What It Means to Be an Expert
We don’t like checklists. They can be painstaking. They’re not much fun. But I don’t think the issue here is mere laziness. There’s something deeper, more visceral going on when people walk away not only from saving lives but from making money. It somehow feels beneath us to use a checklist, an embarrassment. It runs counter to deeply held beliefs about how the truly great among us; those we aspire to be; handle situations of high stakes and complexity. They do not have protocols and checklists. Maybe our idea of heroism needs updating.
This is perhaps the most important passage in the entire book for our industry. There is a deeply ingrained cultural belief in technology that the best developers don’t need process; they just know. The “10x developer” mythology, the lone genius who ships features at midnight, the senior engineer who never needs to look anything up. It’s a seductive narrative, and it’s actively harmful.
Real expertise isn’t about having a perfect memory or never making mistakes. It’s about knowing which mistakes are most likely and building systems to prevent them. The best pilots in the world use checklists. The best surgeons in the world use checklists. There is no reason the best developers shouldn’t do the same.
The fear people have about the idea of adherence to protocol is rigidity. They imagine mindless automatons, heads down in a checklist, incapable of looking out their windshield and coping with the real world in front of them. But what you find, when a checklist is well made, is exactly the opposite. The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with, and lets it rise above to focus on the hard stuff.
This is the insight that should win over even the most checklist-averse developer. A good checklist doesn’t constrain your thinking; it frees it. When you’re not burning mental energy trying to remember whether you updated the changelog, ran the linter, or notified the on-call team, you can focus that energy on the genuinely hard problems: the race condition in the distributed system, the subtle UX issue, the architectural decision that will shape the codebase for years to come.
Accepting Our Fallibility
We are all plagued by failures; by missed subtleties, overlooked knowledge, and outright errors. For the most part, we have imagined that little can be done beyond working harder and harder to catch the problems and clean up after them… They could have decided just to "try harder" or to dismiss a crash as the failings of a "weak" pilot. Instead they chose to accept their fallibilities. They recognised the simplicity and power of using a checklist and so can we.
“Try harder” is not a strategy. “Be more careful” is not a process improvement. When a production incident happens, the right response isn’t to blame the individual who made the mistake; it’s to ask why the system allowed the mistake to happen and what can be done to prevent it in the future. That might be a checklist. It might be automated testing, or a CI/CD gate, or a pre-deployment review. But it starts with accepting that fallibility is human, and building accordingly.
Bringing the Checklist Mindset to Your Team
The Checklist Manifesto isn’t really about checklists. It’s about humility, communication, and the courage to admit that even the most experienced professionals benefit from simple, well-designed processes. In software, where complexity only ever seems to increase, these lessons are more relevant than ever.
Start small. Pick the process that most often goes wrong; maybe it’s deployments, maybe it’s onboarding, maybe it’s incident response. Draft a short, sharp checklist. Keep it to the critical steps that are most easily missed. Get buy-in from the people who will actually use it. Iterate based on their feedback. And resist the temptation to make it comprehensive; the goal is to support expertise, not replace it.
If you’re looking to improve the reliability and consistency of your team’s processes, that’s a conversation worth having. Let’s talk.