Review the incident without giving responders tomorrow’s knowledge

Once we know storage was involved, the rollback discussion can look like a detour. Why were people looking at the deployment?

Because they did not know the ending yet. They saw delayed exports after a deployment. That sequence gave them a reasonable question, not a settled explanation. A useful incident review lets the reader discover what weakened that question and what the team learned next.

The fictional Dispatch timeline records a deployment hypothesis, a submission cap that helped only partly, a search for specialist help and an eventual storage repair. To learn from those decisions, keep the information available then separate from the information available now.

Put yourself beside the unfinished timeline

Choose three moments: declaring the incident, applying the cap and waiting for storage approval. For each, record what was known, which explanations remained plausible, what authority was available and what the action was meant to change. Put later findings in a different column, where they cannot quietly become earlier clues.

“The team wasted time considering rollback” tells us the reviewer's verdict. A more useful account explains the turn: “The team considered rollback because the deployment preceded the first reports; delayed jobs on the old version then weakened a version-only explanation.” Now the reader can follow both the original clue and the reason to reconsider it.

This does not excuse every missed opportunity. If compatibility evidence was available, identify where it lived, whether the responders knew to look there and how it could have changed their choice. That gives the next team something to repair. “Be more careful” leaves them to work out the repair alone.

Trace the deployment hypothesis through that old-version comparison. Do not claim the team ignored the real cause unless the record shows that decisive evidence was already available and understood. Knowing the answer afterward is not evidence that it was obvious beforehand.

Storage was part of the story, not the whole explanation

Slow storage delayed writes. Retries could add work. Missing completion records made unfinished exports harder to see. Waiting for a specialist affected when the team could act. Calling all of those conditions “the storage problem” would hide different opportunities to reduce harm.

The incident lead coordinates the response without automatically holding every production permission. If approval delayed mitigation, show which route was missing and what the wait changed. Saying the lead should simply have bypassed it does not repair the permission problem.

What would the proposed change actually change?

A dashboard might expose the delay sooner without preventing it. A backup approver might shorten the wait without changing how storage behaves. For each proposed action, distinguish preventing the trigger, reducing harm, revealing failure sooner and speeding the response. These are different contributions, even when all are worthwhile.

Be equally careful about the customers' experience. Name the affected operation and scope, the duration or supported time range, and unresolved exports. If the evidence only places the start of failures within a range, keep the range. A sharper-looking timestamp would not make the account more accurate.

Take the missing completion record. One candidate change is an event tied to the export identifier, with a way to find accepted work that is overdue. Test it with a synthetic stalled export: can the signal and the responder find that particular unfinished job? Then send through an export that completes normally, so ordinary work is not falsely labeled stalled. This improves visibility. Delayed writes still need their own storage repair.

Replace the verdict with the constraint

Build the account around impact, a linked timeline, the explanation, decisions and constraints. Include response behavior that helped as well as difficulties. Give the few resulting actions an owner, an expected effect and a check. Leave the source observations linked so another reader can challenge the explanation.

Before writing “The engineer failed to roll back quickly,” ask what the record actually establishes. Was compatibility unknown? Was an authorized reviewer unavailable? Was there no alternate approval route? Include supported constraints and leave the other possibilities as follow-up questions. A plausible explanation is still not a recorded fact.

Let another reader reach the ending

Ask someone who does not already know the outcome to read the review. Can they follow the clues and see what changed the team's mind? If they need the final cause explained first, the earlier decisions need a clearer account. The review should help the next responder reason through uncertainty, not merely make the past look orderly.

This tabletop cannot reveal real people's motives or establish real organizational causes. It can practise a more useful habit: show what each decision had to work with, what changed and what remains uncertain. Then the next team inherits more than the answer. It inherits a way to recognize the clues.

Sources

Postmortem culture discusses learning-oriented review. All Dispatch events and the example rewritten statement are illustrative.