A system developed as a systematic problem solving tool by Taiichi Ohno, the father of the Toyota Production System. Eric Ries has adapted it for the Lean Startup model with a few changes designed specifically for startups.
At the root of every seemingly technical problem is a human problem. Five Whys provides an opportunity to discover what that human problem might be.
When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. For example, suppose a machine stopped functioning:
1. Why did the machine stop? There was an overload and the fuse blew.
2.Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
5. Why was the shaft worn out? There was no strainer attached and metal scrap got in.
Repeating ‘why’ five times, can help uncover the root problem and correct it. If this procedure were not carried through, one might simple replace the fuse or the pump shaft. In that case, the problem would recur within a few months. The Toyota production system has been built on the practice and evolution of this scientific approach. By asking and answering ‘why’ five times, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms.
Note that even in Ohno’s relatively simple example, the root cause moves away from a technical fault (blown fuse) and toward a human error (someone forgot to attach a strainer). This is completely typical of most problems that startups face no matter what industry they are in. Going back to our service business example, most problems that at first appear to individual mistakes can be traced back to problems in training or the original playbook for how the service is to be delivered.
Let me demonstrate how using the Five Whys allowed us to build the employee training system that was mentioned earlier. Imagine that at IMVU we suddenly start receiving complaints from customers about a new version of the product that we have just released.
1. A new release disabled a feature for customers. Why? Because a particular server failed.
2. Why did the server fail? Because an obscure sub system was used in the wrong way.
3. What was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know how to use it properly? Because he was never trained.
5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are ‘too busy’.
What began as a purely techincal fault is revealaed quickly to be a very human managerial issue.
Make a Proportional Investment
Here’s how to use Five Whys analysis to build an adaptive organisation: consistently make a proportional investment at each of the five levels of the hierarchy. In other words, the investment should be smaller when the symptom is minor and larger when the symptom is more painful. We don’t make large investments in prevention unless we’re coping with large problems.
In the example above, the answer is to fix the server, change the subsystem to make it less error-prone, educate the engineer, and, yes, have a conversation with the engineers manager.
This latter piece, the conversation with the manager, is always hard, especially in a startup. When I was a startup manager, if you told me I needed to invest in training my people, i would have you told you it was a wast of time. There were always too many other things to do. I’d probably have said something sarcastic like ‘Sure, I’d be happy to do that – if you can spare my time for the eight weeks it’ll take to set up’. That’s manager speak for ‘no way in hell!’.
That’s why the proportional investment approach is so important. If the outage is a minor glitch, it’s essential that we can make only a minor investment in fixing it. Let’s to the first hour of the eight week plan. That may not sound like much, but it’s a start. If the problem recurs, asking the Five Why’s will require that we continue to make progress on it. If the problem does not occur again, an hour isn’t a big loss.
I used the example of engineering training because that was something I was reluctant to invest in at IMVU. At the outset of our venture, I thought we needed to focus all of our energies on building and marketing our product. Yet once we entered a period of rapid hiring, repeated Five Whys sessions revealed that problems caused by lack of training were slowing down the product development. At no point did we drop everything to focus solely on training. Instead, we made incremental improvements to the process constantly, each time reaping incremental benefits. Over time, those changes compounded, freeing up time and energy that previously had been lost to firefighting and crisis management.
Automatic Speed Regulator
The Five Whys approach acts as a natural speed regulator. The more problems you have, the more you invest in solutions to those problems. As the investments in infrastructure or process pay off, the severity and number of crises are reduced and the team speeds up again. With startups in particular, there is a danger that teams will work too fast, trading quality for time in a way that causes sloppy mistakes. Five Whys prevents that, allowing teams to find their optimal pace.
The Five Whys ties the rate of progress to learning, not just execution. Startup teams should go through the Five Whys whenever they encounter any kind of failure, including technical faults, failures to achieve business results, or unexpected changes in customer behaviour.
Five Whys is a powerful organisational technique. Some of the engineers I have trained to use it believe that you can derive all the other Lean Startup techniques from the Five Whys. Coupled with working in small batches, it provides the foundation a company needs to respond quickly to problems as they appear, without over investing or over engineering.
The Curse of the Five Blames
When teams first adopt Five Whys as a problem-solving tool, they encounter some common pitfalls. We need systems like Five Whys to overcome our psychological limitations because we tend to over react to what’s happening in the moment. We also tend to get frustrated if things happen that we did not anticipate.
When the Five Whys approach goes awry, I call i the Five Blames. Instead of asking why repeatedly in an attempt to understand what went wrong, frustrated teammates start pointing fingers at each other, trying to decide who is at fault. Instead of using the Five Whys to find and fix problems, managers and employees can fall into the trap of using the Five Blames as a means of venting their frustrations and calling out colleasures for systemic failures. Although it’s human nature to assume that when we see a mistake, it’s due to defects in someone elses department, knowledge, or character, the goal of the Five Whys is to help us see the objective truth that chronic problems are caused by bad process, not by bad people, and remedy them accordingly.
I recommend several tactics for escaping the Five Blames. The first is to make sure that everyone affected by the problem is in the room during the analysis of the root cause. The meeting should include anyone who discovered or diagnosed the problem, including customer service representatives who fielded the calls, if possible. It should include anyone who tried to fix the symptom as well as anyone who worked on the subsystems or features involved. If the problem was escalated to senior management, the decision makers who were involved in the escalation should be present as well.
This may make for a crowded room, but it’s essential. In my experience, whoever is left out of the discussion ends up being the target for blame. This is just as damaging whether the scapegoat is a junior employee or the CEO. When it’s a junior employee, it’s all too easy to believe that that person is replaceable. If the CEO is not present, it’s all too easy to assume that his or her behaviour is unchangeable. Neither presumption is usually correct.
When blame inevitably arises, the most senior people in the room should repeat this mantra: if a mistake happens, shame on us for making it so easy to make that mistake. In a Five Whys analysis, we want to have a system level view as much as possible.
Here are a few tips on how to get started with the Five Whys that are based on my experience introducing this technique at many other companies.
For the Five Whys to work properly, there are rules that must be followed. For example, the Five Whys requires an environment of mutual trust and empowerment. In situations in which this is lacking, the complexity of Five Whys can be overwhelming. In such situations, I’ve often used a simplified version that still allows teams to focus on analysing root causes while developing the muscles they’ll need later to tackle the full-blown method.
I ask teams to develop these simple rules:
1. Be tolerant of all mistakes the first time.
2. Never allow the same mistake to be made twice.
The first rule encourages people to get used to being compassionate about mistakes, especially the mistakes of others. Remember, most mistakes are caused by flawed systems, not bad people. The second rule gets the team started making proportional investments in prevention.
This simplified system works well. In fact, we used it at IMVU in the days before I discovered the Five Whys and the Toyota Production System. However, such a simplified system does not work effectively over the long term, as I found out first-hand. In fact, that was one of the things that drove me to first learn about lean production.
The strength and weakness of the simplified system is that it invites questions such as What counts as the same problem? What kind of mistakes should we focus on? and Should we fix this individual problem or try to prevent a whole category of related problems? For a team that is just getting started, these questions are thought-provoking and can lay the groundwork for more elaborate methods to come. Ultimately, though, they do need answering. They need a complete adaptive process such as the Five Whys.
This article is an extract from The Lean Startup by Eric Ries, a book we highly recommend not only for startups, but any business looking to remain agile and innovative.
The cartoon wasn’t in the book. It’s a reminder that this process isn’t simple. Persevere for best results, it’s worth it.