The Analog Incident Story Tram Map Workshop

Hand‑Drawing Reliability Routes Through a Paper City of Failures

What if you could ride along with your next incident as if it were a tram line through your system? Every alert becomes a station. Every handoff between teams, a line change. Every obscure dependency, a risky interchange.

That’s the idea behind the Analog Incident Story Tram Map Workshop: a collaborative, paper‑based exercise where teams literally draw how failures flow through their infrastructure, tools, teams, and processes.

In a world of dashboards, traces, and real‑time metrics, this sounds almost suspiciously low‑tech. But that’s exactly the point. When you step away from the screen and slow down with pen and paper, you start seeing reliability in a new way.

Why Draw a Tram Map of Incidents?

Transit maps distill chaotic geography into clean, understandable structure. You don’t see every street and building; you see what matters for navigation:

• clear lines (routes)
• distinct stations (stops)
• intuitive interchanges (where routes cross)

Now imagine incidents as routes on a tram map:

• Each incident is a line that travels through systems, teams, and decisions over time.
• Each event (an alert, a Slack ping, a failed deploy, a manual fix) is a station.
• Each dependency or handoff is an interchange.

By visually mapping incidents this way, you:

• Reveal hidden dependencies and “we forgot that even existed” components.
• See how minor issues cascade into major outages.
• Understand how incidents move across teams and tools, not just across servers.
• Make risks and bottlenecks obvious at a glance, instead of buried in logs or postmortems.

A tram map isn’t just a pretty artifact—it’s a shared mental model everyone can point at and discuss.

Paper Over Pixels: Why Analog Matters

You have dashboards, runbooks, incident timelines, traces, and tickets already. Why add paper to the mix?

Because analog forces different behaviors:

1. Slowness surfaces assumptions
   When you draw incidents by hand, you can’t fast‑forward or filter. You have to decide: What happened next? Who was involved? Which system did this touch? Those conversations expose:

   • contradictory recollections
   • invisible dependencies
   • vague ownership (“Who actually runs this job?”)

2. Everyone can participate
   No special tool expertise required—just pens and sticky notes. Ops, devs, product, and even leadership can stand around the same paper map. That levels the field and encourages shared learning.

3. You break out of the dashboard tunnel
   Digital views are powerful but highly curated. They show what someone decided to instrument, in the shape that tool prefers. A blank sheet of paper doesn’t care about products or schemas. You can mix:

   • infrastructure
   • teams
   • processes
   • tools on a single canvas.

4. The artifact invites curiosity
   A hand‑drawn map up on a wall sparks hallway conversations: “Why does that line go through three teams for a simple rollback?” Over time, the wall of maps becomes a living reliability gallery.

Setting Up an Incident Tram Map Workshop

You don’t need much to start:

Materials:

• Large sheets of paper or a roll of brown paper
• Colored markers or pens
• Sticky notes (optional but handy)
• Tape or a big table/wall

People:

• 1–2 experienced SREs or incident commanders (to guide the story)
• Engineers from key systems touched by the incident
• A representative from support, product, or customer success (if customer impact was involved)
• A facilitator (can be one of the SREs) to keep time and prompt discussion

Incident selection: Pick one of:

• A recent high‑impact incident everyone remembers
• A “small” repeated incident that feels like background noise but keeps coming back

Avoid starting with the absolute most traumatic outage; begin with something real but safe enough to dissect.

Step‑by‑Step: Drawing the Paper City of Failures

1. Define the Map’s “Geography”

First, decide what your stations represent. Common options:

• Systems / Components (APIs, databases, queues, jobs)
• Teams (Backend, SRE, Data, Support)
• Tools (PagerDuty, Slack, CI, dashboards)
• Process Steps (Detect → Diagnose → Mitigate → Recover → Learn)

Then draw a simple layout:

• Horizontal axis: time (left = start of incident, right = resolution)
• Vertical clusters: major domains, e.g.:
  • top band: customer & business impact
  • middle band: applications & services
  • lower band: infrastructure & external dependencies
  • side panel: teams & communication

You don’t need perfection—only logical regions where you can place stations.

2. Plot the Incident Timeline as a Route

Pick a colored marker for this incident’s line.

Walk through the incident story:

