Yesterday, Harvard Business Review posted a video of Eric Ries (identified as their “entrepreneur-in-residence”) showing how to find the “human causes” of technical problems using the 5 Whys approach.
(I’d embed the video here but I’m not so technically savvy when the code isn’t already provided for me. So to watch the video, click here.)
Anyway, one of the key points Eric brings out is that for technical problems there is typically an underlying human problem that causes it, which he demonstrates using the 5 Whys technique. As a lean practitioner that depends on teamwork, coaching, and collaboration, this is probably the last thing I want to do.
The example he uses in the video (server problem caused by insufficient training) points the finger at the manager for not providing adequate training for the engineer that implements the coding issue. I view the process for identifying the cause in two ways.
One, how do we know that the training was insufficient? Does the process of creating an engineer that is adequately prepared identify what training needs to be completed first? If not, then it’s a process problem in that the standard isn’t created.
And if the process identifies the incorrect training, it’s again a process problem. Does the manager not follow the process? If so, why does he not follow it? What outside force is keeping him from completing it?
And two, we could probably pretty easily say that any and every problem can be traced back to a human cause. Every process is created by humans, so naturally every cause is human made. However, coming to that conclusion is a fruitless and wasteful endeavor because the point is to solve the original problem at the point where the dominoes start to fall. Must we go back to the creator of the elements?
So if you want to make sure “human causes” don’t exist, you must create foolproof processes where human intervention is necessary but not a curse.
And by no means should we point a finger at a person when it’s really the process that’s at fault.