Smart individuals don't add up to a learning organization. A team's real moat isn't who's strongest — it's how fast it turns every mistake into one it won't repeat.
This issue's thesis: The most expensive waste in a big company isn't downtime — it's the same mistake made again by a different person. A key engineer leaves and nobody knows how to deploy the system; a postmortem produces a page of action items that get re-lived next quarter verbatim; the retro degenerates into a going-through-the-motions gripe session. All of it points to one thing — whether your team compounds experience into organizational capability, or lets it walk out with people and evaporate with time. Four foundations this issue: blameless postmortems (learning from failure), institutional memory (knowledge management), single- vs double-loop learning (retro culture), and the step most often missed — closing the loop so a lesson becomes changed behavior.
PRINCIPLE 01
Blameless Postmortems: Fix the System, Not the Person
Blameless Postmortems — Fix the System, Not the Person
learning from failurepostmortemspsychological safety
Principle + Master's Words
The moment a postmortem starts hunting for "who did it," learning stops — because everyone will hide next time. The real question isn't "who pushed the wrong button" but "what made pushing that button both easy and unstopped." People can't be "fixed"; systems and processes can.
"You can't 'fix' people, but you can fix systems and processes to better support people making the right choices."The postmortem chapter's core stance: you don't repair the person, you repair the conditions that made the error likely.— Google, SRE Book, Ch.15 "Postmortem Culture: Learning from Failure"
Scene: The Postmortem After a Production Incident
Situation: A config change took a live service down for 40 minutes. In the review, the junior engineer who made the change stares at the table; the room is silent. As tech lead manager, your first sentence sets the tone.
✗ Hunt for the person (the room freezes)
"Who made this config change? Was it reviewed first? Can we be more careful going forward?" — You think you're just asking about details, but what the room hears is: getting caught means getting named. Next time someone hits a landmine, the first instinct is to cover, not report — and you've buried your most valuable incident data.
✓ Fix the system (unload the shame first, then dig)
Set the tone: "To be clear — this isn't about assigning blame. Anyone, with the same information and tools available at that moment, could have done the same thing. What we're hunting is the system's gap, not the person's."
Then dig: "Why could this config go to full rollout without a second confirmation? Why didn't the canary catch it? If it were me making the change, which step would have stopped me?"
Blameless Postmortem Checklist
In the doc, is the "root cause" a person's name / a lapse, or a system defect (missing validation, missing canary, missing alert)? The former means you haven't dug to the bottom.
Did I explicitly say "no blame here," or leave people to guess? Unspoken, people default to defense.
Does every action item point to "change the system so the error is harder to make," rather than "everyone be more careful"? "Be more careful" isn't an action item — it's a wish.
Common Mistakes
Blameless in words, hunting with your eyes. You say "no blame," but after the review that person gets moved off the core module — the team can read it, and hides again next time. Blamelessness is a behavior, not a slogan.
Stopping at "human error." Those two words are the investigation's start, not its end: why this person made this error, and how much room the system gave them to make it — that's the real answer.
This Week's Exercise + Reflection
Exercise: Pull up a recent postmortem. Classify each "root cause" and "improvement": mark ❌ if it points at a person, ✅ if at a system. If ❌ outnumbers ✅, rewrite — translate each "should have been more careful" into "the system should have stopped it this way."
Reflection: Last time I pressed "who did it," was it really for learning — or for the sense of control that comes from "someone's accountable now"? What's the price of that sense of control?
PRINCIPLE 02
Institutional Memory: Knowledge That Outlives People
Institutional Memory — Knowledge That Outlives People
knowledge managementbus factormake it explicit
Principle + Master's Words
Knowledge that lives only in one person's head isn't an asset — it's a liability: they take sick leave or quit, and the knowledge walks out with them. A manager's job is to keep forcing tacit knowledge into retrievable, explicit records. The metric is bus factor: how many people must be hit by a bus before nobody can run this system? If the answer is 1, that's a red light.
"Tacit knowledge is highly personal. It is hard to formalize and, therefore, difficult to communicate to others."The crux of organizational learning is exactly this: making the personal and hard-to-formalize explicit.— Ikujiro Nonaka, The Knowledge-Creating Company (HBR, 1991)
Where Knowledge Lives: The Lower, The Safer
Scene: The Moment a Key Engineer Resigns
Situation: The only person who truly understands the payment reconciliation system suddenly resigns — gone in two weeks. In their head sit all the system's "gotchas" and conventions.
✗ Last-minute cram (two weeks can't recover three years of tacit knowledge)
"Before you go, patch up the docs and write down everything you know to hand off to the team." — Three years of tacit knowledge can't be recovered by one rushed doc in the final two weeks. And it exposes the real problem: the mechanism you should have built long ago never got built.
✓ Drain it continuously (not only when someone's leaving)
Everyday mechanism: "Starting this month, any system only one person knows gets paired / rotated on-call, with the second person filling in the runbook as they go — not a handoff to anyone, just the team standard."
On the person leaving: "These two weeks, don't write a big comprehensive doc. Do three things: run one real failure drill, record one deployment walkthrough, and list 'the 5 gotchas I most fear you don't know.' Drain the deadliest first; don't chase completeness."
Institutional Memory Checklist
How many systems on my team have bus factor = 1? Can I name them? If not, I'm not even watching this.
Do major technical decisions leave a record of "why we chose this" (ADR / RFC)? Keep only the conclusion, not the reasoning, and in six months nobody dares touch it.
Is writing docs part of the team's everyday rhythm, or forever parked under "when we have time" — and therefore never done?
Common Mistakes
Mistaking "wrote a doc" for "knowledge management." A doc that's unsearchable, unmaintained, and six months stale is worse than none — it gives false safety. Searchable, owned, and updated: that's institutional memory.
Depending on a "hero" while quietly grateful. That "knows-everything, always-on" firefighter is a single point of failure. The more you depend on them, the more it shows you haven't built a system.
This Week's Exercise + Reflection
Exercise: List every critical system on your team and tag each with a bus factor (how many people know it). Pick the one at =1, and this week schedule a pairing session or have a second person start a runbook.
Reflection: Am I also enjoying the irreplaceability of being "the only one who knows X"? How is that sense of safety slowing my own move upward — because I can't take my hands off?
PRINCIPLE 03
Single- vs Double-Loop Learning: Question the Recipe, Not Just the Dish
Single- vs Double-Loop Learning — Question the Recipe, Not Just the Dish
retro culturelearning organizationreflection
Principle + Master's Words
Single-loop learning is "the result was wrong, so tweak the method" — patching this dish. Double-loop learning goes up a level and asks: "What made us assume this was the right thing to do in the first place?" — changing the recipe. Most teams' retros are stuck in single-loop: endlessly optimizing a process that shouldn't exist. Real learning is daring to question the premise that's never been questioned.
"Double-loop learning occurs when error is detected and corrected in ways that involve the modification of an organization's underlying norms, policies, and objectives."Correction that reaches the organization's underlying norms and goals — not just its actions — is where the second loop lives.— Chris Argyris, Organizational Learning (Argyris & Schön, 1978)
Two Kinds of Learning: Which Loop Do You Correct
Scene: The Quarterly Retro, Again Optimizing the Process Nobody Loves
Situation: Every retro, the team complains "the release review is too slow," so every quarter they tweak the review form, add people, change the tooling. Three quarters on, still slow.
✗ Spinning in the single loop (optimizing inside a wrong premise)
"This time let's cut two more columns from the form and add an approver to share the load." — You're making an already-bloated process run slightly faster. The premise — "every release needs a review this heavy" — has never been touched. Next year's retro, you'll be sitting right here.
✓ Move up to the second loop (question the premise)
Push the question up a level: "Before we optimize the process, step back: why does every release go through this heavy review? Is it a scar from one big incident in the past, or does every kind of change genuinely need it?"
Change the recipe: "If 80% of changes are low-risk, the answer may not be 'make review faster' but 'low-risk changes shouldn't go through this review at all' — tiered release. We may have been optimizing something that shouldn't exist."
Double-Loop Learning Checklist
In the retro, are we discussing "how to do this thing better," or do we dare ask "should this thing be done at all"? Only the former = trapped in the single loop.
Is there a "we've always done it this way" rule that no one has asked "why" about in a long time? That's often the doorway to the second loop.
Am I, as leader, precisely the guardian of the "underlying assumption" — some premises are mine, so the team doesn't dare question them?
Common Mistakes
Running the retro as venting or a praise fest. Only griping without change, or only mutual praise without digging, produces no learning. A retro's output is "one concrete method or premise we'll change next time," not a better mood.
Daring only the single loop, because the double one drags out "who set this." Questioning a premise often points at a senior leader or a historical decision — politically uncomfortable — but avoid it and the team patches forever.
This Week's Exercise + Reflection
Exercise: Pick a process the team keeps complaining about yet keeps only tweaking. Write down the "never-questioned premise" behind it, and at the next retro put that premise itself on the table for debate — instead of optimizing the process again.
Reflection: Which rule is "a scar left by one incident"? It made sense back then — does it still today? Are we guarding against risk, or worshipping an outdated totem?
PRINCIPLE 04
Closing the Loop: From Action Item to Actually Changed Behavior
Closing the Loop — From Action Item to Changed Behavior
knowing-doingfollow-throughavoid learning theater
Principle + Master's Words
A postmortem that produces a full page of action items — no owner, no follow-up, re-lived verbatim next quarter — isn't learning; it's learning theater: performing "we're so reflective" while changing no behavior. Knowledge only actually happens when it changes the next action. Writing it down is only knowing; doing it is learning.
"Knowing what needs to be done... too often does not result in action or behavior consistent with that knowledge."This is the fatal gap between knowing and doing.— Pfeffer & Sutton, The Knowing-Doing Gap (2000)
Scene: Last Quarter's Postmortem Conclusion, Re-Lived This Quarter
Situation: You dig into the record and find the root cause of this incident — an identical action item was already written in another postmortem last quarter. It just never got done.
✗ Write it again (theater, encore)
"Okay, this time we really must follow through — I'll record it in the postmortem doc." — You've produced another unclaimed action item. The doc honestly records: you've never actually changed.
✓ Give it an owner, a date, a check (real closure)
Lock the three elements: "An action item only counts with three things — a named owner, a clear due date, and a verifiable definition of done. Without all three, it doesn't go in today."
Build a review mechanism: "Every sprint, spend 5 minutes at the start going over last period's action items; anyone not done says why, out loud. Make 'not followed up' visible — visible, and it gets done."
Closing-the-Loop Checklist
Does every action item have a named owner + due date + a verifiable "what counts as done"? Missing any one, and it probably won't happen.
Is there a standing mechanism to periodically revisit whether last period's action items actually got done? Without a review, what's written defaults to fizzling out.
Is the number of action items so large it can't possibly be finished? A list of 10 you can't finish is worse than 2 you actually close — over-listing is itself not intending to do them.
Common Mistakes + Note for Women
Substituting "record it" for "change behavior." Writing it into a doc brings a false sense of closure, as if the problem is handled. Docs don't change behavior; follow-through does.
Action items grow in number, shrink in completion. An unfinishable list equals no list; better to lock 1–2 and actually close the loop.
Female Leader's Note
Taking retro notes, maintaining the wiki, chasing action-item progress — this "housework of organizational memory" is often defaulted to women (office housework): time-consuming, uncounted as "technical output," and forgotten at promotion time. Two counters: one, rotate the note-taking and follow-up so it's a shared team duty rather than one person's fixed label; two, if you're doing this coordination work, actively name it as your leadership contribution and leave a trail — "I built and ran the team's postmortem follow-up mechanism and cut the repeat-incident rate by X" — instead of letting it fade into "she's just detail-oriented."
This Week's Exercise + Reflection
Exercise: Pull up the last postmortem's action items and check each: does it have an owner? Is it done? Pick one that isn't, and this week fit it with owner + due date + definition of done, and schedule it into the start of the next sprint's review.
Reflection: Of the action items my team writes down, roughly what share actually lands? If it's low, is the problem "didn't think clearly about what to do" or "thought it through but no one drove it"? The two have completely different fixes.
Deeper Questions
Won't blameless postmortems swing to the other extreme — no one's at fault for any error, since "it's the system's problem"?
Yes, and this is a real risk. Blameless doesn't mean no accountability. The fix is Dekker's Just Culture: distinguish an "honest slip" from "reckless / willful." The former is treated impersonally and used to fix the system; the latter still calls for accountability. The dividing line is intent: would a conscientious person in the same conditions have done the same? If yes, it's a system problem; knowingly barreling ahead despite risk is another matter. Blamelessness protects "daring to report," not "exemption from consequences."
Writing docs for knowledge management is costly — won't it slow delivery? How much should actually be captured?
This is a real trade-off; don't pretend otherwise. Principle: rank by "hurts if lost," don't chase completeness. Worth capturing — the "why" of major decisions (ADR, saves future arguments), incident-handling steps (runbook, life-saving), bus-factor-1 systems. Not worth it — implementation details that go stale before you finish, things the code already expresses. Test: would this knowledge badly wound the team if it walked out with a person? If yes, write it. A doc is insurance, not a ritual — buy the coverage you need, don't over-insure everything.
In a high-pressure, deadline-driven big company, isn't this "learning organization" stuff a luxury?
Quite the opposite — the higher the pressure, the more you need it; the form just has to get lighter. No time for an hour-long retro? Use a 5-minute "one thing to keep, one thing to stop from last sprint." No time to write a long doc? Leave one line of "why this change" in the PR description. Learning needn't be a grand ceremony; it can be a micro-habit embedded in the everyday flow. The real luxury is paying the same tuition for the same mistake over and over — that's the cost a high-pressure team can least afford.
How does scale change this? Are the practices the same for a small team and an org of hundreds?
The underlying principles are the same (blameless, make-explicit, double-loop, close-the-loop); the mechanisms differ. Small teams rely on high-frequency informality: spoken retros, pairing, knowledge flowing naturally in dense collaboration, bus-factor risk diluted by everyone touching the code. Large orgs rely on systems and tooling: a cross-team postmortem library, searchable decision records, turning learning into templates and automated checks — because among hundreds, tacit knowledge won't flow on its own; infrastructure must force it explicit. The bigger the scale, the more "findable" beats "someone knows it."