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.