Introduction: When Postmortems Disappear into Docs

Most teams treat incidents like paperwork: an outage happens, everyone scrambles, a postmortem is written, a few action items are created—and then everything vanishes into a wiki.

The problem isn’t that we’re not documenting. It’s that the documentation lives in a place nobody looks at unless there’s an audit, a new hire, or another incident. The learning is technically there, but it’s not felt in day‑to‑day work.

What if your incident history wasn’t hidden behind Confluence links, but hanging literally above your heads?

Enter the Analog Incident Story Mobile: a kinetic paper map of failure that turns your outages into a physical, moving sculpture right in your workspace. It’s part art project, part systems diagram, part team ritual—and it can deeply change how your team relates to failure.

What Is an Analog Incident Story Mobile?

An Incident Story Mobile is basically a hanging kinetic sculpture that encodes your incident history using paper, thread, and motion.

Imagine a mobile—like those hanging over a crib—but instead of stars and clouds, it’s composed of:

• Shapes representing incident elements (causes, impacts, mitigations)
• Strings and joints representing relationships (dependencies, timelines, communication paths)
• Layers and movement representing change over time and systemic patterns

Suspended above your team’s area, this mobile becomes a living memory of outages. It’s always there in your peripheral vision, gently moving as the air shifts—reminding everyone that the system is complex, failure is normal, and learning is continuous.

This is not meant to replace digital postmortems. It’s a complementary artifact that brings those learnings into physical space, where they can’t be easily ignored.

Why Make Incidents Physical?

Digital artifacts are easy to store—and just as easy to forget.

A kinetic paper map does something your wiki never will: it turns failure into a tangible, shared, and persistent presence.

1. A Persistent Visual “Memory” of Outages

Hanging the mobile above your team’s workspace creates an ambient memory of what’s gone wrong and what you’ve learned. Unlike a one‑and‑done postmortem meeting, the sculpture:

• Stays visible during planning, standups, and casual conversations
• Creates subtle prompts: “We’ve seen this pattern before—where is it on the mobile?”
• Reinforces that incidents aren’t isolated freak events but part of an evolving story

The mobile turns incidents from events you survived into chapters in an ongoing narrative about your system.

2. Leveraging Hands-On, STEAM-Style Learning

Kinetic sculpture is a classic STEAM (Science, Technology, Engineering, Art, Math) tool because it encourages:

• Exploration: tinkering with balance, motion, and structure
• Systems thinking: understanding how moving one part affects the whole
• Storytelling: encoding narratives in form, color, and motion

Those same qualities are ideal for incident learning. Your team isn’t just reading about failures; they’re:

• Cutting shapes (identifying elements)
• Choosing colors and connections (classifying and relating them)
• Adjusting weights and joints (thinking through interactions and tradeoffs)

The process itself deepens understanding.

Encoding Incidents as Shapes, Connections, and Motion

To make the mobile useful (and not just decorative), you’ll encode key elements of each incident into the sculpture itself.

Here’s one simple encoding scheme you can start with—and adapt later:

Shapes: What Happened?

Use different paper shapes to represent incident components:

• Circles – Primary causes or triggering conditions (e.g., config change, deploy, dependency failure)
• Triangles – Amplifiers or contributing factors (e.g., missing alert, single point of failure)
• Squares/rectangles – Impacts (customer-facing issues, SLO breaches, revenue hits)
• Hexagons – Remediations and long-term fixes

Colors: How Bad, How Frequent?

Color can encode severity or frequency:

• Red gradient – Severity (light red = minor, dark red = severe)
• Blue gradient – Duration
• Patterns (stripes, dots) – Recurring versus one‑off incidents

Connections: How Did It Unfold?

Use strings or threads in different styles:

• Straight lines – Direct causal links (“this caused that”)
• Curved lines – Indirect or systemic influences
• Thicker threads – Strong, well‑understood relationships
• Thinner threads – Suspected or weakly understood connections

Place them along a rough timeline from left to right or top to bottom:

• Earlier incidents on one side, newer on the other
• Newer incidents can hang slightly lower to indicate recency

Motion: What’s Still Changing?

The kinetic aspect is powerful:

