I'm building a SaaS around creating repeatable checklists (and procedures). Experienced people know how to do their jobs, but they are still people. People are error prone even on a good day. On bad days, well...
Please include a function to print nice looking versions.
My not-for-profit is still quite paper based and when the checklist is online and the paper it relates to is offline the checklist doesn't get used.
It's a fine book. My learning after that book was to try to ask for and read the checklist for medical procedures my family members undergo. At least over here (the Netherlands) they are usually given without problem or even publically accessible online. In case of the chemo of my father, I was able to point to missed steps twice, once needing immediate intervention. In case of simple family disease I can at least understand the reasoning of our GP without totally cross-examining him.
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.
After being in the Weapons Department of a submarine crew, I generally swear by checklists, or a tthe very least, not just a 'let's think about this' session but as close to a walkthrough as I can manage. Vacation planning? Major holiday shopping/preps? New pet? (Other unusual circumstance?)
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.
Always nice seeing a fellow submariner here at HN. :) I feel the same way, though I was in Radio on a fast attack out of Pearl: Checklists are the way to go. Now as a civilian, I'm always extolling the benefits of (regularly updated) checklists to my co-workers.
> The dogma is that you can't capture skill, experience and intelligence in a checklist.
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 think one of the important parts of aviation is that checklists have been embedded in the culture since most pilots first started.
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
I can see how checklists are valuable for extreme high-stakes but routine operations, like surgery or aviation.
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.
Sounds like part of the problem is that checklists aren't being applied properly, given that checklists are constantly refined and adapted as needed to situations.
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....
You can get value from making your own. I have a small list for coding that says "commit, test, story" that reminds me to be always saving my work, coding against a test, and testing against a story. As long as you remember that you're the one in charge and don't treat it like your boss, a list can be a great aid to memory and discipline.
You're right there's a lot of value in writing down what you need to do on a personal level, adapt and modify it to suit yourself and the situation at hand. It's not "your boss" and that's why it helps.
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.
I find checklists useful for an routine and well-defined task, mission-critical or not. Just saves me a lot of headache by making sure I don't forget things. Stress from, e.g., forgetting milk at the store isn't the same as stress from operating on the wrong body part; but it's still an annoyance and easily eliminated--so why not?
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)
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.
Done right, checklists set you free. They set a minimum bar for the completion of a task. You know when you've hit every point that you've considered at least the things you thought were so important that you put them on the checklist.
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.
An important takeaway from the book I got was that distilled checklists didn't work alone. It took some flexibility within the environment using the checklist to allow for its full potency, such as nurses being allowed to second-guess a doctor without fear of reprisals.
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.
It was a fine book, but this summary serves the point perfectly while also being way shorter. My working assumption with all these popular books is they could be half (or less) as long and retain effectiveness.
There are a lot of books that really deserve more than a magazine article or summary. You get context, examples, maybe some history, and so forth.
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)."
In my experience, it works better for relatively timeless self-contained topics. (Or for topics that are interesting in a historical context for whatever reason.)
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.
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.
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 was working at [a large cloud company] a couple of years after this book came out when suddenly all the managers (in my area) started reading it in a very short space of time. They became completely prepossessed by checklists, but IMO totally misunderstood what makes an effective checklist. They turned checklists into an oppressive regime of documenting every conceivable step and path to the tiniest detail. Checklists became impossibly long and far to cumbersome to be useful.
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.
changing practice is not a technical problem that can be solved by ticking off boxes on a checklist but a social problem of human behavior and interaction
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
> They turned checklists into an oppressive regime of documenting every conceivable step and path to the tiniest detail.
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.
> They turned checklists into an oppressive regime of documenting every conceivable step and path to the tiniest 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".
The New Yorker article on which the book was based was a real eye opener for me. That something so simple and so well known could have such dramatic effects in real life was unexpected. It was the magnitude of the effect that was a revelation.
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.
33 comments
[ 4.3 ms ] story [ 76.9 ms ] threadIn 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
https://www.nejm.org/doi/full/10.1056/NEJMe1315851
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".
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.