The Incident Review That Changes Behavior (And the Kind That Wastes an Hour)

Last updated: September 3, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

An incident review changes behavior when it ends with three things: a written timeline of what people actually knew, action items carrying a named owner and a date, and no defendant. The rest of the template exists to make those three things happen.

I wrote a sentence a few years ago that I have been arguing with ever since.

It was about giving engineers room to make their own calls. Nine times out of ten the reasoning is sound and I learn something, I said, and the tenth time becomes a coaching conversation, not a postmortem. That line got quoted back to me more than anything else I have written. Somebody put it on a slide.

It is also wrong. I knew it was wrong while I was typing it.

What I meant was that the postmortems I had sat in were bad. Blame in a Confluence page. A director asking who pushed the change, in that voice. Forty minutes of extremely careful hedging by seven engineers who had already settled in a Slack DM what they were and were not going to say out loud. I sat in enough of those that the word itself curdled on me, and by the time I typed that sentence I was using it the way you would use any other word for a thing you had given up on.

Then we lost the rate-lock service on a Tuesday morning, in the middle of a rate drop, for a little over three hours. Worst possible day. The review we ran afterward was polite, thorough, well attended, and produced one Jira ticket that nobody was assigned to. The ticket sat. Five months later a different service failed the same way, for the same reason, and I got to watch a room of good engineers rediscover a lesson they had already written down and filed.

What a Postmortem Template Is Actually For

A postmortem template is a fixed set of prompts a team fills in after an incident: timeline, customer impact, how it was detected, how it was recovered, what conditions contributed, and the action items. Its job is to stop the meeting from turning into a memory contest, and to make this incident comparable to the last one.

The container does not run the meeting. That is the part people keep hoping to buy.

Which is why searching for a postmortem template returns page after page of free downloads, and why so few engineering organizations get anything out of the one they picked. You can run a genuinely terrible review inside Atlassian’s template. I have. The document came out immaculate.

I spend a fair amount of time alongside the engineering staffing agency side of KORE1, and the problem shows up there in a very specific shape. A VP asks for two more site reliability engineers. Two questions in, the real situation is that their last eleven incident reviews generated forty-one action items and closed nine of them, and the same class of failure has now happened three times. That is not a headcount problem yet. It might become one. It is not one today.

The Template I Actually Use

Nine sections. Fits on one page if people are honest and two if they are not. The right column is the part that matters, because every section exists to prevent a specific failure I have watched happen.

Notice what is not on it. There is no field for who caused the incident. No severity debate, because severity gets set during the incident and relitigating it afterward is a status exercise. No five whys, for reasons I will get to.

Copy the table. Put it in Confluence or Notion or a markdown file in the repo. I genuinely do not care which. The tooling has never been the variable.

Where the Hour Goes

Nine people in a room for sixty minutes, half of them senior, costs somewhere north of a thousand dollars in loaded time before anybody has written a sentence. Add prep. Add the two engineers who spent Thursday afternoon reconstructing a timeline from Datadog. Every organization I have worked in has been willing to spend that, repeatedly, on a meeting that nobody could connect to a single change in how anybody behaved.

Four things eat the hour.

The memory contest. No timeline was assembled in advance, so the first twenty minutes are eight people disagreeing about when the alert fired. This is entirely preventable and it happens constantly. Assign the timeline to one person the day of, while the Slack scrollback is still fresh, and hand it out before the meeting rather than building it live.

The defendant. Somebody in the room is on trial, and everyone can feel it, including whoever is running the meeting and insisting that it is blameless. Amy Edmondson has been putting a version of this question to executives for years. Asked what share of the failures in their organization are genuinely blameworthy, they say two to five percent. Asked what share actually get treated that way, the same executives say seventy to ninety. Her point is that the gap is where the learning goes to die, because failures that will be punished simply stop being reported.

The single root cause. Five whys is a fine tool for a manufacturing line where the causal chain is physical and short. Distributed systems do not fail that way. They fail when four conditions that were each individually tolerable happen to line up on a Tuesday, and picking one of them and calling it the root is a decision about who to talk to next, not a finding. The Verica Open Incident Database has now cataloged thousands of public incident reports across hundreds of companies, and its central argument is that the industry’s attachment to a single root cause makes reports shallower rather than sharper. In the analysis of the early corpus, only about a quarter of reports even identified one, and near misses, which cost nothing to study because nobody is on fire, made up well under half a percent of the collection.

The document nobody opens again. This is the one that hurts, because the work was already done. Somebody wrote a genuinely good analysis and then filed it in a Confluence space with two hundred other pages, and the next team to hit the same wall has no idea it exists. The search never finds it. Nobody links to it.

