Blameless Root Cause Analyses

You are here:

Blameless Root Cause Analyses

At the conclusion of each project, we will conduct a root cause analysis using the template below. The purpose of these is to identify areas for improvement, as well as wins to make sure to highlight. The team generally works on independent projects and with diverse customer groups, so mutual learning is important to how the Implementation Engineering team lives up to the GitLab values of Collaboration and Iteration.

Conducting a Root Cause Analysis

Agenda

Meeting Purpose

We will not focus on the past events as they pertain to "could've," "should've," etc. However, we can make suggestions for what to do "next time."

We will focus on reinforcing GitLab Values, specifically items such as

Address behavior, but don't label people

People are not their work Always make suggestions about examples of work, not the person. Say, "you didn't respond to my feedback about the design," instead of, "you never listen." And, when receiving feedback, keep in mind that feedback is the best way to improve and that others want to see you succeed.

Directness is about being transparent with each other. We try to channel our inner Ben Horowitz by being both straightforward and kind, an uncommon cocktail of no-bullshit and no-asshole. Feedback is always about your work and not your person. That doesn't mean will be easy to give nor receive it.

No ego Don't defend a point to win an argument or double-down on a mistake. You are not your work; you don't have to defend your point. You do have to search for the right answer with help from others.

Make a proposal If you need to decide something as a team make a proposal instead of calling a meeting to get everyone's input. Having a proposal will be a much more effective use of everyone's time.

All follow-up action items will be assigned to a team/individual before the end of the meeting. If the item is not going to be top priority leaving the meeting, don't make it a follow up an item.