The Analog Incident Story Cabinet of Mirrors: A Wall of Paper Reflections for Seeing Your Own Role in Outages

Outages feel chaotic in the moment: pagers going off, charts spiking, executives asking for ETAs. But the real danger isn’t the outage itself. It’s what happens after—when we either learn the wrong lessons, or fail to learn anything at all.

This is where the idea of an “Analog Incident Story Cabinet of Mirrors” comes in. Think of your incident history not as a graveyard of past failures, but as a wall of reflective surfaces—each incident a mirror that shows you something true about your system, your team, and your own role.

Inspired by the Song dynasty’s Comprehensive Mirror in Aid of Governance—a historical chronicle used to help rulers see their own behavior more clearly—we can design our incident practices so they help us govern modern systems with more wisdom and less denial.

This post explores how to:

• Use mirrors as a guiding metaphor for incident learning
• Design reviews as reflections, not blame sessions
• Pair each incident or big decision with a formal challenger role
• Build daily micro‑habits of empathy around incidents
• Use lightweight, continuous reflection mechanisms
• Periodically pause to harvest insights and adjust team goals

Mirrors, Not Mugshots: Rethinking Incident History

The Comprehensive Mirror in Aid of Governance wasn’t written to shame the past; it was written so future leaders could see themselves more clearly. The point of the “mirror” was recognition, not condemnation.

Many organizations treat incident history like a mugshot gallery:

• Tickets are filed, closed, then buried
• Postmortems become compliance artifacts
• People remember “who broke production,” not what the system revealed

A cabinet of mirrors works differently:

• Each incident is recorded as a story, not a crime
• The narrative focuses on conditions, trade‑offs, and surprises, not villains
• The primary question is: “What does this reveal about how we actually operate?”

When teams adopt this mindset, they stop asking “Who messed up?” and start asking “What did this incident reflect back to us about our system and ourselves?”

Design Incident Reviews as Reflections, Not Trials

If you want incidents to function as mirrors, you have to redesign the social ritual of the review.

Shift the purpose statement

Start each review with an explicit framing:

“This review exists to gain insight from history, not to assign punishment or prove we were right.”

Then reinforce it with ground rules:

• No blame language ("Who caused this?" → "What conditions made this likely?")
• Assume competence (everyone did their best with what they knew at the time)
• Focus on narratives, not root‑cause soundbites

Ask reflective questions

Instead of just regression timelines and impact summaries, ask:

• What did we expect would happen here, and what actually surprised us?
• Where did the system behave reasonably, given the signals it had?
• What incentives, pressures, or habits shaped our decisions during the outage?
• What did you personally learn about your own reactions or assumptions?

The goal is to help each person see their own reflection: how they think, where they get tunnel vision, how they respond under stress. That’s far more valuable than another “fixed a config” bullet point.

The Challenger: A Second Mirror for Every Big Decision

Historical rulers used chronicles as mirrors; they also relied on advisors who could challenge their assumptions. We can borrow that pattern.

For every major operational decision (e.g., risky rollout, architecture change) and every significant incident postmortem, assign a formal challenger:

• Someone not directly responsible for the change or incident
• Empowered to question assumptions, logic, and conclusions
• Explicitly protected from retaliation or subtle pressure

What the challenger actually does

The challenger’s job is not to block progress; it’s to sharpen thinking. They might:

• Ask, “What evidence do we have for this conclusion?”
• Probe for alternatives: “What other explanations fit these observations?”
• Surface blind spots: “Who is affected by this that we haven’t talked to?”
• Challenge groupthink: “If we discovered in a month that this was wrong, what would we wish we had asked today?”

By design, the challenger acts as a second mirror: not just reflecting what happened, but reflecting how the team is making sense of what happened.

Make the Challenger Role Formal, Not Symbolic

If the challenger isn’t formally empowered, the role will quietly dissolve under:

