🚨 Postmortem Anti-Pattern: The Solo-Authored Postmortem

Overview

A postmortem is often handed to whoever was on call when the incident closed: “you were closest to it, you write it up.” That person sits down alone, reconstructs the timeline from their own memory and their own terminal history, names the cause as they understood it, and files the document. It looks complete. It reads coherently. And it is, almost inevitably, wrong in the specific way that a single perspective is always wrong — it captures what one person saw, knew, and could infer, and silently omits everything outside that one field of view. The parts of the incident that lived on another team’s dashboard, in another engineer’s earlier decision, or in a system the author doesn’t operate simply never make it onto the page.

This anti-pattern is deceptive because a solo postmortem can be well written, on time, and entirely blameless, and still fail at its one job: producing an accurate, multi-causal understanding that prevents recurrence. Incidents in distributed systems are rarely single-threaded events with a single witness. They cross service boundaries, span shifts, and involve decisions made days earlier by people who aren’t in the room. A single author cannot know what they don’t know, and — crucially — cannot review their own blind spots, because the whole nature of a blind spot is that you can’t see it from where you’re standing. The correction is not a better writer; it is more eyes. This guide is about why solo authorship fails and how to build the collaboration that fixes it.

Symptoms

• A single name in the author field and no reviewers, contributors, or acknowledgments — the document is one person’s account, start to finish.
• A timeline built entirely from one vantage point, missing the events that were only visible on another team’s side of the incident.
• A root cause that stops at the author’s system boundary, naming the component they operate and going no deeper into upstream or downstream causes.
• Unexamined assumptions stated as fact — “the cache was obviously stale” — that a second reader from another team would immediately question.
• Action items that all land on the author’s own team, because those are the only levers the single author can see and pull.
• No dissent or alternate hypotheses recorded, because there was no one present to disagree.
• A review meeting that is a read-out, not a review — the author presents, everyone nods, nothing is challenged or added.
• Recurrence of the incident via a cause the postmortem never mentioned, revealing the whole other half of the story the solo account missed.

Common Root Causes

• Postmortem treated as a chore to assign. It gets handed to one person to “get it done,” framing it as documentation rather than collective sense-making.
• The single-witness fallacy. The organization assumes the person who resolved the incident understands it fully, when they usually understand only their slice.
• No structural role for contributors. The template and process have an author field but no mechanism to pull in the other teams, shifts, and systems that touched the incident.
• Time pressure. Getting many people to co-author feels slow, so a solo draft is filed to close the ticket, and the collaboration that would have caught the blind spots never happens.
• Siloed knowledge. Each team can only see its own telemetry, so a cross-boundary incident genuinely cannot be understood by any one team acting alone.
• Review as ritual, not scrutiny. Where a review meeting exists, it’s often a passive read-out with no expectation that anyone challenge or extend the account.
• Author’s stake in their own narrative. People are poor critics of their own reasoning; the author is the one person least able to spot the assumptions they built the document on.

Diagnostic Workflow

Before accepting a postmortem as done, map the surface area of the incident and check whether every part of it had a voice in the writeup. The test is coverage, not eloquence.

List everyone/everything the incident touched:
  which services / components were involved?
  which teams own each of them?
  which on-call shifts spanned the incident window?
  who made upstream decisions (deploys, config, capacity) days before?

For each -> did that perspective contribute to the postmortem?
Any gap -> the account is partial. Pull that voice in before finalizing.

Next, stress-test the causal chain and the assumptions, ideally with someone who was not the author. A blind spot is only visible from another angle.

For each stated cause or assumption, ask a non-author reader:
  "Is this how it looked from your system's side?"
  "What would have to be true for this to be the whole story?"
  "What did YOU see during this window that isn't written here?"

New facts, dissent, or alternate hypotheses surfacing
  -> the solo draft was incomplete. That's the collaboration working.

Finally, examine where the action items land. If every remediation targets one team’s systems, that is a strong signal the analysis never crossed the author’s boundary. A genuinely multi-causal incident almost always produces action items for more than one team, and their absence is diagnostic of a single-perspective account.

Example Root Cause Analysis

Incident: The mobile app showed stale account balances to users for about 40 minutes. The mobile backend on-call engineer resolved it by restarting the balance-cache service and was asked to write the postmortem.