1. Trigger: What was the first observable sign? User report? Alert? Dashboard anomaly?

   • Draw a station: “User reports error 500s” or “CPU alert fires on service X”.

2. Propagation: What happened next? Which system did the failure touch?

   • Draw a station for each significant transition and connect them.

3. Detection & Response: How did the team notice and react?

   • Include stations like “PagerDuty alert to on‑call”, “Slack war room created”.

4. Escalations & Handoffs: When did other teams or tools join the story?

   • These are your interchanges.

5. Mitigation & Recovery: Track every major attempt to fix, successful or not.

Resist the urge to compress. If it took six handoffs to roll back a deploy, show all six.

3. Expose Hidden Dependencies and Forgotten Components

As you draw, keep asking:

• “What did this failure depend on to become visible?”
• “What did it rely on to get worse?”
• “Which components are we assuming ‘just work’ here?”

Add stations for:

• scheduled jobs that silently failed
• old services nobody wants to own but everyone relies on
• external providers (payments, DNS, auth) that shaped the incident

Use a different color or station shape for these “forgotten” pieces. They’re often where cascading failures start.

4. Embed SRE Practices as Lines and Interchanges

Now enrich the map with SRE incident management structure:

• Draw a distinct “communication line” that follows who talked to whom, where, and when (Slack channels, bridge calls, status pages).
• Add a “command line” showing incident command role, decision points, and escalations.
• Mark interchanges where technical paths and communication paths intersect, e.g.:
  • decision to roll back
  • decision to page another team
  • decision to update customers

This makes it obvious where communication lag or role confusion slowed resolution.

5. Highlight Bottlenecks, Breakpoints, and Design Flaws

Step back and look at the whole map. Ask the group:

• Where do many routes pass through a single fragile station? (single points of failure)
• Where do we see long gaps between detection and action? (slow response)
• Where do lines do unnecessary detours through multiple teams? (ownership or permissions problems)
• Where do failures jump unexpectedly between domains? (surprising dependencies)

Circle these areas or mark them with icons (⚠, ●●●). These are your reliability hotspots.

How Tram Maps Improve Future Incidents

Once you’ve drawn a few incident tram maps, patterns emerge.

Faster, Clearer Decision‑Making

Teams that see their incident routes laid out visually:

• redesign on‑call rotations and escalation paths to reduce detours
• place dashboards and alerts where the map shows blind spots
• streamline permissions so the right people can act without waiting

The next time an incident touches a known “interchange,” responders already understand its context and risk.

Better Shared Understanding Across Roles

Non‑engineers can finally see:

• why a “small config change” wasn’t small at all
• how external vendors or “that old service” shape outages
• which teams get overloaded during every major event

This builds empathy and makes conversations about investment in reliability more concrete.

More Honest Post‑Incident Reviews

A visual tram map turns a postmortem from blame‑tinted storytelling into joint exploration:

• You can literally point at the messy spaghetti of lines and ask, “How can we make this simpler?”
• People contribute corrections and nuance—“We actually didn’t know that queue was backing up at the time”—which improves your historical record.

Tips for Running a Great Workshop

• Timebox aggressively. 60–90 minutes is enough for one incident. Don’t aim for perfection; aim for insight.
• Start rough. Use sticky notes for stations at first so you can rearrange as the story clarifies.
• Rotate storytellers. Don’t let only senior engineers narrate. Ask different participants to describe their segment.
• Capture photos and digitize lightly. You can recreate the map in a diagramming tool later, but keep the original character.
• Repeat regularly. Make tram map workshops part of your incident review culture—monthly or after major events.

Conclusion: Building a City of Reliability Stories

The Analog Incident Story Tram Map Workshop is not about better art; it’s about better shared thinking.

By hand‑drawing incidents as routes through a paper city of failures, you:

• surface obscure dependencies and forgotten components
• see how small issues escalate into big outages
• blend geo‑style clarity with abstract reliability data
• embed SRE roles, communication paths, and escalations directly into a visual map
• create collaborative, slow, analog space for teams to challenge assumptions and redesign their systems

Over time, your wall of tram maps becomes a living atlas of how your organization experiences failure—and how it learns. Each new incident line is another route you’ll navigate better next time.

You already have logs, traces, and metrics. Add something different: a marker, a big sheet of paper, and an hour with your team. Draw the story of your next incident. See where the lines really run.