• Hierarchy (“We don’t have time for this; leadership already decided.”)
• Time pressure (“We’ll skip the challenge this once; the release is urgent.”)
• Social discomfort (“I don’t want to seem difficult.”)

To prevent that, treat the challenger like you treat on‑call rotations:

• Document the role: responsibilities, authority, and limits
• Maintain a rotation calendar: who is challenger for which decisions/incidents
• Give them meeting time and agenda space to do their work
• Make it procedurally hard to skip: a decision isn’t “done” until the challenger has had their say

Importantly, “having their say” doesn’t mean they always win. It means their questions must be seriously engaged and explicitly answered, not brushed aside.

When this becomes routine, challenge stops feeling like confrontation and starts feeling like craftsmanship.

Micro‑Habits of Empathy During Incidents

Mirrors can be harsh. To keep reflection from turning into shame, you need a counterweight: everyday empathy.

You don’t build an empathetic culture only in the postmortem meeting; you build it in small, continuous gestures:

• In incident chat, say: “How’s everyone holding up? Anyone need a quick break?”
• Offer help unprompted: “I can take notes or handle comms if you want to focus on debugging.”
• After a long night, send a brief check‑in: “Yesterday was rough. Anything you wish had gone differently that we can fix?”
• Normalize rest: “You’ve been on this for hours—let’s hand off or pause.”

These micro‑habits do two things:

1. They reduce the emotional cost of acknowledging mistakes or confusion.
2. They send a clear signal: you are more important than this outage.

Only when people feel safe and valued will they truly use the mirrors you’re building.

Lightweight, Ongoing Reflection: A Living Cabinet of Mirrors

Formal postmortems are necessary, but they’re too infrequent to capture the constant flow of small learnings. To normalize continuous learning, add lightweight reflection channels.

One simple pattern: a shared incident‑learnings chat thread or lightweight doc.

How it works:

• Anyone can post a brief learning after an incident or near‑miss:
  • “Learned: our dashboard doesn’t show partial failures; we only saw full outage.”
  • “Realized I always assume DNS is fine—we should add quick DNS checks to runbook.”
• No format policing: a few sentences or bullet points are enough
• Reactions and follow‑ups are optional, not required

The key is low friction. You’re building a paper wall of reflections—short stories, moments, and realizations that accumulate over time.

Later, you can mine this wall for patterns:

• What keeps surprising us?
• What personal habits or assumptions show up again and again?

This turns learning from a rare event into a background process.

Periodic Pauses: Harvesting Insights and Updating Goals

Even with daily micro‑reflections, you still need periodic, deliberate pauses—weekly or monthly—to make meaning at a higher level.

Run a short team session with two focuses:

1. Personal insights

   • Ask everyone to share: “What’s one thing you learned about how you work in incidents this month?”
   • Examples:
     • “I get stuck in one hypothesis for too long.”
     • “I hesitate to ask for help when leadership is present.”
     • “I forget to update stakeholders when I’m deep in logs.”

2. Goal updates

   • Translate insights into small, concrete goals:
     • “Next incident, I’ll explicitly list 3 possible causes before diving deep.”
     • “We’ll add a 15‑minute stakeholder update cadence to the incident runbook.”
     • “I’ll ask for a buddy when I’m primary during a high‑stakes outage.”

Capture these goals somewhere visible. Your cabinet of mirrors shouldn’t just reflect; it should reorient you.

Bringing It All Together

A modern Analog Incident Story Cabinet of Mirrors isn’t a physical wall of scrolls, but the analogy holds:

• Every incident is a story, not just a metric
• Reviews function as mirrors, not trials
• Challengers ensure you question your own narratives
• Empathy makes honest reflection emotionally sustainable
• Lightweight, ongoing reflection keeps learning alive between big events
• Regular pauses help you harvest insights and adjust your course

Outages will never be pleasant, but they can be profoundly useful—if you design your culture to look squarely into the mirrors they offer.

The choice is whether you treat incidents as isolated fires to extinguish, or as a living archive of reflections that help you see your system—and yourself—more clearly over time.