In Montreal this summer, while making idle conversation, Paul asked me if I had read anything interesting. Here was my answer…
Five years ago, I met D. Richard Hipp because my friends were thinking of bundling a database he wrote into PHP. Since that time, besides being in the PHP core and thus about 40% of the web servers on the planet, SQLite is in every smartphone, in software such as Firefox, platforms such as Adobe AIR, and operating systems such as Apple Mac OS X. It is used by Oracle and Bloomberg.
I was curious how the unassuming man I met took the new-found fame of his pet software project. This is why, despite my hatred for all things database—they’re boring and talks about them are probably what it feels like to sit through a course on actuarial accounting—I popped into his talk at OSCON.
I was glad I did. It was about, of all things, checklists.
My brother and father are much more responsible than my mom and me. One things that separates them from us was in their methodical use of checklists. Watching his talk reminded me how important they are, how they can be used for so much more than I considered, and how thankful I was that I finally made a packing checklist before going to Portland (and Montreal). 🙂
Read the article, and, if that interests you, buy the book.
With a little imagination, a checklist will change your life.
Notes from the book Checklist Manifesto
– help memory recall
– clearly set out minimum steps necessary
– establish higher standard of baseline performance
Three types of problems
- simple: recipe
- complicated: no set recipe, perfectable
- complex: unanticipated
- central organization fails on complexity (no master builder)
- general organization and direction
- individual autonomy
- communication binds general direction with individual autonomy
- stand up meeting for unanticipated events
- final check by chef/sous-chef
Three requirements for guidelines
- simple : can be systematized
communication in checklist
- “team briefing:
- stand up meeting to voice concerns
- biggest danger is “not my problem”
- fosters teamwork
- “activation phenomenon”
general and specific lists
bad checklists are:
- too long
- hard to use
- made by those with no awareness of the problem space
good checklists are:
- efficient: do not spell everything out, easy to use
why use a checklist
- proven worth
- define pause points for when used
- do-confirm or read-do list?
- not lengthy (guideline: 5-9 items, 50-90 seconds before “shortcutting” occurs)
- simple and exact wording
- fit on one page
- free of clutter, unnecessary colors
- uppercase and lowercase
- sans serif font
- must be tested in the real world
- remove all steps that are always performed (not comprehensive)
- allow for customization
delay in implementing?
- investigate failures then build a checklist
- because knowledge is not translated into simple, usable, systematic form
- collect data before implementing list
- make a list of mistakes then match list of checks to them
who halts and starts a checklist? Answer: not the operator
- too busy, liable to slip up
- sends egalitarian message
the goal is not to check boxes
- promote culture of teamwork
- promote culture of discipline
- improve outcomes with no increase in skill
“Fly the airplane”
Code of professionalism
- expectation of selflessness
- expectation of skill
- expectation of trustworthiness
- discipline (teamwork)
- frequent visitation & refinement of lists
checklists that deal with systems/assemblies
- great component but not enough
- car analogy
2 thoughts on “Notes from Checklist Manifesto”
I’m so bummed that I missed that talk.
Thanks for sharing your notes from the book! The point about starting to create checklists from points of failure is so key. Creating lists of the stuff you get right every time sort of defeats the purpose.
I would love to see what your packing checklist is. Here’s mine (each item on the list inspired by painful failure):
I have a packing list in TaskPaper that changes before each travel.