Introduction: Why Your System Needs a Greenhouse

Most teams treat incidents as isolated storms: they roll in, cause chaos, then vanish into postmortem docs that no one reads twice.

But in reality, your system doesn’t just have storms — it has seasons.

There are predictable times of the year when things get fragile: end-of-quarter crunches, marketing launches, Black Friday, holiday freezes, major releases, tax season, school enrollment windows. These aren’t random; they are seasonal patterns of load, risk, and vulnerability.

This is where the “greenhouse dome” 360° paper panorama comes in.

Imagine building a big, physical, circular map of your system’s year — a paper dome that wraps around you. Each segment represents a time-bound phase of risk. You walk around it and see, in all directions, the stories of incidents, near-misses, and operational stress. It’s analog, visual, and deeply collaborative.

This post walks you through how to:

• Use a 360° greenhouse dome as a metaphorical map of your system
• Treat incidents like seasonal agricultural cycles
• Structure each season using incident comms and retro patterns
• Apply a tool evaluation mindset when deciding what and how to visualize
• Turn the dome into a living, shared artifact for onboarding and learning

Step 1: Map Your System’s Riskiest Seasons

Start by asking: When does our system get fragile? Not just when it broke in the past, but when you hold your breath a bit more.

Look for patterns over a calendar year:

• Traffic-driven seasons
  • Black Friday / Cyber Monday
  • New feature launches
  • End-of-year rush / tax deadlines
• Org-driven seasons
  • Big release windows
  • Code freeze periods
  • Org restructures or major product shifts
• External dependency seasons
  • Vendor maintenance windows
  • Regulatory deadline cycles

Treat this like agricultural seasonality:

• Planting: New features, large migrations, foundational infra changes
• Growing: Steady load, feature adoption, dependency accumulation
• Harvest: Peak usage, reporting deadlines, public launches
• Fallow: Slow periods, refactors, technical debt paydown

Make a simple list or spreadsheet first. Each row is a time-bound phase (e.g., “November peak retail season,” “Q2 tax filings,” “Annual enrollment week”). This will become the structural backbone of your paper dome.

Step 2: Design the 360° Greenhouse Dome

You don’t need a real dome. You just need 360° of paper and some tape.

Physical layout

• Take a roll of paper or multiple large sheets
• Arrange them around a table or wall in a circle (or as close as you can)
• Divide the circle into segments, each representing a season/phase
• Label each segment with:
  • Time frame (e.g., “Nov 15–30”)
  • Name (“Holiday Checkout Surge”)
  • Primary risk type (load, change, dependency, organizational, security, etc.)

You’re essentially building a giant, analog polar chart of your year.

Metaphor: The greenhouse dome

In a greenhouse, you:

• Track what grows when
• Understand conditions (light, temperature, water)
• Notice recurring problems (pests, disease, nutrient issues)

Your incident greenhouse does the same:

• Shows what breaks when
• Surfaces conditions that precede incidents
• Captures recurring failure patterns and their context

The dome format makes risk surround you. You’re not scanning a flat timeline; you’re standing inside your system’s story.

Step 3: Borrow From Incident Comms and Retros

To avoid the dome turning into a wall of sticky notes, give each season a clear, repeatable narrative structure.

Borrow from your best:

• Incident communication playbooks
• Status page update templates
• Retrospective or post-incident review formats

For each season segment, create a small, reusable template printed or written at the top, such as:

• Context:
  • What’s happening in the business/market?
  • Who is under pressure? (Teams, customers, partners)
• Conditions:
  • Typical load levels
  • Change velocity (high/medium/low)
  • Known fragile components
• Notable incidents:
  • Date / short title
  • Impact summary (customers, duration, systems)
  • Key contributing factors
• Signals & leading indicators:
  • Metrics or logs that usually get noisy
  • On-call tickets that spike
• Practices that helped:
  • Playbooks that worked well
  • Communication patterns that reduced confusion
• Open questions:
  • Things you still don’t understand about this season
  • Potential experiments for next year

Each segment becomes a mini-incident story capsule, not just a list of failures.

Step 4: Apply a Tool Evaluation Mindset

It’s tempting to try to cram every metric and graph into your paper dome. Don’t.

Treat the dome itself like a tool evaluation exercise:

• Team size & capacity
  • Small teams: focus on 3–5 major seasons and 1–2 key metrics per season
  • Larger orgs: more segments, richer annotations, but still curated
