Short answer: Dictate the narrative parts of a postmortem (summary, what happened, why it was not caught, what changes) by voice while the incident is fresh, and type the values (timestamps, service names, error rates, ticket IDs). Capture short spoken notes during the incident so the write-up becomes an edit job.
Open the last five postmortems your team published and read them as a stranger would. There will be a timeline, because timelines are copied out of the chat log. There will be a root cause, usually one line: "config change to the rate limiter." There will be action items, most of them a verb and a noun. What there will not be, in most of them, is an explanation. Why did the config change seem safe? What did the on-call engineer see first, and what did they think it meant? Why did it take forty minutes to find the change when the deploy log had it? Why did the customer notice before the alert did?
Those are the questions a postmortem exists to answer, and they are the parts that are missing. That is not because your team does not care, and it is not a "blameless culture" problem that another workshop will fix. It is an input-cost problem, and it has a mechanical solution.
Why postmortems come out thin
Consider when and how a postmortem actually gets written. The incident ended on Tuesday. The document is due for the review meeting on Friday. Whoever was incident commander (or whoever drew the short straw) sits down on Thursday afternoon with a template, a chat scrollback, and a memory that has already started to compress. They type at forty words per minute, from reconstruction, about something that took two hours to live through.
The three-day gap is expensive. On Tuesday afternoon, the on-call engineer could have told you exactly what they saw first, what they tried, what they ruled out and why. By Thursday that has collapsed into "we investigated and identified the cause." The reconstruction cost is real too: our guide to dictating status reports makes the point that most of the time spent on a weekly update is archaeology, not writing, and a postmortem is archaeology on hard mode.
Then there is the typing itself. The parts of a postmortem that are valuable are prose: an explanation of a chain of reasoning, in sentences, with "because" in them. Explaining that chain out loud to a colleague takes ninety seconds. Typing it takes ten minutes, and while you type you are holding the whole chain in your head, which is exactly the thing that makes people stop after the first sentence and write "see timeline."
The result is a document that has all the fields filled in and none of the understanding written down. Everyone at the review meeting supplies the understanding verbally, it is a good meeting, and six months later a new engineer reads the doc and learns nothing.
What a useful postmortem contains, and which parts are prose
Templates vary, but almost every postmortem has these parts:
- Summary. Two or three sentences a director can read. Prose.
- Impact. Who was affected, how badly, for how long. Mostly numbers with a sentence of context.
- Timeline. Timestamped events. Values plus a short sentence each.
- Root cause and contributing factors. The chain of "because." Prose, and the most important prose in the document.
- Detection. How you found out. Prose, and often the most awkward paragraph to write.
- Response. What was tried, what worked, what did not, why. Prose.
- What went well and what went poorly. Prose.
- Action items. A sentence each, plus an owner and a ticket. Prose plus values.
Six of eight sections are mostly sentences. The two that are mostly values, impact and timeline, are the two that usually get filled in properly, because you can copy them from a dashboard and a chat log. The document is thin exactly where it has to be spoken rather than copied.
Speak the narrative, type the values
The rule that makes voice work for this kind of writing is simple: speak the sentences, type the numbers and identifiers.
Speech is excellent at prose. It is fine at numbers, but numbers fail differently from words. If dictation gets a word wrong, the sentence usually reads oddly and you notice. If it hears "fourteen oh three" and writes 14:30, the timeline still reads as perfectly correct, and the engineer trying to correlate it with a deploy log next quarter draws the wrong conclusion. The same goes for "four percent" versus "forty percent" of requests, and for service names that are also ordinary words. There is no redundancy in a timestamp, so a wrong one looks exactly like a right one.
So the working pattern for a timeline row is: type 14:03, then hold the hotkey and say "first alert fires for elevated error rate on the checkout service; on-call acknowledges within two minutes." Type the next timestamp, speak the next sentence. Type ticket IDs, error rates, hostnames, and version numbers; speak everything around them. Read the digits back before you publish. This is the same split we recommend for dictating bug reports, and for the same reason: prose defends itself and data does not.
The timing change that matters more than the tool
Here is the part that changes the document more than anything else: move the narrative capture from Thursday to Tuesday. Not the whole document. Just the sentences.
During or immediately after an incident, the people involved know things they will not know in three days. The way to keep those things is to capture them as short spoken notes at the moment they are true. Fifteen seconds each:
- When you take over the incident: "Taking over from the previous on-call. What I have so far is elevated errors on checkout starting around two, no deploy in the last hour that I can see, first guess is the upstream payment provider."
- When a theory dies: "Ruled out the payment provider, their status page is green and our own health check to them is passing. Looking at the rate limiter change from this morning now."
- When you find it: "Found it. The rate limiter config change set the burst value in the wrong unit. It looked fine in review because the old value was also small. Reverting."
- When it is over: "Recovered at 15:41. What I want to remember for the postmortem: the alert fired eleven minutes after a customer emailed support, and the config diff was in the deploy log the whole time but nobody looked there because we assumed it was upstream."
Each of those is a spoken sentence or two into a scratch note, an incident channel, or the incident doc itself. None of them takes longer than a sip of coffee. Together they are the raw material for the summary, the root cause, the detection section, and the response section, written by the person who knew, at the moment they knew it. Thursday's job becomes ordering and trimming those notes rather than reconstructing them, and editing is the fastest kind of writing.
Where these notes go matters less than that they exist. A dedicated incident doc is best, because everything ends up in one place. An incident chat channel is fine as long as you are the kind of person who will go back and copy them out.
Section by section: how to dictate each part
The summary (write it last)
People try to write the summary first and stall, because a summary is a compression of things they have not written yet. Write it last. Then say it out loud as if answering a director who has stopped you in the corridor: "For about an hour and a half on Tuesday afternoon, roughly a third of checkout requests failed. A rate-limiter configuration change deployed that morning set a burst limit in the wrong unit. We reverted it and added a validation check. Nothing was lost, but customers saw errors and support got fourteen tickets." Two or three sentences. Fix the numbers by hand.
The timeline
Type the timestamp, speak the sentence, one row per event. Resist the urge to paste raw chat lines; a timeline made of "@here anyone else seeing this??" is a transcript, not a timeline. The spoken sentence should say what happened and, where it matters, what people believed at that moment, because the gap between belief and reality is where the lessons are.
Root cause and contributing factors
This is the section that dictation improves most, and here is why. The honest way to find a root cause is to keep asking why: the errors happened because the limiter rejected valid traffic; it did that because the burst value was a hundred times too small; it was too small because the unit changed; the unit change was not caught because the reviewer compared it to the old value rather than the documented range; there is no documented range because that config file has never had one. Speaking a chain of "because" is completely natural; it is how you would explain it across a desk. Typing the same chain is a slog, and the typed version tends to stop at the second link.
So do it out loud. Ask yourself "why" and answer in a full sentence, five or six times, into the doc. Then edit. You will end up with contributing factors you would not have typed, and the section will read like an explanation rather than a verdict.
Detection
"How did we find out?" is the most awkward paragraph in the document, because the honest answer is often "a customer told support" or "someone happened to look at a dashboard." That sentence is embarrassing to type slowly and easy to say quickly, which is precisely why it gets typed as "the issue was identified at 14:03." Say the real thing: "Support forwarded a customer email at 13:52. The alert did not fire until 14:03 because its threshold is set for a full outage, not a partial one." That is a finding. It generates an action item on its own.
Response
Narrate it as a sequence of decisions rather than a sequence of commands. What did you try first, and why did that seem right? What did you rule out? What would have shortened it? If you captured spoken notes during the incident, this section is mostly already written.
What went well, what went poorly
Two short lists, one sentence each. Speak them as opinions, then soften nothing that is true. "The runbook for the checkout service was out of date and pointed at a dashboard that no longer exists" is a useful sentence that nobody wants to type and everybody is willing to say.
Action items
Speak the sentence, type the owner and the ticket. "Add a validation step that rejects burst values outside the documented range" is a good action item; "fix config validation" is a note to self. The difference is four seconds of speaking.
Keeping it blameless
A worry we hear about dictating postmortems: does speaking make the tone worse? In practice it is the reverse. Typed postmortem prose drifts toward the passive voice and toward verdicts ("the change was not adequately reviewed") because those are the shortest things to type. Spoken prose sounds like a person explaining rather than a person defending, and it naturally includes the context that makes an action understandable: "the reviewer compared it to the old value, which was also small, so it looked like a routine tweak."
Two editorial habits keep it that way. First, speak in terms of roles and systems, not names: "the on-call engineer," "the reviewer," "the deploy," never "Priya's change." Second, if you find yourself saying "should have," stop and say instead what would have made the better path the obvious one. Dictation makes both easy, because rephrasing a sentence out loud costs nothing.
Where postmortems live, and the traps in each
Most teams keep postmortems in Confluence, Notion, Google Docs, or as an issue in the tracker. Each has a couple of things to know when you dictate into it.
- Selection is not insertion. A highlighted heading has no cursor. Click into the body of the section, see the caret, then dictate.
- Return submits. In a tracker comment box or a chat message, ending a sentence with a spoken "new line" can post the comment. In those surfaces, dictate a paragraph, then press Shift-Return yourself.
- Auto-numbering. If you say "one, two, three" into a doc that auto-formats lists, you get double numbering. Let the editor number the list; speak the item text only.
- Slash commands and single-key shortcuts. Block editors treat a leading slash as a menu, and trackers bind single letters to actions. Do not start a dictation with a slash, and if a hotkey ever triggers something in the app instead of dictating, move it. F13 through F19 are the safe choice on keyboards that have them.
Our guides to dictating Confluence pages and dictating issues and comments in Linear cover the tool-specific details.
Where Voice Keyboard Pro fits
Voice Keyboard Pro is a Mac menu bar app: hold a hotkey, speak, release, and the sentence is typed at your cursor in whatever app is in front of you. That is the whole interaction, and it is what makes the fifteen-second incident notes above practical. There is nothing to open and nothing to switch to; you are already in the incident doc or the channel, you hold a key and say the thing.
A few specifics that matter for postmortems:
- Smart Vocabulary is a personal dictionary with replacement rules. After one or two incidents you will know which service names, internal codenames, and vendor names come out wrong, and you add them once. Postmortems get searched later, so a service spelled two ways silently hides half your incident history. One caveat we repeat in every developer guide: do not add mixed-case code identifiers as replacement rules. Type those. Keep the dictionary to things you would say aloud in a meeting.
- Meeting Mode, with speaker detection and AI notes, is useful for the postmortem review meeting itself, where the best explanations are always given verbally and then lost. Tell attendees it is running, and treat the output as raw material for the doc rather than as the doc. Attribute findings to roles in the published version, even though the notes will know who said what.
- The iPhone keyboard covers the pages that arrive when you are not at a desk. Voice Keyboard Pro's iPhone keyboard has a mic button that works in any app, so an incident note can be spoken into the channel from wherever you are, and Voice Edit lets you fix a sentence by speaking the change instead of fighting a touchscreen cursor. Do not narrate customer data or credentials into a note from a phone, or from anywhere.
On privacy, since incident documents often contain things you would not want to leave the building: our servers store only operational pings, not audio and not transcript content. What you dictate ends up in your doc and nowhere else on our side. If your incident touches regulated data, follow your own policy about where the write-up may live, exactly as you would if you had typed it.
Voice Keyboard Pro has a free tier with daily limits, which is enough to try it on the next incident. Pro is $4.99 per month or $34.99 per year and removes the limits.
Honest limits
- It does not do the analysis. Dictation removes the cost of writing down what you understand; it does not supply the understanding. A postmortem dictated by someone who has not thought about the incident is a fast bad postmortem.
- There is no integration with your incident tooling, deliberately. It types text where your cursor is. Timestamps, graphs, and links still come from where they come from.
- Do not dictate code, configs, or commands into a postmortem. Paste them.
- It needs an internet connection to transcribe.
- It is audible. Fifteen-second incident notes in an open office are fine; the sentence about which vendor you are considering dropping is one to type.
Your first dictated postmortem
You do not need to change the template or convince anyone. On the next incident, do three things. Speak a fifteen-second note into the incident doc each time your understanding changes. When it is over, speak one more: what you want the postmortem to remember. Then, when you write the doc, type the timestamps and numbers, and hold the hotkey for every sentence around them, especially the chain of "because" in the root cause section.
Compare the result with the last one your team published. The difference is not that it is longer. It is that a stranger can read it and understand what happened, which was the point all along. Voice Keyboard Pro is free to try; the next time an alert fires, you already have everything you need to capture what you know while you still know it.