Skip to content

Personal Dev Checklists

← Back to all decks

10 cards — 🟢 3 easy | 🟡 4 medium | 🔴 3 hard

🟢 Easy (3)

1. What is the difference between a read-do checklist and a do-confirm checklist?

Show answer A read-do checklist guides you step by step — read each item, then do it before moving on. A do-confirm checklist is used after completing a set of tasks from memory — you then run through the list to confirm nothing was missed. Read-do suits unfamiliar or high-stakes procedures. Do-confirm suits experienced practitioners doing routine work. Using the wrong type causes either frustrating over-guidance or dangerous under-checking.

2. What are Atul Gawande's key principles for effective checklists from The Checklist Manifesto?

Show answer Gawande's principles: (1) keep it short — 5-9 items maximum, targeting critical "killer items" only, (2) use simple, exact language, (3) fit on one page, (4) test in the real world and revise, (5) define a clear pause point (when the checklist is triggered), (6) do not try to spell out everything — a checklist is a safety net for the steps humans most often forget under pressure, not a comprehensive manual.

3. What is poka-yoke and how does it relate to checklist thinking?

Show answer Poka-yoke (Japanese for "mistake-proofing") is designing a process or device so that errors are physically impossible or immediately obvious. Examples: USB-C connectors that cannot be inserted wrong, gas pump nozzles sized to prevent wrong fuel type, form validation that rejects invalid input. It relates to checklist thinking because the best error prevention removes the need for a checklist item entirely — if the error cannot happen, you do not need to check for it.

🟡 Medium (4)

1. What is a forcing function and how does it prevent errors differently than a checklist?

Show answer A forcing function is a design element that requires a specific action before the process can continue — it forces correct behavior rather than reminding you to choose it. Examples: a microwave that stops when the door opens, a deploy pipeline that blocks without passing tests, a car that will not shift out of park without pressing the brake. Unlike checklists (which rely on human compliance), forcing functions make skipping the step impossible. They are stronger than checklists but harder to implement.

2. How does the Swiss cheese model apply specifically to error prevention in processes?

Show answer Each layer of error prevention (training, checklists, peer review, automation, monitoring) has holes — situations where it fails. A checklist missed because of time pressure, a peer review skipped because the reviewer was overloaded, automation that does not cover an edge case. An error reaches the user only when holes in all layers align. The Swiss cheese model applied to error prevention means: never rely on one layer, deliberately vary your defense types, and investigate every near-miss to find which layer's hole was exposed.

3. What are the key design principles for a pre-flight style checklist?

Show answer Pre-flight checklist design principles: (1) define the trigger — what event starts the checklist (e.g., "before every production deploy"), (2) list only critical items whose omission causes real harm, (3) order items logically (by sequence or by system), (4) use binary checkable language ("backup verified" not "think about backups"), (5) include a pause point for team communication if applicable, (6) version the checklist and review it after every incident. A pre-flight checklist is a gate, not a tutorial.

4. Why do stale checklists fail and what maintenance rhythm prevents staleness?

Show answer Stale checklists fail because the process has evolved but the checklist has not — items reference old tools, skip new critical steps, or include items no longer relevant. People stop trusting stale checklists and either skip them entirely or check items mechanically without thinking. Prevention: review the checklist after every incident or near-miss, remove one useless item per review cycle, add any step whose omission caused a recent problem, and assign a human owner responsible for maintenance. A checklist without an owner is already stale.

🔴 Hard (3)

1. How do checklists reduce cognitive load and what is the risk of a checklist that is too long?

Show answer Checklists externalize working memory — instead of holding critical steps in your head while executing, you offload tracking to the list. This frees mental resources for judgment, adaptation, and problem-solving. The risk of a too-long checklist: it becomes a cognitive burden itself, people skim or skip items, important items get lost among trivial ones, and compliance becomes performative rather than protective. The paradox: a checklist meant to reduce cognitive load can increase it if it is not ruthlessly pruned.

2. What does auditability mean for checklists and why does it matter beyond compliance?

Show answer Auditability means the checklist leaves a trace of who completed it, when, and what they found. It matters beyond compliance because: (1) it enables post-incident investigation — you can determine whether the checklist was followed and whether it would have caught the failure, (2) it creates accountability without blame — the trace shows systemic gaps, not just individual errors, (3) it provides data for checklist improvement — patterns in completion rates, skipped items, and failures reveal where the checklist is weak. Without auditability, a checklist is faith-based safety.

3. What is the difference between checklist compliance and actual error prevention, and how do organizations confuse them?

Show answer Checklist compliance means every box was checked. Actual error prevention means the checks were performed with attention and the process caught real problems. Organizations confuse them by: (1) measuring checkbox completion rates as a safety metric, (2) pressuring speed over thoroughness, (3) creating checklists so long that people "pencil-whip" them (check everything without doing anything), (4) treating the checklist as legal protection rather than operational safety. The fix: measure outcomes (error rates, near-miss counts), not just compliance, and keep checklists short enough that real engagement is feasible.