• Heavier shapes move less: stable, well-understood parts of the system
• Lighter shapes wobble more: fragile or poorly understood areas
• Clusters that sway together hint at coupled components or recurring patterns

Over time, you might notice:

• A cluster of red circles in one region → reliability hotspot
• Many strings converging on a single shape → a critical dependency
• Repeated shapes and colors across incidents → systemic patterns to prioritize

You’re helping the team literally see patterns in failures that might be buried in text.

Building the Mobile as a Blameless, Collaborative Ritual

How you build the mobile matters as much as the finished object.

Treat construction as a team ritual that reinforces blamelessness and systemic thinking.

Step 1: Gather the Story, Not the Suspects

When translating an incident into the mobile:

• Focus on conditions, interactions, and contexts, not individuals
• Avoid putting people’s names on shapes; use systems, services, or roles instead
• Ask: “What about the system made this outcome likely?” instead of “Who messed up?”

This aligns with modern, blameless postmortem practice and keeps the mobile from becoming a wall of shame.

Step 2: Make It Together

Involve the people who:

• Responded to the incident
• Own affected systems
• Care about reliability and operations

During a short working session:

1. Translate the digital postmortem into shapes and colors
2. Arrange them on a table before committing to strings
3. Discuss and adjust connections together

This collaborative, tactile process helps everyone build a shared mental model of the incident.

Step 3: Embrace Low Fidelity and Change

Use simple, easy-to-change materials:

• Colored paper or index cards
• String, thread, or fishing line
• Tape, clips, or binder rings to allow re‑arranging

Like paper prototyping in UX, the low fidelity invites experimentation:

• It’s okay to be wrong; you can just re‑tape a connection
• You can add new shapes as you learn more
• You can rearrange clusters as your understanding of the system evolves

The artifact stays alive instead of becoming a frozen, perfect diagram.

Keeping It Present: Nudging Better Incident Hygiene

Once your mobile is hanging above the team, it starts to work on your habits—quietly.

Subtle Behavioral Nudges

The constant presence of the mobile can:

• Prompt people to follow through on postmortems (“We can’t add it to the mobile until we write it up.”)
• Encourage better communication hygiene (“Does this incident deserve its own cluster?”)
• Remind the team to pay attention to small failures, not just headline outages

Because all incidents get space on the mobile, you start to see a more equitable distribution of attention. Minor, recurring issues become as visually present as major one‑off failures.

Integrating with Existing Processes

Use the mobile deliberately in existing rituals:

• Weekly ops review: spend 5 minutes adding or adjusting shapes for recent incidents
• Sprint planning: glance at clusters to inform reliability work
• Onboarding: walk new engineers through the mobile as a story of how the system actually fails

Over time, the mobile becomes a shared, evolving map of how your system behaves under stress—and how your team responds.

Practical Tips to Get Started

You don’t need an art degree or a facilities budget. A simple pilot can look like this:

1. Start with 3–5 recent incidents rather than your entire history.
2. Choose a simple encoding legend (shapes for causes/impacts, colors for severity only).
3. Use a lightweight frame (a wooden dowel, coat hanger, or embroidery hoop).
4. Prototype on a wall first with tape, then convert to a hanging version.
5. Document your legend on a small card attached to the mobile.
6. Review and adjust every 2–4 weeks so it stays accurate and useful.

You can always expand the sophistication (more shapes, more dimensions) once the habit sticks.

Conclusion: Turning Failure into Shared, Visible Wisdom

Failures are inevitable; learning from them is optional.

An Analog Incident Story Mobile doesn’t give you new data. What it gives you is a new relationship to the data you already have:

• Incidents become stories, not statistics
• Patterns become visible, not theoretical
• Learning becomes continuous, not confined to a single meeting

By turning your postmortems into a kinetic paper map that hangs above your team, you:

• Make failure a first-class, visible part of your engineering culture
• Reinforce blamelessness and systems thinking through shared making
• Encourage better incident hygiene and more equitable attention across all failures

If your incident learning feels abstract, ephemeral, or ignored, try going analog. Cut some paper, tie some strings, and let your failures move in the air above you.

You may find that the stories you can touch are the ones your team truly remembers—and acts on.