The Analog Incident Puppet Closet: Paper Personas That De‑Weaponize Blamestorming After Outages

Outages are stressful. Systems fail, customers yell, leaders want answers, and engineers brace for impact. The meeting that follows—whether you call it a postmortem, incident review, or RCA—can either accelerate learning and resilience, or devolve into a defensive, political blamestorm.

This post introduces a surprisingly low‑tech tool to keep you firmly in the first category: the Analog Incident Puppet Closet—a set of paper personas you literally take off the wall and “speak through” to change how your team talks about failure.

Why Blameless Postmortems Are So Hard in Practice

Many organizations say they run blameless postmortems. Fewer actually do. When an outage hits revenue, the gravitational pull toward “Who messed up?” is strong.

But we know effective postmortems have a different focus:

Identify contributing causes rather than single root causes
Explore what happened, how it happened, and why
Avoid blaming individuals and instead look at systems, processes, incentives, and information flows
Produce concrete learnings and improvements, not just a list of who should “be more careful”

The real blocker isn’t process. It’s psychological safety.

If people fear embarrassment, punishment, reputation damage, or subtle career penalties, they will:

Withhold information
Minimize their role in the incident
Avoid asking "stupid" questions
Over‑index on self‑protection instead of shared learning

Blameless postmortems only work when people feel safe admitting mistakes, uncertainty, and near‑misses. That’s where the puppet closet comes in.

Enter the Puppet Closet: A Low‑Tech Hack for Psychological Safety

The Analog Incident Puppet Closet is a literal or metaphorical box/closet/wall where you keep a set of paper personas—simple, named characters representing real stakeholder perspectives involved in your incidents.

For example:

Ops Olivia – On‑call engineer juggling alerts
Dev Dan – Feature developer under deadline pressure
SRE Sam – Reliability engineer watching SLIs/SLOs
Product Priya – Product manager balancing roadmap and risk
Customer Casey – External user experiencing the impact
Support Samira – Support agent on the front lines of user pain
Exec Eli – Executive who sees dashboards and headlines, not logs

These aren’t cartoons for fun; they are human‑centric tools to:

Make stakeholder needs and pressures visible
Provide safe distance between a real person and the story being told
Shift the conversation from “Why did you do this?” to “What did Olivia experience here?”

Instead of talking directly about you and your mistake, the team can talk through the persona who represents your role and context.

How Personas De‑Weaponize Blamestorming

Personas are widely used in design and product work to keep human needs in focus. The same idea works beautifully in incident analysis.

1. They Refocus on Systems, Not Villains

When you frame an outage through personas, you naturally ask:

What did Ops Olivia see at 03:12?
What information did Dev Dan have when shipping that change?
What pressures was Product Priya under at the time of that decision?

The conversation moves from:

"Alex ignored the runbook."

to:

"Ops Olivia was paging across three services and the runbook was outdated and hard to find. No wonder she missed step 7."

People stop hunting for a guilty party and start seeing interacting conditions: bad visibility, ambiguous ownership, tool friction, misaligned incentives.

2. They Make It Easier to Tell the Whole Truth

It can be scary to say:

"I was exhausted and I skipped a checklist step."

It’s much easier to say:

"In Olivia’s shoes, at hour 19 of an on‑call shift, with three concurrent incidents, it’s highly likely she’d skip non‑obvious checklist steps."

You’re still talking about reality—but through a protective layer that reduces shame. That psychological buffer encourages more honest, detailed storytelling.

3. They Clarify Roles and Expectations

Incidents often expose role confusion:

Who owns communication to customers?
Who decides when to roll back?
Who can escalate to leadership?

By grounding discussion in personas, you can ask:

What does Support Samira believe her responsibility is during an outage?
What does Exec Eli expect from the incident channel?

This helps turn vague frustration into concrete role and task clarification, improving future collaboration.

Building Your Puppet Closet: Creating Useful Personas

You don’t need a UX research department to do this. You can create and validate personas qualitatively using the experience already in your team.