• Budget & effort
  • This is intentionally low-tech; the “budget” is time and attention
  • Decide how often you’ll update (quarterly? annually?) and stick to it
• Workflow alignment
  • Pull metrics that teams already check (dashboards, SLOs)
  • Reference existing tools rather than duplicating them on the paper
  • Add QR codes or short URLs to specific dashboards or runbooks

Your goal isn’t to reproduce your monitoring stack on paper.

Your goal is to orchestrate perspectives:

• Where do our tools and alerts always light up during this season?
• Where do they stay oddly quiet while humans feel nervous?
• Where are we blind altogether?

Choose views and metrics that highlight those gaps and tensions.

Step 5: Build Each Segment as a Story-Rich Panel

Now you’re ready to populate the dome.

For each segment (e.g., “Black Friday week”):

1. Mark the calendar bounds

   • Exact dates or recurring week pattern
   • Any known blackout or freeze periods

2. Plot historical incidents

   • Place each incident in the right season segment
   • Write a very short title (“2023 Checkout DB Saturation”)
   • Annotate with 1–2 sentences: cause, impact, what changed after

3. Add visual layers

   • Color bands for risk type (e.g., red = load, blue = change)
   • Icons or stickers for roles impacted (support, SRE, product, etc.)
   • Arrows showing dependencies (e.g., “API X strained by client Y”)

4. Highlight patterns

   • Cluster incidents with similar causes
   • Circle recurring triggers (marketing pushes, vendor outages)
   • Add short “this usually happens” notes

5. Capture preventative stories

   • Times when the system held up because of something you changed
   • E.g., “2024: same traffic peak, no incident after rate-limiting rollout”

Each segment becomes more than data; it’s a storyboard of risk and resilience.

Step 6: Turn It Into a 360° Story Platform

A dome is only powerful if many voices contribute.

Treat it like a shared 360° media platform where different roles “publish” their incident perspectives:

• SREs / Infra
  • Add details on saturation points, noisy metrics, flaky components
  • Mark playbooks that worked or failed
• Product managers
  • Note launches, feature flags, commitments to customers
  • Capture trade-offs made (“chose speed over reliability here”)
• Customer support
  • Annotate with spikes in tickets, common user complaints
  • Add quotes (anonymized) that capture user experience of the incident
• Security / Compliance
  • Identify compliance-heavy periods or regulatory deadlines
  • Mark phishing, fraud, or abuse spikes by season

Make contributions explicit rituals:

• Run a “dome update” session every quarter or after a major season
• During incident reviews, ask: “Where on the dome does this belong?”
• Give people simple sticky templates to fill out and stick onto the season

Over time, the dome becomes a collective memory device — not just ops memory, but org-wide memory.

Step 7: Use the Dome for Education and Decision-Making

Once built, the greenhouse dome shouldn’t be wall art. It should be a working tool.

Onboarding

• Walk new engineers or PMs around the dome
• Tell the story of the year as a sequence of seasons
• Use it to explain:
  • Why certain freezes exist
  • Why you’re strict about some review processes
  • Why specific metrics get special attention at certain times

Incident postmortems

• During a retro, stand near the relevant segment
• Ask:
  • Did this incident match past seasonal patterns?
  • What was different this time?
  • What did we learn that should be written into this season’s story?

Planning & roadmap

• Use the dome when planning major initiatives
• Ask:
  • Are we about to plant something risky in an already fragile season?
  • Should we move this launch to a more “fallow” time of year?
  • Which seasons need more tooling, rehearsals, or staffing?

The point is not only to remember incidents, but to change future decisions about when and how you take risk.

Conclusion: Make Risk Visible, Seasonal, and Shared

Digital systems feel abstract. Incidents get flattened into tickets, dashboards, and PDFs. The analog greenhouse dome gives your team a different kind of visibility: embodied, narrative, and collective.

By treating your system’s riskiest periods like agricultural seasons — with planting, growth, harvest, and fallow phases — you move away from “random bad luck” thinking and toward pattern, preparation, and adaptation.

A 360° paper panorama won’t replace your tools, but it will:

• Expose recurring risk seasons in a way everyone can understand
• Create a shared, story-based artifact that survives reorgs and churn
• Give SREs, product, support, and others a common map to contribute to

If your incidents are starting to feel like the same story told over and over, it might be time to build a dome, step inside it, and see your system’s year in full 360°.

Then ask, together: What can we grow differently next season?