Highlights from “The Checklist Manifesto” by Atul Gawande
chestergrant.com
chestergrant.com
In work I've only once (alas) hit the sweet spot of having team members being able and willing to define their own checklist and following and refining it regularly. The results were pretty great (30x efficiency gains on the same procedure in two years). Since, I've noticed quite a lot of professionals being resistant to the idea of checklists. The dogma is that you can't capture skill, experience and intelligence in a checklist. That's a false dichotomy, since the checklist is ment to save you from embarrassing errors, but it's a persistent thought.
Imagine what it will be like to live through the time and actions that you expect, and almost guaranteed, the gotchas will pop out like a sore thumb, and you'll be planning ahead for those.
Wherever I can get to a checklist level, though, I do. Even if it's a list of possible options that I only select a few priorities from each day, it keeps me in mind of the possibilities and things I may be neglecting, etc.
Checklists and point-read-operate are part of my life wherever they can possibly apply. The only things missing are the pips and grease pens.
I would bring up airplanes if someone was skeptical of their effectiveness. Pilots have all of those qualities, and they are responsible for almost six hundred lives (A380) at times.
Pilots are basically legally required to follow checklists.
If using checklists is good enough for the FAA, they're probably good enough for just about anyone.
I find its harder to get people sold on checklists if they've been operating without them for years or decades. It's especially hard when trying to convince 'type A' personalities because it can be perceived at an affront to their ego
These managers wanted to treat engineers as robots and thought these checklists would be the code they fed into other flesh-robots, that then wouldn't need to know anything about what they were doing. Meanwhile the real engineers among us wanted to write actual code that would run on actual computers to do automation and scale instead. But the managers couldn't read code so didn't trust this desire of these engineers and stifled it for a considerably long time. It was a frustrating interpretation of a book I otherwise enjoyed.
That‘s a shame since this exact pitfall is covered in the book when the first list he comes up with for an operating room fails spectacularly because it’s over-detailed. He has to circle back and revisit the checklists used by pilots and realized they only cover the most essential steps. He also discusses the difference between a pilot’s checklist and the checklists used in construction projects and why they have different levels of detail.
Isn't this what things like Ansible/Chef/etc are for? You write the minutiae of certain checklists into code, and the human's checklist item becomes "execute playbook/recipe X".
successful system change requires demonstrating the need for change, engaging institutional leadership, collecting data, and most important, providing training in teamwork so that everyone feels respected and accountable
But in practice, in the realities that we face in non-life-critical jobs, they're oppressive.
Some project managers cling to the fantasy that work will get done in a predictable and orderly fashion if only they wrote down everything that needs to be done and put checkbox next to it (preferably with a target date). The problem is for many projects we don't know what needs to be done in advance or we don't have a deep bench of experienced talent that is able to even generate a realistic checklist.
What often happens with these "checklist project managers" is that they end up creating excessively turgid checklists for which many items are inapplicable to the task at hand, many important items are utterly missing, and there's no prioritization of which things are truly the most critical-- everything's just an identically emphasized line item.
Checklists are for activities which are _extremely_ well understood, practiced exhaustively, and also critical to the mission.
I have spent years refining one checklist. It has completely transformed how I think about that task and how efficiently/often I execute it.
Checklists are appropriate for procedural tasks, or tasks that must be complete before moving on, not directly to R&D. One can might a clock-cycle of R&D with a checklist (Hypothesize, plan, test, analyze, repeat), but if a checklist feels like it is strangling you, it has not yet been sufficiently refined.
That sounds more like a to-do list, rather than a checklist. The way I understand checklist is to have a short (or manageable) and repeatable list of very important items that need to be checked before major events (surgery, software release, flight take off etc). If there are dates next to items and every single tiny item is in the list, then it is a todo list.
Also, checklist aren't just valuable only for high stakes operation. For example, I find use in checklist for ensuring that I have my everyrday carry.. My only problem was that I kept forgetting to use the checklist....
I am talking about checklists devised in a work situation by "a boss" as an integral part of how work is actually preformed.
It's sooo easy for these things to get stupid when they're abused. A checklist, used improperly, is like a pre-waterfall workflow-- almost militaristic in it's simplicity.
He expanded the essay into the book. The book is only okay, because it adds length and a few anecdotes, not all of them convincing, but the best stuff is also in the article.
I’ve read a lot of book abstracts (from getabstract.com) of business or pop science books in about 6 to 20 pages. They really do seem to contain all the pertinent points, but in my experience you read them, nod your head (“that makes sense”), and then the next day have forgotten all about it. Zero retention.
A book, by contrast, is much longer and, yes, repetitive, but also gives context, examples, applications, anecdotes, etc., and in my experience all this seemingly superfluous stuff helps with retention.
But they could probably be, say, 75 pages rather than 250. The problem is that the economics and practices of the publishing industry--and, in all fairness, the expectations of most book buyers--are built around 250-300 page books. So authors end up padding out their 75 page book to 250+ pages.
Philip Greenspun wrote the following in 2003. It was in the context of blogs as an alternative but the reality is that books still carry a certain gravitas that online publishing usually doesn't have.
"Let’s go back to the beginning. The commercial publishing world supports basically two lengths of manuscript: the five-page magazine article, serving as filler among the ads; the 200+-page book. If you had a 20-page idea and didn’t have access to the handful of “long-copy” magazines in the U.S. (old New Yorker, Atlantic, etc.), you could cut it down to a meaningless 5-page magazine piece or add 180 pages of filler until it reached the minimize size to fit into the book distribution system (cf. any diet book or business bestseller)."
I find it works less well when you're just hoovering up a bunch of random content that was perhaps interesting relative to current events and trends but is less so in isolation. Nothing wrong with doing it as a way of archiving past work but it's probably not something that's likely be to the average reader.
In the tech industry I think we can apply the construction company example more appropriately, which was construction companies structuring themselves over the decades for an immediate rescheduling of work and inspections to meet a construction sequence when something came up.
To be blunt and cynical, I don't believe that today's software management styles and scheduling are realistic in that manner. Whatever calendar flexibility exists is covered in name only. So I feel that too often project management decisions serve the calendar instead of allowing field hands to push back on launch dates.
Sometimes leading by example (coworkers seeing positive outcomes) is the best way to gain adoption within your org.
Like all artifacts - things can get stale - maintenance of the checklist needs to be part of the overall group's ongoing tasks.
Generalizing, since then i have consciously tried to force myself to follow/look at the simplest possible technique/explanation/etc. in all my endeavours. Our modern life is so much filled with incidental complexity that 90% of the time a simple approach always works. It has all been done before and we just have to follow established conventions/heuristics.