The 5 whys – and why do there need to be 5 of them?
An employee at my company (10gen, the company behind MongoDB) sent me this link to a video of Eric Ries talking about the “5 whys” and how technology problems are often people problems.
For those of you not familiar with the notion of “5 whys”, the idea is to ask why 5 times until you get to the root cause. While I think asking why and finding root cause can be important, a few issues jump out at me: first, why do you need to ask exactly 5 times? Second and perhaps more importantly, when there are multiple answers to a given why, which one do you follow for further investigation.
In the example Eric gives, they start with a server crash and end with a manager who doesn’t believe in training. I would argue this is an attempt to reduce technical management to something that general managers reading Harvard Business Review can do, which is dangerous.
What really needs to be asked? The first why is straightforward.
1. Q: Why did the server crash?
A: There was a bad call to some new API
Now what’s the root cause? Is the problem with the API or the program that called it? Is it a problem of programmer competence, communication, or training? Or is it an architecture problem which is actually bigger than this specific API usage? Was the problem in design, implementation, testing, or documentation? Was it a process problem, a training problem, or a hiring/management problem? I don’t think 3 or 4 more whys will mechanically answer that. One or two more whys might answer it, but the key is focusing on the right areas.
What technical manager at a startup really thinks that training will prevent a developer from calling an internally developed API incorrectly in a way that causes a crash? Its not impossible, but I think pretty unlikely. Better API docs could help, and better communications could definitely help. Or a more robust API, or more thought about whether that API needs to be public if it can’t be made more robust, or broader test coverage…
I think a better policy might be “2 or 3 whys, but the right ones”. I don’t think it will catch on as a management slogan, but I think it is more likely to yield useful answers.
— Max
Max Schireson's blog 
My wife once pulled the “5 whys” on me to get me to state “I thought this way about this issue because I was passionate about (programming)” I don’t remember what the issue was exactly, but it probably was about a boss or coworker not getting it or having a wrong outlook.
In that regard, they were 5 loaded whys, asked to me to elicit specific answers and a specific emotional response. In other words, it was a Socratic counseling.
From that experience and the resulting reflection upon it, I think that “5 why’s” can be useful in two situations:
1. Someone opposes me and they very tunnel visioned based on a core belief (e.g. this part of the code needs to be rewritten for speed, management has to find a way to justify the cost). I need to make them articulate that instead of what they abstracted that belief to to support their argument (e.g. I don’t think we should force the client to buy a bigger server). Once I get them to state their original belief, I can lead them down a Socratic dialog to establish what they think the cost of a rewrite is, and to lower the ceiling of “no matter the cost” to something tangible like “1% of our budget for the quarter”
2. A variant of the first, someone has drawn their line in the sand, and I don’t know why. So I ask a quick successive series of why’s, the fifth one leading to an emotional stated core belief, and then I can frame a Socratic discussion from there, or possibly decide I’m wrong and he’s right.
As to branching when why has multiple answers, I think the idea is to simplify the problem, and if the problem really has multiple root causes, the technique won’t work. You can’t use 5 why’s to balance the federal budget. You can use 5 whys to break an impasse over a single line item.
So now to answer why its always 5 whys. I don’t know, but I assume that when Sakichi Toyoda of Toyota developed the process he felt 5 was deep enough and that if the problem was superficial one could solve whys 1-4 as opposed to why 5. I also think that 5 is deep enough for most things that come up in manufacturing engineering. When used as a psychological or organizational behavior tool, as in my examples, I think 5 whys a rule of thumb for eliciting an emotional charged brutally honest response (getting their guard down) without getting them angry enough to revert to the reptilian instinctual parts of their brain (pissing them off to the point that further dialog is impossible).
All that being said, the engineer in me says 5 is probably a padded number, and one can assume that in practice the third or fourth why is the one you need to fix.