There is an interrogation technique called Five Whys. I believe it was created by S. Toyoda, and was and very is effective in root cause analysis. The basic idea was to ask a question and follow up with "Why?" until an answer contained an alterable behavior... that answer would usually come with the fifth why. Once in a while I use it in a business meetings, and as long as the person who is being questioned doesn't get defensive or hostile, it is surprisingly effective.
5 Whys is great for getting depth into one causal subtree, but based on a paper I once read, answers can lack breadth when there is more than one cause (which is often the case). It said that "Why" is often best answered with a directed acyclic graph of causal relationships.
(Though when I tried to use a causal DAG for root cause analysis of an incident at my current company, I was told that I was wasting time and no one cares. But I thought the data I found was pretty interesting and worth exploring.)
Similar here. Was pumped in an RCA with "why?" multiple times. The 'root cause' was I fucked up and missed something. But that was because "prod was broken right then, fix ASAP!" and no one else understands the problem, and we're understaffed, and people 'reviewed' the code without understanding what it was doing (or why) and one 'fix' led to another problem, and that 'fix' led to a third, and trying to explain this in an 'RCA' meeting confused the heck out of everyone because there were 3 different days/times people saw the problem, and could not understand it was one original thing that triggered, with cascading problems in the 'fixes', etc.
You keep asking "why?" and only want one 'thing' to be 'actionable'... you will raise my frustration level. The root cause is an emergent property of understaffing, poor communication practices and a belief that everything can be reduced to a jira card providing sufficient context and understanding for a diverse audience with different skills and needs.
In a japanese company that I worked at previously, answering RCA must be clear and in detail way. I got used to it so when I explain something to people, I want them to NOT ask any further question again because I compiled all the information they needed, including prevention. Their next response should be "got it understood" or clarifying their action. Other than that, I think I failed to explain things in a very basic way
> The 'root cause' was I fucked up and missed something.
It's really hard to do RCA when people are blaming themselves. It had to suck to be in that meeting. A really good RCA isn't about finding a single actionable thing, it's about finding our what the root cause of the problem is... which in this case, might have been whatever originally broke production and caused an emergency fix that failed three times.
"It's really hard to do RCA when people are blaming themselves"
Often, the root cause is someone made a mistake. You can say there should have been other systems to prevent/review/etc, but the root cause is a mistake a person made. You can '5 whys' it to death, but I made a mistake (or... someone did).
"whatever originally broke production" - in this case, I made a mistake. That mistake wasn't caught until production. Then the fixes were all broken too.
I don't always blame myself for everything, but if I've made a mistake, I'll own up to it. For me, it helps me be aware of what I can do to avoid those in the future. This may or may not be some rca-checklist other people can refer to, because... it's not 'actionable' to anyone but me.
