Why our retrospective template doesn't ask for root cause

This blog post is based on a webinar I conducted; you can find the recording here.

I’ve built and run incident programs for more than ten years at Braintree, PayPal, and Chime. The failure I’ve seen most often isn’t a missing retrospective. It’s a retrospective that got filled out and never read. Every box has something in it. The action items are filed. Six months later the same incident happens again, and nobody can point to that document and say it changed how we work.

The template is a big part of why. It decides what people think about. A field labeled “Root cause” gets you one sentence, and (gasp) sometimes a person’s name somewhere in it. A field that asks what conditions had to be true for the incident to occur gets you something you can use.

So when we built the Rootly Retrospective Template, we started with a test. Hand the retrospective to an engineer who joins your team six months from now. Would they understand what happened, why it made sense to the people involved, and what the organization knows now that it didn’t before? If yes, it’s a good retrospective. If all they get is a timeline and three Jira tickets, it’s a receipt.

Here are the seven sections and why each one is there. Every section comes with help text so you don’t have to write the questions yourself. I’ve added suggestions that I ask out loud in the review meeting to push it even further.

1. Key information

This section holds the incident ID, severity, affected services, and the detection and mitigation times. The rule here is that nobody should ever type a timestamp. Rootly fills the section from incident data with Liquid variables, and that matters more than you’d think. Every minute an engineer spends copying metadata is a minute they aren’t spending on thinking. Let the machine keep the record so people can do the reasoning.

2. What happened

This section is a narrative written by the responders, and it asks for the wrong theories and dead ends too. If your team spent 40 minutes on the database when the problem was DNS, that tells you something about your observability and your mental models. The dead ends are where the learning is.

The help text asks responders to tell the story from inside it: what they saw and knew at each point, and what made sense to do and why. Hindsight makes every choice look obvious, and this section’s job is to undo that. In the meeting I push one step further and ask “What made that decision seem reasonable in the moment?”

3. Impact

This section covers who was affected, how badly, and for how long, quantified and not spun. If you catch yourself writing “some users may have experienced degraded performance,” stop and say what it was. “4,200 customers couldn’t log in for 38 minutes” is a sentence leaders can trust, and honest impact statements are what keep them trusting the process. If you don’t have the hard numbers, that’s a sign you need better logs.

4. Contributing factors

This is the biggest change from the traditional format, and the plural is on purpose. Real incidents almost never have one root cause. Several things had to line up: a config change, a missing alert, an out-of-date runbook, a Friday deploy, an on-call engineer three weeks into the job. Take away any one of them and maybe there’s no incident.

Asking “why” five times usually stops at a person. Contributing factors keep you looking at the system. The help text asks what usually catches this class of issue and why it didn’t this time. When the room goes quiet, I ask “What else had to be true?” Keep asking until the answers stop being technical and start being organizational. Staffing, priorities, deadlines, and who knew what are usually the factors that matter most.

5. Learnings

This section includes what went well, and we give it the same weight as what went wrong. Your ability to respond is something you can study and strengthen. Somebody on that bridge call almost certainly did something smart that isn’t written down anywhere.

The help text points at what limited the impact or sped up the response, and at risks like key-person dependencies. I ask that last one directly: “Where did someone’s expertise save us that we’d lose if they left?” That answer is a risk you didn’t know you had, and it’s also something worth reinforcing.

6. Follow-up actions

Every action gets an owner, a date, and a priority. My opinionated take is that fewer is better. Five actions that get done beat fifteen that rot in a backlog. Not every learning has to become a ticket, either. Sometimes the output is that three teams now understand the payment service better, and that counts.

7. Appendix: timeline

The timeline goes last. It’s the record, and the narrative is the thinking. Open with 60 timestamps and the thinking gets buried. Rootly builds the timeline for you, so it can sit in the appendix until someone needs it.

Going further than the default

The template is a starting point. Once your team has used it a few times, three changes will get you more out of it.

Tier your retrospectives. One template for every incident means your SEV1s get too little attention and your SEV4s get too much process. I think in three tiers:

