Hacker News Reader

I think you're taking the 5 whys to literally. The plan is not to ask why five times and replace the issue text with the fifth answer, but to take a moment to inspect what actually caused the issue instead of directly trying to fix the symptoms.

Sure, there's a chance that there is no root cause (although, at least in my experience, there usually is a major contributor) or that it's something that's not easy to fix right now, but at least is shows you what issues are brewing below and what you need to put on your roadmap. And, in the best case, you might actually be able to fix a bug higher up the chain directly and resolve future issues.

When we used 5Ys at Uber SRE I always like to say that you are looking for a tree of depth 5 but if it's width 1 you've not tried hard enough. "Root cause" or at least the idea there was a single factor that was the defining feature of an issue is hardly ever true.

There is quite often one symptom that is pivotal and cause a critically failure, but generally that symptom itself is a result of multiple inputs.

I'd simply say 5Ys should be a rule of thumb to get folks to be sufficiently inquisitive to keep asking follow-up questions about whatever they are investigating until they've hit around 5 questions per area.

There is also the concept of ownership, that you are really in total ownership of any situation.

I think the 5 why's should arrive to what part in your circle of ownership does the issue lie.

Hard disagree, I would rather have multiple clear and singular RCAs than any 5Y exercise that is >1 width. Too much context to follow to accurately drill into each cause per an RCA, from my experience.

You end up looking for random causes to increase your tree width, instead of the actual analysis at hand.

As long as you prune branches that don't have action items, what's the problem?

5 why's presents a list of action items, and a justification for them. One action item could depend on two leaf nodes of the RCA, or solve multiple leaf nodes.

> What's the appropriate level of abstraction?

The appropriate level of abstraction is to find the deepest level at which your choices can have an impact. The purpose of the exercise in general is to make sure we aren't investing energy into solving a problem when that problem may manifest in different ways. To use the article's example, addressing the problem of "I get distracted by emails" is insufficient if the subject will just look for other ways to be responsive, thus reducing productivity. There's a deeper level at which they can impact the chain of events, so we want to discover that.

In your example, there's nothing we could really do about "when God first created Man, He also created Temptation..." or "investors are greedy". But we can impact "investors are only interested in a company scaling at a certain rate", since we can provide feedback about how the current processes impact scaling rates. That would be a good starting point.

> The concept of a "root" cause is silly, because the roots of a plant spread far and wide and have many different ends. In the analogy, if the plant is the "problem", and the root is a "cause", then there are hundreds of different roots (causes) that contribute to the plant (problem). People are always trying to assign a single "root" cause as if there is one. Many causes contribute to systemic failures, and often times fixing any one of the root causes would have delayed the failure for another cycle, without actually addressing the procedural risk. Your technician accidentally skipped a step, sure, but he skipped a step because he was in a rush, and he was in a rush because he was overworked, and he was overworked because of those damn sales targets, and... >If we're interested in "root" causes, then we need to end up with a list of several causes that combine to result in the problem. If we only want a single cause, we should call it a "seed" cause, as defined by "this problem (plant) is guaranteed to happen (grow) every time this cause (seed) occurs (is planted)"

I understand what you're saying here, but I feel like you're focusing on the semantics of the argument rather than on its core message.

> The appropriate level of abstraction is to find the deepest level at which your choices can have an impact.

This is a brilliant insight and immediately gave me an “aha” moment on how best to use the 5 Whys approach!

I think the reason Five Whys seems silly to a lot of engineers (or engineer-minded types) is because we naturally progress through the first few whys on our own. Our entire work is basically: "That didn't work—why? Because this function didn't get called—why? Because this if-else branch went the wrong way—why?"

Other fields don't immediately critique facts when presented to them. They're asked to update a model before the 12PM call and the get right on it. Five Whys gives them a framework for pausing, thinking, and critiquing their tasks before they set off on them.

I'll note that the engineer's default criticism isn't always positive: sometimes engineers overly-question and end up derailing the actual work. Critique is important, but sometimes executing according to the plan is more important.

That line of thinking is actually really valuable, here's some insights:

(1) The company has either a sales issue or a pitch issue, if reasonable sales targets can't attract investors.

