The same story, told thirty times, is not repetition. It's perspective, taught one angle at a time.
The facts of a story can stay the same while its center changes. One telling follows the person who made the decision. Another follows the person waiting for it. A third follows whoever dealt with the consequences. Each perspective can reveal something the others missed without changing what happened.
A post-mortem can be technically accurate and still leave the team with an incomplete picture. What broke and what fixed it are essential. So are what it cost, what was not delivered, and what the person on the other end of the outage experienced.
A practical way to widen the review:
- Write the same incident three times: from engineering, from the business, and from the customer's chair. If the three versions agree on everything, one of them wasn't written honestly.
- Have the customer's version written by someone who never touched the fix. Whoever fixed it can no longer see the outage from the outside.
- Read the three side by side before deciding what to change. The action item almost always lives in the gap between two tellings, not inside any one of them.
For a system running across regions, a useful incident review connects technical recovery to its consequences. Which users could still work? Which commitments were missed? What did support have to explain? Those questions help turn a repair record into a decision about what to build next.
Retelling isn't redundancy. It's how a team gets a whole picture out of people who each hold a piece.
When your team writes up a failure, whose version gets written — and whose never does?