Post-mortem questions ask what we set out to do, what happened, what went well, what got in the way and what we change next time. In the meeting, the loud voices fill the hour. Ask everyone first, one at a time, and the quiet person's answer is on the table before anyone speaks.
The launch slipped when the API date moved and nobody said so out loud; the status stayed green for three more weeks.
An example of the line the Agent Results Brief leads with.Under every question is the follow-up Spoke asks when the first answer is vague. That second question is where the real answer usually is.
What did we set out to do with this project, in your own words?
Halfway through, how would you have known whether we were on track for that?
What did you personally expect to be true on launch day?
Which of those things turned out differently?
Who was this project for, as you understood it?
What did that person need from it most?
Walk me through the project from your seat. What happened, in order?
Which step took longer than the plan said it would?
When did you first sense the plan and the reality had drifted apart?
What did you see that day that told you?
What changed between the plan and what shipped?
When did you find out about that change?
What was the hardest week of the project for you?
What made that week harder than the others?
What went better than you expected?
What made it go that way?
What would you keep exactly as it was next time?
What would we lose if we dropped it?
Where did the team recover well from something going wrong?
What did someone do that made the recovery work?
Which decision are you glad we made?
What would have happened if we'd gone the other way?
What got in the way most?
Think of the last time it got in the way. What were you trying to do?
Where did you spend time the plan hadn't counted on?
What did you put down to make room for it?
What did you need earlier than you got it?
What did you do while you waited?
What, if anything, did you hold back from saying at the time?
What would have made it easier to say?
Which decision took the longest to get made?
What was it waiting on?
What made the biggest problem possible in the first place?
What would have had to be true for it not to happen?
What did we assume at the start that turned out to be wrong?
When could we have checked that assumption?
Which of the things that went wrong were connected?
What's the thread that runs through them?
If the same problem showed up again, what would be the earliest sign?
Who would be the first to see that sign?
What's the one thing you'd change before we run a project like this again?
What would that change look like in the first week?
What should we stop doing?
What would you do with the time that frees up?
What would you tell the next team on their first day?
What makes that the thing they most need to hear?
What would you bet we do again next time?
What would it take to catch it early next time?
Walk me through the incident as you experienced it. What happened first?
What was the first thing you saw that told you something was wrong?
How did we find out about the incident?
What would have told us sooner?
What did you have to go looking for during the response?
Where did you eventually find it?
What did the system do that surprised you?
What did you expect it to do instead?
What made sense to do at the time that looks different now?
What did you know at that moment that led you there?
What slowed the fix once you knew what was wrong?
What were you waiting on at that point?
Every person gets interviewed, not surveyed. Spoke asks, listens, and follows up on what that person actually said. Here's an example.
Read the answer, not the transcripts: themes ranked by how many people raised them, the quotes behind each, and the places where two groups disagree.
The launch slipped by three weeks. Most people trace it to the API date moving without anyone announcing it: the ticket changed, the plan didn't, and people found out from broken branches rather than from a message. Status stayed green because nobody wanted to be first to say it, or nobody had the full picture; the team is split on which. What went well: the rollback on launch day was fast because one person had rehearsed it. What to change: say every date change out loud in one place, check plan against reality weekly, and rehearse the rollback before every launch.
An example Agent Results Brief. The counts, themes and quotes are illustrative, not from a real survey.
The post-mortem meeting is where the loud voices win and the person who was on call at 3 a.m. says nothing. Move the asking to before the meeting.
The first answer in a post-mortem is a category: communication, scope, resources. The follow-up turns it into the specific handoff, decision or hour. Examples, not real respondents.
Not communication in general: an approval loop with no final say. The fix is one owner for the email, not another status meeting.
A small habit worth keeping: test the copy on real customers first. Without the follow-up the meeting hears “the email did well” and moves on.
Detection failed for a specific, fixable reason: an alert silenced for a migration and never restored. Blameless framing got the person who silenced it to say so.
The words get mixed up. They differ in when you ask and what you're asking for.
| Post-mortem | Retrospective | Pre-mortem | |
|---|---|---|---|
| When | After a project, launch, campaign or incident ends | At the end of every sprint or cycle, while the work continues | Before the work starts, once there's a plan |
| The question | What happened, why, and what do we change? | What should we keep, stop and try next sprint? | Imagine it failed. What went wrong? |
| Scope | The whole project, start to finish, including the decisions made before anyone wrote code | The last two or three weeks of work | The plan and its assumptions |
| Who answers | Everyone who touched the project, including people outside the team who depended on it | The team that did the sprint | The people about to do the work |
| The output | A written record: timeline, root causes, and changes with an owner and a date | A short list of experiments for the next sprint | Risks ranked, with the earliest sign of each |
| Where to ask | Use the questions on this page; interview everyone before the meeting | A retro board, then the engineering questions for the notes the board left vague | The root-cause set above, in the future tense: what would make this fail? |
Retro boards on ScatterSpoke are free with no limits. Which questions to ask after a sprint, rather than after a project, is on the engineering use case; how to write a probe that gets past the first answer is in follow-up questions.
A blameless post-mortem assumes everyone did the reasonable thing with what they knew at the time. The wording of the question decides whether people defend themselves or explain.
The useful question is what the person knew and saw at the moment they decided. That's where the missing alert, the stale ticket and the unread comment show up.
When a person made a mistake, the system let them. Ask what the system did, what it should have done, and what would have caught it.
“Communication was bad” is a verdict. “The last time it got in the way” is a story with a handoff in it, and you can fix a handoff.
If the post-mortem only collects failures, people learn to hide them. Ask what to keep, and who did something that made a recovery work.
What do you want to learn, and who's answering?
Want me to keep the incident questions separate from the project ones, or run them together?
Work through the shape of the project: what we set out to do, what happened (the timeline before any judgment), what went well, what got in the way, root causes, and what we change next time. Ask each as an open question and follow up on the first vague answer: when “communication was bad” is all you get, ask what would have had to be true for it not to happen.
To turn one project into a written record the next one can use: what happened, why, and what changes, from everyone who worked on it, not just the people who spoke in the meeting.
A post-mortem looks at a whole project, launch, campaign or incident after it ends and produces a written record: timeline, root causes, changes with an owner. A retrospective is a recurring look at the last sprint or cycle while the work continues, and produces a short list of things to try next. Sprint retro questions are on the engineering use case; retro boards are free.
Start from the assumption that everyone did the reasonable thing with what they knew at the time. Ask what people knew and saw when they decided, what the system did and should have done, and what would have caught the problem earlier. Ask everyone before the meeting, one at a time, so nobody has to say a hard thing in front of the room first. On paid plans you can make the responses anonymous.
Within a week or two of the project ending or the incident closing, while people still remember the order of events. Send the questions a few days before the meeting so the meeting starts from the themes rather than from a blank whiteboard.
Lead with the one-line answer, then the timeline, what went well, what got in the way with how many people raised each, the root causes, where people disagreed, and the changes with an owner and a date. The Agent Results Brief gives you the themes, the counts, the quotes and the disagreement; every interview is there as a transcript, and you can export the survey data as CSV.
Free to start. No card. Your first ten agent surveys are on us.