(2) Investors aren't adequately informed on the space and may not be a good fit for the company, if they're only interested in the company if it scales faster.

(3) Alternatively, if investors are short-term greedy, they may be informed on the space but not see a long-term viable path (in which case, silly of them to be investors, but also, analyze why they're long-term bearish).

(4) What other measures could be indicative of success and worth showing to investors, instead of unreasonably high sales projections?

> What's the appropriate level of abstraction?

I think it's unknowable, but you have to make a guess.

It's exploration, so you don't know if your time investment will pay off. It's like exploring for natural resources: you may discover a lucrative deposit or you may discover nothing. You can't know without trying.

There's no way to tell in advance whether you should spend more effort looking. There's no formula or rule that can tell you the right amount of searching because that would require information you don't have yet.

> The concept of a "root" cause is silly

The concept of ONE SINGLE root cause is silly, but the lesson of looking for root causes isn't that there's exactly one of them. The lesson is that you shouldn't neglect to look.

Fixing the wrong thing is one type of error you can make. One possible cause of it is not looking at enough things. This error happens often enough that watching out for it is good advice.

A couple of ways to improve the 5 Why process that I've seen done in the manufacturing world.

1. Create why sessions with key people in the process. Sometimes answers to why are not always apparent. More people contributing can help illuminate

2. If meeting with a group have a facilitator that has done this before.

3. The group needs to have equal say and contribution. No one, including managers and leaders, can overrule or dissuade discource about the answers to why. Everyone's input is equally important.

You just did a 5 why lol. Interestingly enough, for the plant it took you a while to arrive at the fact that the seed is the true cause of all those plants growing where you don't want them. Next you'd ask why there were those seeds in the field in the first place, and you might realize they're being blown from some other field by the wind. Now you know what to address.

That said, you're right,maybe there are many sources of the seed coming to the field, and in a 5 why you can recognize that, but target the biggest bang for your buck first.

And in your other example:

> Because the sales targets for the enterprise are unrealistic"

> "Why?"

> "Because the Board of Directors can't attract investors with reasonable sales targets"

> "Why?"

> "Because investors are only interested in a company scaling at a certain rate"

> "Why?"

> "Because investors are greedy"

You're just not asking the correct question.

Yes "the sales targets for the enterprise are unrealistic", but why does that result in the issue that happened?

You would want to come out of it with, even when the sales target are unrealistic, our processes are resiliant to the issue that just occurred. So now ask the Why's that take you to this answer.

I essentially stop going down a level when I get to somewhere I can't really control. For example, I'd probably stop at your realization that "investors are only interested in a company scaling at a certain rate". I can't make even narrow changes to investment mentality, so there is no way I'll make such a broad one.

Unfortunately, this often means there is no resolution either.

At three Why’s the branching factor is down low enough that a quick person can guess what many of them are and compare them with the lunch conversation and water cooler gripes and the capabilities of the team and steer toward something - anything - that is actionable and will materially reduce the class of problem - not just the same problem, but ones with any similarity.

I think that’s the best you can do, but it has problems. One, it becomes a bit of smoke and mirrors for people new to the process. Two, this only works for people who have access and recall of all the near misses and any grumbling in the ranks. Optimists cannot do a 5W justice. Three, I don’t trust any Five Why’s that I’m not present for, because there’s a moment in every RCA meeting where if I don’t judo throw the conversation we end up with some milquetoast bullshit fix that doesn’t fix anything or just makes things worse, and writing code more onerous.

...or this:

"I feel pressured to do a job that is impossible and it damages my self worth."

Which means GTFO and get a healthier job.

Yep, I'm on the same boat. I just don't see any resolution that I haven't really thought of by doing this exercise.

I'm not sure "Why" is the right question to ask all the time. Seems like "If the only tool you have is a hammer, you tend to see every problem as a nail."

Instead of root cause analysis as blame laying, look at this as more of an identification of diagnostically important reasons. The above example doesn't help anyone. If code was late, would you accept "our developer is incompetent" as a root cause? Of course not. It's possible that they are, but it's also possible that requirements were not clear or that they took toe long to clarify, which led to a reduced amount of time to do actual development.

In a bigger sense though, the exercise is to force you to take a moment to look beyond band-aid solution, not as an exercise to critique capitalism.