The Analog Incident Story Ferris Wheel: Rotating Perspectives Through a Single Outage

Incidents feel chaotic when you’re inside them—and strangely flat when you read the post-incident report afterward. Timelines, metrics, and root causes are necessary, but they often miss the lived experience: who felt what, when; how decisions actually got made; where communication really broke down.

Enter the Analog Incident Story Ferris Wheel: a simple, repeatable activity that rotates your team through the same outage from multiple perspectives—engineer, customer, leadership, support, and more. Instead of asking, “What went wrong?” you ask, “What did this look and feel like from every seat on the ride?”

Used as part of a Post-Incident Review (PIR), the ferris wheel turns one painful incident into a durable source of learning, empathy, and reliability improvements.

Why a Ferris Wheel?

A ferris wheel is the perfect metaphor for a single outage:

Same structure, different view: Everyone is on the same ride (the incident), but what you see depends on your seat (role).
Rotating perspectives: You can’t see the whole picture from one seat; you need to rotate and compare views.
Predictable ritual: The ride has a known start, loop, and stop—just like a good post-incident process.

Most teams already have technical rituals—incident timelines, metric reviews, root cause analysis. The ferris wheel adds a social-emotional and perspective-taking layer to those rituals, helping teams:

Build empathy across roles
Improve communication protocols
Clarify decision-making responsibilities
Reduce repeated mistakes by understanding not just what happened, but how it felt and why people acted as they did

How the Incident Ferris Wheel Fits Into a Post-Incident Review

Think of your PIR in three parts:

Facts & Signals – What happened? When? What did systems show us?
Decisions & Flows – Who did what? Based on which information and constraints?
Perspectives & Impact – How did different roles experience the same events?

The ferris wheel lives in part 3, but informs parts 1 and 2. You still do a normal post-incident review (timeline, impact, causes). Then you:

Pick a single outage to analyze
Choose 4–6 key roles (seats on the ferris wheel)
Walk through the incident from each seat’s vantage point
Capture insights and improvements that benefit everyone

The goal is blameless learning, not retroactive perfection. If the activity turns into a hunt for “who should’ve known better,” you’ve broken the ride.

Setting Up Your Analog Ferris Wheel

You can run this on a whiteboard, with sticky notes, or on paper handouts. Analog is intentional—it slows people down just enough to think and feel.

Step 1: Define the Seats (Roles)

Pick the perspectives most relevant to your outage. For example:

On-call engineer / incident commander
Customer (or end user)
Support / customer success
Product manager
Leadership (VP / CTO)
SRE / platform / reliability engineer

Each seat gets its own “perspective sheet”: a 1-page template with structured prompts (more on those below).

Step 2: Mark the Lifecycle Stages

Across the top or side of a whiteboard (or down the page of your templates), define the lifecycle stages of the incident:

Early signals – First hints something might be wrong
Recognition – The moment it’s clearly an incident
Escalation – Pulling in more people / declaring severity
Mitigation – Actively working to reduce impact
Resolution – Systems normal / incident closed
Aftermath – Communication, follow-ups, emotional residue

Every role’s story will move through these same stages.

Step 3: Rotate Through Each Seat

For each seat, ask someone to role-play that perspective (they can be the real person who had the role, or someone else using the prompts). The group then walks through the lifecycle stages from that one vantage point before rotating to the next.

Important rule: Only one seat speaks at a time. Everyone else listens and takes notes.

Printable-Style Prompts for Each Seat

Below are sample prompts you can literally print and hand out. Each “seat” gets the same structure but tuned to their context.

Seat 1: On-Call Engineer / Incident Commander

Lifecycle prompts (repeat for each stage):

What did you know at this moment? (specific signals, alerts, dashboards)
What were you feeling? (confident, overloaded, anxious, calm)
What decision did you make? Why?
What constraints did you perceive? (time, risk, unclear ownership, tooling)
What would have made this moment easier or safer?

Reliability lens:

Where did tooling help/hurt?
Where was communication clear/unclear?
Did you know who had authority to decide X?

Seat 2: Customer / End User

You may not have a customer in the room, but you can still approximate their view.

Lifecycle prompts:

When did I first notice something was wrong?
What was I trying to do? What blocked me?
What information did I see? (error messages, status page, emails)
How did this affect my trust or behavior?
What response would have felt respectful and competent?

Reliability lens:

Was impact described in customer language or internal jargon?
Did we set realistic expectations about timelines and risk?

Seat 3: Support / Customer Success