Step 1: Identify Your Stakeholders

List everyone who regularly appears in or is affected by incidents:

On‑call engineers
Developers
SRE / platform teams
Product managers
Support / customer success
Incident commander roles
Security / compliance
Executives

Group them into distinct roles with different perspectives and needs.

Step 2: Co‑Create the Personas

Run a short workshop. For each persona, answer:

Name and short description
Primary goals in an incident (e.g., "restore service quickly," "avoid data loss," "minimize user confusion")
Constraints and pressures (deadlines, on‑call load, KPIs, SLAs)
Information sources (dashboards, logs, Slack, tickets)
Pain points during incidents

Capture this on a one‑page template. Print it. Draw a simple face if you like. Make it physical and visible.

Step 3: Qualitative Validation

Check personas with real people who embody those roles:

Ask: "Does this feel like you? What’s missing or wrong?"
Revise based on their feedback.

Personas don’t need statistical rigor. They need to be recognizable, believable, and relatable so they can support honest conversation.

Using the Puppet Closet in Postmortems

Now integrate the personas into your incident review routine.

1. Start With a Facilitator (External When Possible)

Appoint a facilitator—ideally someone not directly involved in the incident and, when stakes are high, possibly outside the immediate team. Their job:

Keep the focus on what, how, and why, not who
Intervene when language slips into blame
Invite quieter voices into the discussion
Drive toward learning and systemic improvements

At the start, have the facilitator literally open the puppet closet and put the relevant personas on the table or wall.

2. Tell the Story Through Personas

Walk through the timeline and repeatedly ask:

What was Ops Olivia seeing here?
What signals did Dev Dan have?
How did this appear to Customer Casey at that time?
What were Exec Eli’s dashboards showing?

This structure:

Encourages people to reconstruct context instead of judge outcomes
Surfaces where perspectives diverged (e.g., product thought impact was minor; support saw a flood of tickets)

3. Turn Feelings Into Findings

Use personas to translate emotional reactions into system insights:

"Olivia felt panicked" → Alerting was noisy and lacked clear prioritization.
"Samira felt helpless explaining vague status updates" → You need a better comms runbook and clearer ownership.
"Priya felt blindsided" → Improve proactive incident notifications to product.

These become concrete improvement items, not character judgments.

4. Capture Learnings and Commitments

For each major contributing factor, note:

Which personas were affected
What failed them (tooling, process, knowledge, culture)
What change you will make so the persona’s future experience improves

Example:

Ops Olivia: Reduce alert noise and make the runbook link the first line in the alert message.

Support Samira: Provide a canned incident status template within 15 minutes of incident declaration.

Cultural Side‑Effects: Better Than a Process Change

Over time, a few powerful things happen:

Shared Empathy: Engineers understand product’s constraints; product understands on‑call pain; leadership sees the real frontline experience.
Normalized Failure: Discussing mistakes via personas makes it clear that anyone in that context could have done the same thing—reducing shame and personal defensiveness.
Systemic Thinking: The team naturally gravitates toward "How did we set Olivia up to fail?" instead of "Why did Olivia fail us?"
Improved Stakeholder Satisfaction: Because personas keep human needs front and center, your incident process becomes more humane and effective for users, support, and leadership alike.

The result is a postmortem practice that is genuinely blameless, not just branded as such.

Conclusion: Paper Puppets, Serious Learning

Resilient systems depend on resilient learning cultures. Tools, runbooks, and automation matter—but the way we talk about failure matters just as much.

The Analog Incident Puppet Closet is intentionally simple:

A handful of paper personas
A facilitator who commits to blameless inquiry
A structured focus on what, how, and why instead of who

Yet this small ritual can dramatically reduce blamestorming, increase psychological safety, and turn post‑outage conversations into what they should be: honest, systemic explorations that make tomorrow’s incidents rarer and easier to handle.

You don’t need permission to start. Draw your first persona, stick it on the wall before your next incident review, and ask:

"What did this person experience during the outage, and how can we make it better next time?"

That’s how real learning begins.