Item — HN Reader

An EVP of Ops of a fortune 500 did this to an entire room of functional experts.

We were there to discuss a technical implementation.

She kicked it off by saying "Let me start by asking a simple question, why do we do this function?"

I am now considered a domain expert. I love this question. It surprises me at how few people start with the why, or even can articulate the why.

The room of experts, were assembled to roll out a new product in their area of functional expertise. None of us had an articulate answer as to the why. She kept on asking. She gently challenged bad answers with a follow up why. Then when everyone gave up, she gave her answer as to the why. It was brilliant.

Always start with the why. Then ask why again. Keep on asking until you understand why.

3 comments

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.

Regarding the lack of breadth of a 5 whys analysis, there is a fishbone diagram that can be used before the 5 whys to ensure more breadth.

In manufacturing there is usually 4 big topics (person, machine, material, method), but there are many variations that can be used.

Trees or other visual depictions can be used too.

The point is to have some sort of structure and adapt it to your needs.

If it was just a setup to eventually providing an answer she already had in her pocket, is that the same thing really that's being discussed? Willingness to look stupid and earnestness to find an answer?

Sounds a bit like the Socratic method [1], just used for making sure everyone is aligned with the fundamental goals.

As someone who's recently been put in a position to make sure everyone's aligned (and failing quite a bit at it), it sounds like genius, in my opinion.

[1] https://en.wikipedia.org/wiki/Socratic_method

It doesn't seem like the same thing as asking dumb questions to uncover the truth that nobody has yet synthesized.

When you already (think you) know the answer, then it's a pedagogical technique. That's ok unless you happen to be wrong about the answer.

The Socratic method is where they eventually realize the answer, not one where you make them all feel frustrated before finally revealing it.

Wielded w/o skill, the Socratic Method comes of patronizing and trite.

To stay respectful, it is polite to negotiate with all participants in its use.

To be fair, Socrates' goal was to make them realize they didn't actually have the answer, they only thought they did.

I assume frustration levels for both come down to the soft skills used to run the process.

I like to assume everyone has a positive intent, until proven otherwise.

I always ask people why, because I sometimes learn something new, I often learn about the knowledge level of the other participants, and it anchors everyone to the fundamental problem we are trying to solve.

It may be that along the course of asking why 10 different times from different people she was able to identify the answer. It sounds like she got quite a few fragments of answers first.

sometimes I go straight into technicalities for the sake of time (to colleagues at the same level) and wonder if they actually understood what i said.

I like it when they ask basic questions. at least then I can then explain the basics to them without having to feel like I'm patronizing.