Lifecycle prompts:

What were customers saying at this stage?
What information did I have to answer them?
How aligned were internal updates with what I was telling customers?
Where did I feel stuck or exposed?
What template, playbook, or data would have helped?

Reliability lens:

Are there standard incident comms templates?
Do we have clear alignment between status page, support macros, and internal updates?

Seat 4: Product Manager

Lifecycle prompts:

What risks or tradeoffs about this system did we already know?
What did I worry about as impact grew? (SLAs, roadmap, contracts)
What decisions did I support during mitigation?
How did this reshape priorities after the incident?

Reliability lens:

Are reliability and feature work balanced in planning?
Did this incident reveal missing SLIs/SLOs or unclear commitments?

Seat 5: Leadership (VP / CTO)

Lifecycle prompts:

What signal told me this was serious? (severity level, customer name, revenue impact)
What updates did I get? How often?
What decisions did I need to make? (public messaging, resource allocation)
Where did I fear reputational or regulatory risk?
What would increase my trust in the incident process next time?

Reliability lens:

Are severity definitions and escalation criteria clear?
Is there a standard, reliable communication cadence during major incidents?

Seat 6: SRE / Platform / Reliability Engineer

Lifecycle prompts:

What did this teach me about our system’s actual behavior vs. our mental model?
Where did observability help or fail?
What underlying system or process debt did this expose?
What durable improvements can realistically be implemented?

Reliability lens:

Which defenses failed (or were missing)?
What changes will most reduce recurrence or blast radius?

Making It Blameless and Emotionally Safe

The ferris wheel only works if people feel safe telling the truth about:

Being confused
Missing signals
Feeling overwhelmed or scared
Making “best guess” decisions under uncertainty

To protect that honesty:

Set the frame clearly
- “We’re here to understand how the system and process behaved for different people—not to judge individuals.”
Ban hindsight bias language
- Avoid: “You should have known…”
- Replace with: “Given what was visible then, what options seemed available?”
Normalize emotions as data
- Overload, confusion, anxiety, or boredom are signals of system design, not personal weakness.
Document learnings at the system level
- “We need a clearer escalation path”
- “We need better dashboards for service X”
- “We need a support macro for scenario Y”

Turning Perspectives into Concrete Reliability Outcomes

Each seat’s story should produce at least one change in how you run incidents or design systems. Examples:

Engineer seat → Better runbooks & roles
Confusion about who could make a rollback decision leads to an updated incident role chart and a clearer rollback policy.
Customer seat → Clearer communication
Realizing status messages were meaningless to users (“elevated 5xx errors”) leads to new plain-language status templates.
Support seat → Unified source of truth
Support telling customers one thing while engineering knows another leads to a central live incident channel or document plus updated macros.
Leadership seat → More trust, less interruption
Leadership discovering they were pinging engineers ad hoc for updates leads to a standard update cadence and broadcast format.
SRE seat → Fewer repeat incidents
Seeing the same failure pattern show up again leads to prioritized resilience work: rate limiting, circuit breakers, better alert thresholds.

Each of these outcomes connects directly to organizational resilience: faster mitigation, cleaner communication, reduced cognitive load, and fewer surprises.

Building Social-Emotional Skills in Engineering Teams

Although it looks like a process exercise, the ferris wheel is also quiet training in:

Empathy: Engineers imagine how their actions felt downstream to customers and support.
Perspective-taking: Leaders see the pressure and ambiguity on the frontlines.
Collaboration: Teams co-design improvements that respect everyone’s constraints.
Goal setting: The group commits to specific behavior and process changes for the next outage.

You can amplify this by ending with a closing round:

“What surprised you most from another seat’s perspective?”
“What is one thing you personally will do differently next incident?”
“What commitment should we make as a team to support each other better?”

Capture these as one-page commitments and revisit them at your next incident review.

Conclusion: One Ride, Many Views, Shared Improvements

Every outage is already a ferris wheel—many people rising and falling through the same chaotic loop, each seeing only their slice of the landscape. The Analog Incident Story Ferris Wheel makes that reality visible and usable.

By rotating through each perspective in a structured, blameless way, you:

Turn individual stress into collective insight
Reveal gaps in communication, tooling, and roles
Connect emotional reality to technical and process change
Build a culture where reliability is everyone’s shared responsibility

Run this exercise a few times and it becomes a ritual: after each significant incident, we ride the ferris wheel together. The outage may have hurt, but the story we tell about it can make the system—and the people who run it—stronger for the next one.