The most common misread: a checklist doesn't help you remember what you don't know — it guards against skipping what you clearly do know but drop under fatigue, pressure, or distraction. It targets execution failures on known items, not knowledge gaps. A senior surgeon hasn't forgotten how to sterilize; on the 8th case at 2 a.m. they unconsciously skip a step. The checklist converts that step from "by memory" to "by verification."
Non-trivial points: ① Two types — DO-CONFIRM (act from experience, pause at a checkpoint to verify nothing was missed) and READ-DO (read-then-do, like a recipe). Experts use the former, novices the latter; use the wrong type and the checklist gets resented. ② It must be short — 5–9 "killer items" per pause point: steps that are fatal if skipped and most easily forgotten. Cramming in everything you "should" do makes a checklist nobody uses; deleting items is harder and more important than adding them. ③ The hidden function is social, not mnemonic: a checklist creates a legitimate pause that gives lower-status members (a nurse, a junior engineer) permission to say "you missed a step." It's a socio-technical intervention, not a memo.
The WHO Surgical Safety Checklist has just 19 items and 3 pause points (before anesthesia / before incision / before leaving the room). Across eight pilot hospitals worldwide, surgery-related mortality fell by about 47% and complications by a third. The win wasn't new knowledge — it was forcing verification of steps everyone understands but routinely skips in the rush, like confirming everyone has stated their name and role, and that antibiotics were given.
Write a deploy checklist for shipping an AI system: not "be careful," but the few gates that cause incidents when missed and are most easily skipped under deadline pressure — "rollback script verified," "token cost cap set," "prompt version tagged," "sensitive data masked." Keep it under 7 items. It holds at home too: a school-departure checklist by the door shifts the load from "Mom remembers" to "the child verifies" — handing back responsibility and competence at once, which is the social function of checklists in family form.
A normal review is a post-mortem — you investigate the cause of death only after the disaster. A pre-mortem moves the clock forward: assume the project has already failed badly, and have everyone write down why it failed. The same worry, spoken in a different tense, carries entirely different force.
Non-trivial points: ① What it really breaks is conformity pressure. In a normal meeting, saying "I'm worried this will tank" reads as a buzzkill, disloyal, like rooting against the team — so no one says it. The pre-mortem reframes finding failure causes as an officially sanctioned task, even a contest to find the most — flipping dissent from social punishment into social reward. ② The mechanism is prospective hindsight: rewriting "might fail" as "has failed" switches the brain from abstract probability to concrete narrative. Research shows this "it's already settled" framing improves the ability to identify causes of future outcomes by roughly 30%. ③ It's the team-and-time-anchored implementation of inversion (see Day 1) — not just "think backwards," but think backwards with a process, a role, and a time anchor attached.
The method was proposed by decision researcher Gary Klein and championed into the mainstream by Kahneman. The procedure is minimal: at kickoff the facilitator says, "It's a year from now and this project has failed completely — take 2 minutes to independently write every possible cause of death," then everyone reads theirs aloud. It works because independent writing dodges herd effects, and the "already failed" framing finally lets the most senior, most worth-hearing pessimism speak up.
Before launching an AI agent product, run a pre-mortem: "It's six months later and the product is dead — why?" You'll hear the real problems faster than any optimistic pitch deck — "hallucinations destroyed trust," "token costs crushed margins," "users simply won't write prompts." There's a solo version too: before a major architecture choice, write a "eulogy for the architecture everyone hates two years from now." It even mirrors the Buddhist contemplation of death — visualizing the end to force present-day priorities, letting what truly matters surface.
A red team is a group formally assigned to attack your plan, system, or conclusion. The difference from a pre-mortem: the pre-mortem is a one-shot divergence; the red team is a standing, staffed adversarial role.
Non-trivial points: ① The red team's real value isn't "which flaw it found" but that it institutionalizes adversarial thinking — turning "challenging the authoritative conclusion" from an act of personal courage into a job with a mandate and even a KPI, thereby erasing the social cost of dissent. ② It differs fundamentally from a "devil's advocate": the advocate is one person temporarily playing contrarian, and everyone knows "they're just acting," so the opposition goes through the motions. A true red team has structural independence and a genuine incentive to win. ③ The deadliest failure mode is co-optation — if the red team reports to, or wants to please, the blue team, it instantly loses all value. It must be independent, and winning must be rewarded. ④ Acutely current in the LLM era: AI red teaming is now standard in alignment and safety — people deliberately try to jailbreak models or elicit harmful output to expose the gaps in the guardrails.
The Israeli military's "Tenth Man" rule, reportedly born of an intelligence misjudgment in the Yom Kippur War: if nine people reviewing the same intelligence reach the same conclusion, the tenth is obligated to take the opposite view — even purely for the sake of opposition. It uses a forced rule to kill conformity, institutionally guaranteeing that "one voice always attacks the consensus." That is the minimal core of red-team thinking.
Set a red team on your own technical plan: find a colleague not on the project, for whom "finding problems earns praise," to tear apart your architectural assumptions — independence and incentive are both required, or it degenerates into theater. Parenting decisions allow a lightweight version: when the whole family agrees "we should enroll the kid in this class," deliberately assign someone (or yourself) to play a sincere opponent, forcing out "are we just anxiety-driven?" and "is the child's real wish being ignored?" The key is always: dissent must be rewarded, not merely tolerated.
When making a major decision, write down four things: what you expect to happen, your core reasoning, your emotional state at the time, and your confidence level (e.g., "70% sure"). Later, compare against the real outcome.
Non-trivial points: ① It defeats two invisible killers — hindsight bias ("I knew it all along") and outcome bias (inferring decision quality from how it turned out). Without a journal, your brain quietly rewrites the memory of the moment, leaving you a permanent Monday-morning quarterback — so you never learn decision quality, only the emotion of outcomes. The journal freezes the true state at the moment of choice into undeniable evidence. ② Core distinction: a good decision ≠ a good outcome. Under uncertainty you must judge process, not result — a sound 70%-odds bet that loses was still a good decision. The journal is your only data source for separating skill from luck. ③ It's also a training ground for Bayesian calibration (see Day 7): pull out everything you marked "70% sure" and check whether ~70% actually happened — turning vague confidence into a quantifiable, improvable predictive skill. ④ Logging emotion isn't filler: you'll discover you make systematically worse decisions in certain states (tired, offended, rushing).
Bridgewater's Ray Dalio systematically recorded the rationale behind each major decision and reviewed it afterward, gradually distilling reusable "principles." Kahneman likewise stressed that human memory of one's own past judgments is deeply unreliable — only by writing it down in the moment can you later escape the distortion of hindsight and genuinely calibrate your judgment.
Keep a journal for major architecture decisions: "Chose Kafka over RabbitMQ, reasoning X, confidence 65%, was rushing the Q3 deadline and a bit on edge." Six months later: if the outcome is good but the reasoning was all wrong, that's luck — don't learn from it; if the reasoning was right and the outcome bad, the process held — continue. Investment decisions are the same — it cures the dangerous illusion of "I made money so I must understand this." For anyone chasing the "AI super-individual," this is the key infrastructure for turning personal judgment into an iterable system: without a frozen input, there is no trustworthy feedback signal.