← Back to Patterns
Life commons-engineer Vitality: 4

Failure Disclosure

Also known as: Sharing Failures, Learning from Mistakes, Transparent Post-mortems

Sharing what didn't work as openly as what did — the practice that separates credible practitioners from performers. Failure is data.

To build what is durable, we must be willing to show where the cracks were.

[!NOTE] Confidence Rating: ★★★ (High) This rating reflects our confidence that this pattern is a good and correct solution to the stated problem.


Section 1: Context (100-200 words)

You are part of a team or community striving to build something of lasting value. The energy is high, the vision is compelling, and progress feels like a series of successful forward leaps. In this environment, the narrative of success becomes a powerful current, carrying everyone along. Setbacks, missteps, and outright failures feel like eddies—unwanted diversions from the main flow. The pressure to maintain momentum, to project an image of unwavering competence, is immense. It feels safer to bury the dead experiments quietly, to patch the cracks and paint over them, hoping no one will notice. The system you are a part of is a young forest, reaching for the sun. Every tree appears strong and vital, but some are growing on unstable ground, their roots shallow. The ecosystem has not yet learned to communicate these hidden weaknesses, creating a fragile illusion of uniform strength.

Section 2: Problem (100-200 words)

The core conflict is Perfectionism vs. Progress.

This drive for a flawless public image creates a dangerous feedback loop. When failures are hidden, the system cannot learn from them. The same mistakes are repeated in different parts of the ecosystem, wasting precious energy and resources. A culture of fear takes root; individuals become performers, curating their successes and hiding their struggles. This erodes trust and makes genuine collaboration impossible. The system becomes brittle, unable to adapt because it is blind to its own weaknesses. The primary tension is between the desire to present a perfect, unblemished exterior and the messy, iterative reality of all meaningful progress. It’s the individual’s fear of being judged for a misstep versus the collective’s need for the data that misstep provides. The organism, in its attempt to appear invincible, is slowly starving itself of the nutrients required for growth.

Section 3: Solution (200-400 words)

Therefore, you must treat failure as a gift of data, and institutionalize its disclosure as a core practice of credibility.

This means creating the structures and safety to share what went wrong as openly as what went right. Failure Disclosure is not about celebrating failure for its own sake, but about metabolizing it into fuel for the system’s evolution. The core mechanism is a shift in perspective: from failure as a mark of personal inadequacy to failure as an impersonal signal from reality. It is an indicator that a mental model was flawed, an assumption was incorrect, or a process was weak. By externalizing the failure, you depersonalize it. The practice involves creating a formal, blameless process for dissecting failures—often called a post-mortem, an after-action review, or a retrospective. This process is not a tribunal; it is a diagnostic clinic. The goal is not to assign blame but to extract the maximum amount of learning. This transforms the toxic energy of shame and fear into the productive energy of curiosity and improvement. It makes the system smarter, more resilient, and ultimately, more alive.

Section 4: Implementation (300-500 words)

Cultivating a practice of Failure Disclosure requires deliberate, careful gardening. It is not a switch you flip, but a new species of interaction you introduce into your ecosystem.

  1. Create a Safe Container: The first step is to establish psychological safety. This begins with leadership. Leaders must be the first to share their own failures, demonstrating that vulnerability is not only acceptable but expected. Frame the process explicitly as blameless. The prime directive of a retrospective is often a good starting point: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

  2. Define the Trigger: Establish a clear, low-friction process for initiating a failure review. Don’t wait for a catastrophe. Define thresholds for what constitutes a “failure” worthy of review. This could be a missed deadline, a bug that reached production, a marketing campaign that flopped, or even a feature that shipped but saw no adoption. The smaller the failure you can learn from, the faster the system adapts.

  3. Structure the Debrief: A structured format ensures the conversation stays productive. A common model includes:

    • What did we expect to happen? (Revisit the original hypothesis)
    • What actually happened? (State the objective facts, using data where possible)
    • Why was there a difference? (This is the core of the analysis. Use techniques like the “5 Whys” to get to root causes, focusing on systems and processes, not people.)
    • What will we do differently next time? (Generate concrete, actionable follow-up items. Assign owners and timelines.)
  4. Document and Share the Harvest: The learnings from a failure review are valuable assets. Document the outcome in a simple, accessible format. Share it widely. This is the “disclosure” part of the pattern. Create a public, internal repository of these learnings—a library of hard-won wisdom. This act of sharing is what turns an isolated mistake into collective intelligence. It signals to the entire organization that the goal is not to avoid failure, but to learn from it faster than anyone else.

  5. Celebrate the Learning: Acknowledge and reward the act of disclosing and learning from failure. This closes the loop and reinforces the new cultural norm. When a team conducts a thorough and honest post-mortem, celebrate their courage and the value of the insights they’ve generated. This transforms the fear of failure into the pursuit of resilience.