Solo-authored version: “Root cause: the balance-cache service held stale entries after a deploy and did not evict them. Fix: restarting the cache cleared the stale data. Action items: add a cache-eviction step to the mobile backend deploy; add a cache-freshness alert on the mobile backend.” Author: the mobile backend on-call. No other contributors.

Why this is wrong — the blind spot: The mobile backend engineer accurately described what they could see: a stale cache, cleared by a restart. But the cache was stale because an upstream ledger service had, earlier that day, changed the format of its balance-update events without a version bump — a change on a different team, visible on a different dashboard, made before the mobile on-call’s shift even began. The cache wasn’t failing to evict; it was faithfully caching updates it could no longer parse. The restart worked only because it forced a full reload from a source that eventually reconciled. The real cause lived entirely outside the author’s field of view, so the solo account named the symptom the author could see and missed the cause they couldn’t.

What collaboration surfaces: Pulling in the ledger team’s on-call and their deploy log reveals the unversioned event-format change. Pulling in the earlier shift reveals warning signs that were logged hours before the user-visible symptom. Neither perspective was reachable by the single author.

Corrected, co-authored version: “Root cause (cross-team): the ledger service changed its balance-event schema without a version bump; the mobile balance-cache silently failed to apply the new-format updates and served the last parseable values. The cache restart forced a reload that masked, then reconciled, the underlying incompatibility.” Real action items span both teams: ledger team adds schema versioning and a consumer-compatibility check to its release process; mobile backend adds parse-failure alerting so silently-dropped updates surface loudly; a shared contract test guards the event schema in CI. Authors: both on-calls plus the earlier shift, credited as contributors.

Prevention Best Practices

• Make co-authorship the default. Require contributors from every team, system, and shift the incident touched; a single-author postmortem for a multi-team incident should not be accepted as complete.
• Assign a facilitator, not just an author. The facilitator’s job is to gather perspectives and drive the collaborative reconstruction, distinct from whoever holds the pen.
• Build a contributor-mapping step into the template. Explicitly list affected services, their owning teams, and the shifts spanned, and confirm each had input.
• Run reviews as active scrutiny, not read-outs. Set the expectation that reviewers must challenge assumptions, add missing timeline events, and propose alternate hypotheses — silence is a failed review.
• Invite a non-author reviewer from an unrelated team. A fresh outsider is often best positioned to spot the assumptions insiders take for granted.
• Check where action items land. If every remediation targets one team, treat it as a signal the analysis never crossed a boundary, and dig for the causes on the other side.
• Reward contribution, not just authorship. Credit everyone who added a perspective, so collaboration is recognized as the substance of the work rather than overhead on top of it.

Quick Reference

# Anti-pattern: the solo-authored postmortem -> one perspective, one set of blind spots.
# You cannot review your own blind spot; it needs another angle.

Coverage check (do BEFORE finalizing):
  list every service/component, owning team, shift, and upstream decision
  for each -> did that perspective contribute? gap = partial account.

Stress-test with a NON-author:
  "Is this how it looked from your system's side?"
  "What did you see in this window that isn't written here?"
  new facts / dissent surfacing = the collaboration working.

Diagnostic signals of a solo blind spot:
  single name in author field, no contributors
  root cause stops at the author's system boundary
  every action item lands on ONE team
  review meeting is a read-out, nobody challenges anything

Fixes:
- co-authorship required for multi-team incidents
- facilitator role separate from the pen-holder
- contributor-mapping step in the template
- reviews = active scrutiny; invite an outside reviewer
- credit contribution, not just authorship

Conclusion

The solo-authored postmortem fails quietly: the document is coherent, punctual, and blameless, and it still encodes only what one person could see from one seat during one shift. Incidents in real distributed systems cross services, teams, and time, and no single witness holds the whole picture — worse, the single author is precisely the person who cannot audit their own blind spots, because a blind spot is defined by being invisible from where you stand. The remedy is structural rather than editorial: make co-authorship the default, map every perspective the incident touched, run reviews as genuine scrutiny that outsiders are expected to challenge, and treat action items that all land on one team as a warning that the analysis never left home. A postmortem’s value is measured by the accuracy of its understanding, and accurate understanding of a multi-causal event is a collective achievement. One pair of eyes writes a story; many pairs of eyes find the truth.