• Light. A few paragraphs, written asynchronously, for low-severity incidents and near misses.
• Medium. The full template plus a short review meeting.
• Heavy. The full template, a facilitated session, and 1:1 interviews with responders, for the incidents that really hurt.

Rootly’s retrospective processes can route incidents to different templates by severity, team, or incident type. Liquid conditions can show or hide sections, so an executive summary can appear only for SEV1 and SEV2 incidents. Match the effort to what’s at stake and people won’t learn to resent the process.

Write help text as questions for the sections you add. The built-in sections already have help text, so keep it. When you add your own section, write its help text the same way. “Describe customer communication” gets a sentence. “What did customers hear from us, when, and did it match what we knew?” gets a real answer.

Add a block for what you still don’t know. My favorite custom block is “Open questions: what we still can’t explain.” A retrospective that claims to understand everything is usually wrong. Writing down what’s unresolved is more honest, and it’s often where the next incident comes from.

Where AI belongs in a retrospective

The retrospective document isn’t the product. The learning is, and learning happens in people’s heads. It comes from the work of reconstructing what happened and arguing about why. If AI does that work for you, you get a polished document and an organization that learned nothing.

Here’s the short version of my view: AI is excellent at recall and should never be trusted with meaning.

Here’s where I’d use it without hesitating:

• Timeline curation. Pulling the key moments out of a 400-message Slack channel and a two-hour bridge call is grunt work people are bad at.
• A first draft of what happened as a memory aid. Rootly reads the incident data, the Slack channel, and the bridge transcript, so it remembers what responders have already forgotten.
• Catching dropped action items. Ask @Rootly in the incident channel to find actions that were promised but never logged.
• Answering questions about the incident. When did the error rate first climb? Who approved the rollback? Treat it like a research assistant.
• A second read on blameless language. The template’s AI instructions tell it to use roles instead of names and to separate what’s confirmed from what’s suspected.

And here’s where I’d keep it out, or on a short leash:

• Contributing factors and learnings as conclusions. AI only sees what was written down. It doesn’t know what was said in DMs or what was in the on-call engineer’s head at 3 a.m. The most important factors are often the ones nobody typed.
• Deciding priorities. Which follow-up matters most depends on your roadmap, your risk appetite, and your politics. People make that call.
• Replacing the conversation. If your retrospectives get published an hour after resolution with no meeting, you’ve automated the one step that mattered.
• Explaining why a decision made sense. Only the person who made it can tell you. Ask them.

How to set it up so the draft starts the conversation

The rule I give teams is that the AI draft opens the discussion. It doesn’t settle it. Five habits make that work in Rootly.

1. Start from the defaults. Each built-in AI block already ships with instructions that ask instead of answer. The Contributing Factors block separates confirmed factors from suspected ones and turns gaps in the evidence into open questions. The Learnings block proposes candidates for the team to confirm, reject, or refine. The Follow-up actions block marks an owner as unconfirmed unless someone volunteered.
2. Add guidance on top. Instructions you add stack on top of the built-in rules instead of replacing them. Use them for what’s specific to your team, for example “Don’t rank the factors.” Or add a custom block that lists the questions the retrospective meeting needs to answer, so the AI sets the agenda instead of writing the outcome.
3. Check the sources. Every AI block shows its prompt and the incident context it drew from. If a claim doesn’t trace back to something real, delete it.
4. Don’t publish an AI block nobody argued with. Make it a team norm. The draft is a proposal to push back on.
5. Use the thumbs up and down. That feedback goes into how we evaluate output quality.

Watch for three signs that AI is doing too much: every retrospective sounds the same, every contributing factor is technical and none are organizational, and follow-ups appear that nobody remembers agreeing to.

Start with the template, then make it yours

Take three things from this:

1. Build templates that ask questions. The structure decides what people think about, and the help text does the teaching.
2. Match effort to what’s at stake, so people don’t come to hate the process.
3. Let AI handle recall and let people handle meaning.

The Rootly Retrospective Template is in your template list now. Start using it as-is, or add your own questions to tailor it to your company’s culture.

Read how to configure retrospective templates or watch the webinar recording.