Blameless Is a Design Constraint, Not a Mood

Most leaders I talk to treat blameless as something you achieve by being nice about it. You say the words at the top of the meeting, you mean them sincerely, and then you run the exact same meeting you ran last quarter.

It does not work. People read the room, not the preamble.

Google’s SRE practice is the most useful reference here, and the useful part is not the philosophy. It is that they made the whole thing structural. Postmortems are triggered by written criteria rather than by someone’s judgment about whether this one was embarrassing enough: user-visible degradation past a threshold, data loss of any kind, an on-call engineer having to intervene, a monitoring failure. Any stakeholder can request one. Senior engineers review the drafts against a fixed rubric. There is a Postmortem of the Month. Peer bonuses go to people who write good ones.

Read that list again and notice what is being engineered. Writing an honest account of your own bad day is made into the highest-status thing you can do that week. That is a compensation and recognition design, not an attitude.

DORA’s research lands in the same place from a different direction. The culture measure they use comes from Ron Westrum’s work on aviation and healthcare safety, and the thing that separates a generative culture from a pathological one is what happens after something breaks: inquiry, or scapegoating. It predicts delivery performance. It also predicts whether the second incident of the same type ever gets prevented, which is the only thing I care about on a Tuesday.

Three constraints do most of the work, and none of them require anyone to be a better person.

The person closest to the change does not present. Somebody else walks the timeline. This one change does more than every other thing on this list combined, and it costs nothing.

The facilitator is not the incident commander, and is not in that person’s management chain. We rotate the job every quarter. Junior engineers turn out to be unusually good at it, because they ask the obvious question that everyone senior has silently agreed to skip.

Executives get the writeup, not a seat. I have broken this rule myself, walked into a review because I was curious about the failure, and watched the whole conversation change shape within about ninety seconds of me sitting down. Not one person in that room did anything I could have named as wrong. I was the most expensive person present and everybody adjusted to it without noticing they were doing it.

Action Items That Survive Monday

Here is where most of the value leaks out, and it is the cheapest thing to fix.

Three action items. That is the cap. Eleven action items is a way of avoiding the decision about which two things actually mattered, and a list of eleven closes at roughly the same rate as a list of three, which is to say the three get done and the other eight decorate a backlog for a year. Cap it and you force the prioritization to happen in the room, in front of the people with the context, instead of six weeks later in a grooming session with none of it.

Each item needs one human owner. Not a team. Not a squad name. A person, who was in the room, who said the word yes out loud. Decision ownership is the thing I end up drawing on a whiteboard in almost every struggling org I walk into, and incident action items are where the absence of it is most visible.

Each item needs a date and a home. If it does not land in the next sprint, somebody with authority defers it explicitly and puts their name on the deferral. Deferring is fine. Deferring silently is how the rate-lock ticket sat for five months.

Some of these are not sprint work at all. They are funding requests wearing a ticket, and how you write them decides whether they ever get paid for, which is the argument in why tech debt is the wrong frame to take to an executive.

And each item names the condition it removes, in one line, pulled straight from the contributing conditions section. If you cannot write that line, the item is not an action item. It is a feeling about the incident.

Then watch whether any of it moves. Not the count of postmortems completed, which measures compliance. Change fail rate and recovery time are the two that actually answer the question, and they are in the four delivery metrics that hold up under executive scrutiny. If a year of reviews has not moved either one, the ritual is decorative and you should either fix it or stop paying for it. Show me the data or stop booking the room.

The Sixty Minutes, in Order

This is the agenda. It fits in an hour if the timeline was written beforehand, and it does not fit in an hour if it was not, which is most of what determines whether these meetings work.

Minutes 0 to 10. Read the timeline aloud. Slowly, by somebody who was not at the center of it. People correct their own recollections when they hear the sequence, and they correct them without being challenged, which is a very different experience from being asked to explain themselves.

Minutes 10 to 25. Detection and recovery. How did we find out. What did we try that did not work. What finally did. The dead ends belong in the document. They are the map for whoever hits this at 3 a.m. next quarter.

Minutes 25 to 40. Contributing conditions. Plural, always. The question is never why did this happen. What made this possible is one question. What kept anyone from noticing for nineteen minutes is a completely different one, and why the fix still took ninety minutes after somebody did notice is a third. Teams answer the first one and go to lunch.

Minutes 40 to 50. What went right, and the near miss. Both. Skipping the first is how organizations quietly delete the alerting that saved them. Skipping the second is how they conclude that a three-hour outage which came within one failed retry of corrupting a ledger was a three-hour outage.

Minutes 50 to 60. Three action items, owners, dates. In the room. Names said out loud. Nobody leaves until the three are written down where the whole team can see them.