Section 5: Consequences (200-300 words)

Adopting Failure Disclosure fundamentally rewires a system’s capacity for life. The most immediate consequence is a dramatic acceleration in learning and adaptation. The system’s metabolism speeds up; it processes reality more efficiently, converting the raw material of experience—both good and bad—into structural improvements. This creates a powerful compounding effect on credibility. Practitioners and teams who openly share their failures are perceived as more trustworthy and competent, not less. Their confidence is grounded in a robust process of self-correction, not a fragile ego.

However, this practice is not without its costs. It demands a significant investment in psychological safety and requires real courage from participants. In environments where blame is the default currency, attempting to implement Failure Disclosure can be dangerous for the individuals who go first. It can be weaponized by those who still operate in a paradigm of perfectionism and fear. Furthermore, a poorly facilitated process can devolve into a ritual of shame or a performative exercise that generates no real learning. The decay of this pattern looks like “blameless” post-mortems that still implicitly assign blame, or a growing graveyard of unread failure reports. The living expression of this pattern is a palpable sense of curiosity and resilience, where the question “What can we learn from this?” becomes a natural, reflexive response to any setback.

Section 6: Known Uses (200-300 words)

One of the most well-known and mature implementations of this pattern can be found in the tech industry’s DevOps culture, particularly at companies like Etsy. They pioneered the practice of “blameless post-mortems.” When a system outage or significant error occurred, the focus was never on the individual who made the mistake. Instead, the process was treated as a scientific inquiry into the systemic conditions that allowed the error to happen. By rigorously documenting the timeline, the contributing factors, and the technical and process-based remedies, they built a vast, shared library of resilience. This practice allowed them to deploy code hundreds of times a day with confidence, knowing they had a robust immune system for dealing with the inevitable failures that come with complexity and speed.

A second, high-stakes example comes from the world of aviation. The entire global aviation safety system is built on a foundation of Failure Disclosure. After every incident, agencies like the National Transportation Safety Board (NTSB) in the United States conduct an exhaustive investigation. Their purpose is not to punish pilots but to understand the precise sequence of events—mechanical, human, and environmental—that led to the failure. The resulting reports are public, detailed, and become required reading for pilots, manufacturers, and air traffic controllers. This systematic, non-punitive approach to learning from failure is a primary reason why air travel is one of the safest forms of transportation in the world. The ecosystem of aviation has learned to treat every crash as a priceless lesson, ensuring the same mistake is rarely made twice.

Section 7: Cognitive Era (150-250 words)

In the Cognitive Era, as we increasingly partner with AI, autonomous agents, and distributed intelligence, the pattern of Failure Disclosure becomes even more critical. These non-human agents will operate at a scale and speed that makes their reasoning opaque to us. When an autonomous system fails, we cannot simply ask it what it was thinking. The core conflict shifts from “Perfectionism vs. Progress” to “Opacity vs. Insight.”

Therefore, we must design these systems with Failure Disclosure built into their very architecture. An AI agent should be programmed to automatically generate a detailed post-mortem of its own failed processes. This ‘digital after-action review’ would include the data it used, the models it activated, the confidence scores of its predictions, and the chain of inferences that led to the erroneous outcome. Our role as Commons Engineers will be to design the protocols and standards for these automated disclosures. We will become the stewards of machine learning, cultivating ecosystems where both human and artificial intelligence can learn from error transparently. The vitality of our shared cognitive future depends on our ability to debug not just code, but cognition itself.

Section 8: Vitality (200-300 words)

What does vitality look like? It looks like a team that responds to a major outage not with panic and finger-pointing, but with a calm, focused curiosity. It’s the sound of a project lead saying, “This is fantastic. We just found a major flaw in our assumptions before it became catastrophic. Let’s dig in.” Vitality is present when junior members of a community feel safe enough to say, “I think I made a mistake,” and are met with gratitude for their honesty. Signs of life include a well-tended, frequently visited internal wiki of post-mortems, where past failures are referenced as valuable case studies. It’s a culture where the question “What was our last big failure and what did we learn?” has an immediate and insightful answer from anyone on the team.

What does decay look like? Decay is the silence that follows a visible setback. It’s the hushed, private conversations and the search for a scapegoat. It’s the project manager who buries the red metrics in a footnote, or the team that celebrates shipping a feature while ignoring the data that shows no one is using it. Decay is the presence of “organizational scar tissue”—unspoken rules and avoidant behaviors that grow around past, unresolved failures. A system in decay punishes messengers and rewards performers. The ultimate sign of decay is brittleness: the inability to withstand the slightest shock, because the system has lost its capacity to learn and adapt through the open processing of its own mistakes.