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.
Use the RCA. Changes to that template can be added as an MR to the Professional Services project.
Ensure that the Root Cause Analysis label is applied to the issue
Create a calendar event for the root cause analysis, including a link the issue and this page.
Include the SAL, TAM, IE(s), your manager and any other interested GitLab parties
Conducting a Root Cause Analysis
Each root causes analysis meeting should follow (roughly) this agenda here.
This is a blameless root causes analysis.
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.