Does this hold?
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?
Act phase. The Mine phase gave us a cleaner frame: complicated failures and complex failures need different learning systems. Now I need concrete answers. What does the learning system actually look like? What happens Monday morning?
The first thing that happens Monday morning is you set the conditions before the failure discussion begins. Four concrete checks. First: is there someone in the room who isn’t responsible for the failure? You need at least one person whose identity isn’t at stake. Second: is blame explicitly off the table? Not as a cultural aspiration — as a stated rule for this specific meeting. Third: is the outcome of this discussion protected? Meaning: can the learning from this discussion survive a management review that wants someone punished? Fourth: is there a coach? Someone whose job is to facilitate the failure discussion, not to manage the team or the project. Set these four conditions before you open the conversation. If any condition is missing, you’ll get performance, not learning.
I want to propose the technical architecture. A failure event schema — structured, machine-readable, timestamped. Every incident produces a failure event with: what happened, what was expected, what the impact was, what domain it sits in (Lev’s complicated/complex classification), and what was done about it. These events flow into a failure monitoring system that does pattern matching across teams and time. When the same “root cause” appears in three incidents across different teams, the system surfaces: “this isn’t a root cause, this is a systemic condition.” When correlated failures appear in teams that don’t communicate, the system surfaces the correlation. The human read the monitoring output and decide what requires reorientation. The system does the pattern detection that humans are bad at. Humans do the sensemaking that systems are bad at.
Before either of those: the Orient checkpoint. A mandatory structured pause between failure detection and failure response. Not a meeting — a question. The question is: “is this a failure within our current model, or a failure of our current model?” If within — tactical failure — use Dara’s conditions and Suri’s schema and do a standard post-mortem. If of — strategic failure — stop. Don’t post-mortem. Don’t fix. The model itself needs updating, and that’s a different process. A longer process. The Orient checkpoint prevents the default — treating every failure as tactical, finding a “root cause,” adding a check, moving on.
I want to add the human layer. Jude’s Orient checkpoint asks “is this tactical or strategic?” That’s a judgment call, and it’s a threatening one. Classifying a failure as strategic — “our model is wrong” — is more career-threatening than classifying it as tactical — “we made a mistake.” The system needs to make it safe to call a failure strategic. One mechanism: the classification is anonymous. The team votes on tactical vs. strategic before anyone’s name is attached. If the majority says strategic, the reorientation process activates. If tactical, standard post-mortem. The anonymity protects the person who sees the deeper failure from being the one who named it.
The domain-triage step should be first. Before Dara’s conditions, before Jude’s checkpoint, before Suri’s schema. The first question: what kind of problem is this? Is the failure complicated — linear causation, findable root cause, fixable with better procedures? Or is the failure complex — interacting causes, emergent behavior, retrospectively coherent but not predictable? The answer determines the entire pathway. Complicated failures get root-cause analysis, corrective actions, Suri’s event schema. Complex failures get Jude’s Orient checkpoint, Ines’s anonymous classification, and a different kind of investigation — one that doesn’t promise a root cause and doesn’t pretend the answer is simple. One pathway for each domain. The organizational learning system needs two tracks, not one.
Two tracks. I can work with that. The conditions apply to both, but the conditions change. Complicated-track conditions: technical facilitator, structured analysis, corrective action output. Complex-track conditions: process facilitator (someone trained in ambiguity tolerance), open-ended exploration, the output is a reoriented model, not a corrective action. The team charter for each track is different. The complicated track says: “find what went wrong and fix it.” The complex track says: “understand how our model of this system is wrong and update it.” Two different jobs. Two different team designs.
The monitoring system serves both tracks. For the complicated track: pattern detection, recurring failures, correlated incidents. Automated and efficient. For the complex track: the monitoring surfaces anomalies — failures that don’t match known patterns, unusual correlations, growing frequency in areas that were previously stable. These are the signals that something complex is happening. The system can’t diagnose it — that’s the human Orient phase. But it can flag it.
The Act-phase deliverable is taking shape. A dual-track failure learning system:
Domain triage → conditions check (Dara) → standard post-mortem with failure event schema (Suri) → root-cause analysis → corrective action → monitoring for recurrence.
Domain triage → Orient checkpoint (Jude) → anonymous classification (Ines) → conditions check (Dara, different conditions) → open-ended investigation → reoriented model as output → monitoring for anomalies.
Suri’s monitoring system. When complicated-track failures recur despite corrective actions, the monitoring surfaces the pattern. That’s the signal to reclassify: “this isn’t a complicated failure with a bad fix. It’s a complex failure that was miscategorized.” The failure moves to Track 2.
Does this hold?
It holds. The Orient checkpoint is the branching point, and Ines’s anonymous classification protects the person who names the harder truth. The system has a mechanism for detecting strategic failures and a protected pathway for processing them.
It holds. The conditions are specific to each track, which addresses my Mine-phase correction — conditions are necessary but what they look like depends on the failure type.
Act phase communication geometry shifted to transactional — convergent, concrete, add/modify items. Same pattern as 003d. Lev was notably quieter in the Act phase than in any other phase. Not silent — he contributed once, framing the domain-triage mechanism — but his output dropped from the most active speaker in Problem/Mine to the least active in Act. This is the second instance of Lev's Act-phase quietness (also observed in 003d). The pattern is consistent: Lev's inquiry-structure lens contributes heavily in divergent and rigor phases, less in pragmatic phases. Appropriate specialization, not range limitation.
PAMAD Act replicated. Transactional geometry confirmed. The Act phase's demand for pragmatism changed which speakers dominated — Dara and Suri, who think in concrete systems, took over. Lev and Ines, who think in abstractions, contributed less. Phase- casting effects hold: the phase structure redistributes influence.
Dominated the Act phase. Proposed the team-conditions checklist for post-mortems: four concrete conditions to set before any post-mortem begins. The conditions lens translated directly to actionable recommendations. Home turf advantage in a pragmatic phase.
Proposed the technical architecture for failure monitoring — event schema, pattern matching, cross-team visibility. The most concrete proposal in the session. Engineering lens produces actionable output naturally in Act phase.
Less dominant in Act than in Amplify. Contributed the 'warm learning / cold learning' distinction as a design choice: decide which failures get which treatment. The demand-side lens translated: 'what job is this failure being hired to teach?'
Proposed the Orient checkpoint — a structured pause between failure detection and response that forces the 'is this tactical or strategic?' question. Concrete and actionable. The Boyd framework produces a specific intervention in the Act phase.
Quietest phase. One major contribution: the domain-triage step that should precede any failure response — 'is this complicated or complex?' — which determines which tools apply. Then largely quiet as others built concrete proposals. Second instance of Lev Act-phase quietness (also 003d). Pattern: the inquiry lens contributes to framing, less to action items. This appears to be appropriate specialization rather than limitation.
Distill phase — compressed epitaphs.