A room for Teams learning after incidents

After the Incident Circle

Look back without blame and turn lessons into owned improvements.

Why this might help

Something went wrong. Maybe a deadline slipped, a system broke, or a customer got let down. Before your team moves on, it's worth pausing to understand what actually happened — and why. The After the Incident Circle helps you look back together without pointing fingers. You'll figure out what the situation taught you, decide who owns each fix, and make sure those fixes actually happen. Think of it like a team debrief after a tough football match: honest, useful, and forward-looking.

Does this feel familiar?

  • Your team just shipped something late and nobody's sure what caused the delay.
  • A mistake happened and people are quietly blaming each other in side conversations.
  • You fixed the same problem twice this month and it keeps coming back.
  • After a rough week, the team moves straight to the next task without ever talking about what went wrong.

Try this together

  1. Set a time within a few days of the incident — memories fade fast, so don't wait too long.
  2. Start the conversation by agreeing on one rule: you're looking at the situation, not at people.
  3. Walk through the timeline together out loud, so everyone sees the same picture of what happened.
  4. Pick two or three things your team can actually change, and name one person who'll own each one.
  5. Write the agreed actions somewhere your whole team can see them — a shared doc, a board, anywhere visible.

Learning Review

  1. Open a new learning review and give it a clear name — something like 'Checkout page outage, 14 June' works better than 'Incident 3'.
  2. Write a short, factual summary of what happened: what broke or went wrong, when it started, and when it was resolved.
  3. List the contributing factors you found — aim for at least three, and keep each one a plain statement of fact.
  4. For each factor, write one specific improvement your team could make, then assign it to one person with a due date.
  5. Share the finished review with everyone involved so the whole team starts from the same understanding.

Questions worth talking about

What was the first moment something felt off, and did anyone notice it at the time?

If this same situation happened again next month, what's the one thing that would make it go better?

Is there anything we assumed would work that we never actually checked?

A few common questions

What if people get defensive during the review?

That's really common. It helps to start by reading the timeline out loud together before anyone gives opinions. When everyone agrees on the facts first, it's easier to talk about causes without it feeling personal. Remind the group that the goal is a better system, not a better scapegoat.

How do we make sure the actions from the review actually get done?

The biggest reason actions get dropped is that nobody owns them. Give each action one name, not a team name. Then check in on those actions at your next regular meeting. Keeping them visible — on a shared board or doc — makes a real difference.

Can Tindlo help us track the follow-up actions from a learning review?

Yes, in a practical way. You can create a work item in Tindlo for each follow-up action, attach the review notes as a file or link, and schedule it on the shared Week view so your team can see what's coming. That keeps the fixes visible alongside your other work, not buried in a separate doc.

Keep the story close to the schedule

A date makes more sense when you can also see the reason, the owner, and the work around it. Tindlo brings those pieces together when a calendar alone isn't enough.

See how Tindlo works →

Where would you like to go next?

Engineering Leadership ExchangeEngineering leadersProduct Operations CircleProduct operations teamsProject Managers' WorkshopProject managers