2026-02-26 · pamad-diamond · Facilitated by Ren Ito
Why do most organizations fail to learn from failure — and what would a genuine learning system look like?
PAMAD Problem phase. The question: why do most organizations fail to learn from failure — and what would a genuine learning system look like? For this phase, I want divergent framings. Not answers yet — just different ways of seeing what the problem actually is. Go outward.
Sixty percent of team performance is set before the team does any work. The same is true of organizational learning from failure. The conditions for learning are set before the failure occurs — and in most organizations, the conditions are hostile. There’s no psychological safety to admit mistakes. The post-mortem is a blame-finding mechanism dressed up as a learning exercise. The team structure rewards individual accountability, which means admitting “I contributed to this failure” is career-threatening. And the coaching — the expert intervention at critical moments — doesn’t exist. Most organizations have no one whose job is to help teams process failure well. They have managers whose job is to prevent failure, which makes them the worst possible facilitators when failure occurs.
I want to translate this into engineering terms. Organizations have no formal failure propagation protocol. When a distributed system fails, there’s a mechanism — error logs, stack traces, monitoring alerts — that propagates failure information to the components that need it. The information is structured, timestamped, and routable. When an organization fails, the “failure information” is unstructured — scattered across people’s memories, meeting notes, Slack threads, and hallway conversations. There’s no schema. No routing. No guarantee that the lessons from a failure in one team reach the team that needs them. Post-mortems are the closest thing to an error log, and most post-mortems are write-only — they’re produced and never read again. An organization without a failure propagation protocol is like a distributed system without logging. Failures happen. Nobody downstream knows.
Both of you are looking at the infrastructure. I’m looking at the person. What job is a post-mortem hired to do? Ask this honestly and the answer is uncomfortable. Most post-mortems aren’t hired to learn. They’re hired to perform learning. The real jobs: demonstrate to leadership that the failure was taken seriously. Assign accountability so that “we’ve addressed it.” Produce a document that can be pointed to when the failure recurs — “we identified this risk, see page 4.” The forces are stacked against genuine learning. Push: something went wrong, we should do something. Pull: we could prevent this if we understood it. But the anxiety — “if we really explore what went wrong, my role in the failure becomes visible” — and the habit — “we always do a post-mortem and then move on” — overwhelm the learning impulse. Failure is a relational event. Admitting failure to your team requires vulnerability. And most organizational cultures punish vulnerability.
Everyone is diagnosing the learning failure as structural or emotional. I’m saying it’s temporal. Organizations fail to learn because their Orient phase is broken. In the OODA loop — Observe, Orient, Decide, Act — the Orient phase is where you update your mental model of reality. It’s the most expensive step. It requires admitting that your current model is wrong, which means experiencing disorientation before you can reorient. Most organizations skip it. They Observe the failure — something went wrong. Then they skip Orient and go straight to Decide and Act — fix the immediate problem, add a check, write a procedure, move on. The mental model that produced the failure is never updated. The orientation is never done. And so the next failure is generated by the same stale model. Learning from failure isn’t an analysis problem. It’s a reorientation problem. And reorientation takes time that organizations won’t invest because it looks like doing nothing.
I want to name what kind of problem this is, because the kind determines which tools apply. Organizations typically treat failures as complicated problems — there’s a root cause, we can find it through analysis, and we can prevent recurrence through a corrective action. Root cause analysis. Fishbone diagrams. Five whys. These are complicated-domain tools. They work for failures that have linear causation. But the interesting failures — the ones organizations most need to learn from — are complex. They have multiple interacting causes that only make sense retrospectively. There’s no single root cause. The “root cause” found by the post-mortem is a retrospective fiction that satisfies the need for narrative coherence. Cynefin says: in complex domains, you can’t analyze your way to understanding. You probe, sense, and respond. But nobody probes a failure. They autopsy it. The tools don’t match the domain.
Five framings. Dara sees hostile conditions. Suri sees absent propagation protocols. Ines sees the gap between the stated job and the real job. Jude sees a broken Orient phase. Lev sees a domain mismatch between tools and problem type. Each is solving a different problem. Hold these. Don’t integrate yet. The Amplify phase will push the tensions further.
Different cast on a different topic produced the same PAMAD Problem-phase pattern: radial communication geometry. Each speaker contributed outward from their framework without responding to each other. Five distinct frames for "why organizations don't learn from failure" emerged. The single-source high-commitment opening pattern held — Dara, Suri, and Jude all opened with declarative positions. Ines (composite) entered more responsively. Lev (composite) entered with a reframe, as usual.
PAMAD Problem phase replicated cleanly. Radial geometry confirmed — same pattern as 003a with entirely different cast. The format's phase structure, not the cast, determines communication geometry. This is the strongest evidence yet for format-shapes-behavior.
Home turf. Opened strong: '60% of learning-from-failure is determined by the conditions set before the failure occurs.' Applied Hackman's team conditions to post-mortem design. The conditions lens on failure-learning is native, not stretched.
Surprising contribution — translated failure-learning to distributed systems: 'organizations have no formal failure propagation protocol.' Likened post-mortems to log files nobody reads. The engineering metaphor was genuinely illuminating, not forced.
In a different cast, with a relevant topic. The demand-side lens activated naturally: 'What job is a post-mortem hired to do? Most post-mortems aren't hired to learn — they're hired to assign blame or to perform the appearance of learning.' Forces model on failure-learning: push (something went wrong), pull (we could prevent this), anxiety (naming my role in the failure), habit (our current post-mortem ritual). Strong Perel activation: 'failure is a relational event — admitting failure to your team is an act of vulnerability, and most organizational cultures punish vulnerability.'
Reframed failure-learning as an OODA problem: 'Organizations fail to learn because their Orient phase is broken — they observe the failure (O) but never update their mental model (O). They skip straight to Decide and Act: fix the immediate problem, move on.' The temporal lens is distinctive — it's about the tempo of reorientation, not the quality of analysis.
Reframed the question as domain confusion: 'Organizations apply complicated-domain tools (root cause analysis, fishbone diagrams) to complex-domain failures (emergent, multi-causal, retrospectively coherent but not predictable). The tools don't work because the problem type doesn't match.' Snowden lens on failure-learning was natural and productive.
Amplify phase — push the tensions further.