Debriefing manual

“To err is human. To repeat error is of the Devil.” — some guy

I will share how we do debriefs at our startup. It is a very short guideline, but hopefully it has the important stuff.

Definition

Debriefs are a tool for extracting insights from suboptimal events.

What to debrief

Here are some examples for events that can be debriefed:

• a prolonged feature request life cycle, from customer to sales through product and to engineering.
• a bug in production.
• a broken main branch.
• a hire that turned out not so well.

Essentially anything that has a high cost and could have been avoided.

Process

The debrief process looks like this:

1. Alice asks Bob to debrief a suboptimal event. Alice is not necessarily Bob’s superior, she’s just someone that saw how things came to be and decided it’s a good learning opportunity. Bob is someone who was not directly involved, otherwise he’s not a good choice for debrief conductor.
2. Bob interviews the relevant members of the team for their count of events, and takes record of what everyone experienced. This is best done in multiple 1:1 sessions to allow each individual to relay their unique perspective and to maximize psychological safety while doing so. Bob aggregates everything under a timeline and sees that there are no contradictions.
3. Bob composes a document with a structure that can look like this: 1. impact — what makes this event important enough to debrief. 2. count of events — factual depiction of what transpired. 3. Conclusions, failure points and recommendations (as needed) — trying to identify recurring pathological patterns and writing recommendations for how to avoid them in the future. He then assigns each recommendation some owner from the team that can pursue it further.

Guidelines

1. A debrief should start only after the event has ended. It doesn’t make sense to invest energy in debriefing while cannos still roam.
2. There doesn’t have to be a conclusion. Don’t write one unless you believe it’s a good one.
3. Sometimes it takes more than one instance of a problem to reach a good conclusion. Feel free to wait with conclusions if that is the case.
4. Humans make mistakes, so a non-constructive conclusion is “Eve should pay more attention” or “Eve’s manager should have instructed her better”. Eve’s abilities and motivations will likely not change by a debriefing recommendation. A better recommendation would be procedural, e.g. “there was no automated test to block Eve’s mistake from impacting production”.
5. The recommendations part of the conclusions must take into account the trade-off between effort of implementation and the risk of recurrence of the bad event. So if we had a bug in production, a non-constructive conclusion would be — “let’s always have 2 reviewers for each change” or “let’s make sure everything has a test”.
6. Keep it short and easy to read, around 1 page or less.

This tool is at your disposal — whenever you want to prevent something bad from recurring, debrief! If you are too involved or prefer someone else to run the process, ping that individual and ask them to do it.

As always keep it simple and factual as possible.

Hope you find this useful.