Then somebody has to actually read these later, which is the last piece and the one I have never seen a tool solve. We do a thirty-minute reading club once a month. Old writeup, no agenda, no action items, just engineers reading something that happened to someone else and arguing about it. Google runs a version of this too. It is the cheapest training I have ever run and I have never once had trouble getting people to show up.

When the Review Keeps Finding the Same Thing

Sometimes you run this well for two quarters and the reviews keep converging on conditions you cannot fix at the review level. Ownership boundaries that put one team on the hook for a service they did not build. A platform group that is really a ticket queue with a new name. One person who is under the hood of four systems and cannot be in two incidents at once.

That is an org design problem wearing an incident costume. No template touches it. Mine does not either. This is the failure mode I get called about most often. The reviews are honest, the action items get done, and the same class of failure keeps arriving because the structure underneath it never changed. KORE1’s engineering org design and operating model advisory practice exists for exactly that conversation, and the engineering velocity diagnostic is the faster version if you want a read on where the constraint actually sits before committing to anything. If it turns out you genuinely are short a person, KORE1 averages 17 days to fill an IT role and runs contract staffing for the cases where you need coverage before you need a permanent hire. And if the honest answer is that your operating rhythm is the problem, I have written at more length about defending the boring work that makes engineering velocity possible.

I am happy to argue about any of the nine sections if you think one of them is doing less work than I claim. Connect with me on LinkedIn, or talk to a KORE1 recruiter if the gap you found turns out to be a people gap after all.

What Engineering Leaders Ask Me About Incident Reviews

Which incidents actually earn a full review?

Four triggers cover it, written down in advance so that nobody is deciding case by case in the moment. Customer-visible degradation past a threshold. Data loss of any size. On-call intervening by hand. A monitoring gap that meant a person found it before your alerting did.

The reason to fix the triggers in writing is not thoroughness. Discretionary reviews get skipped exactly when they are most needed, because the incidents nobody wants to write up are the embarrassing ones, and the embarrassing ones are where the learning is. One more rule belongs on that list. Anybody can request a review of anything, near misses included, and nobody has to justify the request to get one.

Blameless sounds great until someone is genuinely careless. Then what?

Then you have a performance conversation, and it is not this meeting. The review looks at conditions and never at people. Performance is private, handled by that engineer’s manager, on a different day.

Collapsing those two things is the single most common way leaders wreck their own review process, and it usually comes from a good instinct about accountability. Here is the test I use. If a competent engineer with the same information, the same tooling, and the same time pressure would plausibly have done the same thing, it is a systems finding. If not, it is still a systems finding for the review, and a separate management conversation on Thursday. In twenty-five years I have had that second conversation maybe four times. Four.

How do we stop generating action items that nobody ever does?

Cap the list at three and give each one a person’s name and a date, this week, before you change anything else. Almost every other fix is downstream of that one.

Then go back through the last six months of writeups and close the open items honestly. Some are done and nobody updated the ticket. Some will never be done and should be killed on purpose rather than left to rot. That cleanup is unglamorous and takes about an afternoon. What it does to whether people believe the next review is real is out of all proportion to the effort.

Should the person who caused the outage write the document?

They should write their part of the timeline. Somebody else assembles and presents it. That split gets you the detail only they have without the performance of self-defense that comes with standing up and narrating your own worst afternoon.

Google goes further and rewards writeup quality directly through peer bonuses and internal recognition, which turns authorship into a status win instead of a penance. Most companies cannot copy that mechanism outright. Most companies can copy the smaller version, which is that whoever writes it gets named and thanked in the channel where the incident was handled.

Realistically, what does this cost per incident?

About three hours of one engineer’s time to build the timeline and draft the document, plus one hour times the number of people in the room. For a serious incident that is most of a day of organizational attention.

Which is why the trigger list matters so much. Run this on everything and it becomes a tax that people start quietly evading. Run it on the incidents that meet the written bar, with a timeline prepared in advance, and it is one of the highest-return hours on an engineering calendar. Run it badly on everything, which is the common case, and you have built an expensive ceremony that produces documents nobody reads.

Do we need a dedicated postmortem tool?

A page template and a calendar invite cover it for most teams under about two hundred engineers. Tooling helps with the part nobody shops for, which is finding the writeup from eighteen months ago that describes your current outage.

If you do buy something, buy it for search and for linking incidents to each other, not for the form. The form is free and it is in the table above. I have watched teams spend a procurement cycle on incident tooling while still running the meeting that produced eleven unowned action items, and the tool inherited the process exactly as it was. Nothing changed. It was just better indexed.