Sometimes things don’t go according to plan. Tools break, wires get crossed, the best-laid plans fall apart.
And on those occasions, it helps to know exactly what happened—so it doesn’t happen again.
Moments like these are when we turn to a simple but remarkably effective process: The Five Whys.
It’s just as it sounds: A discussion of the unexpected event or challenge that follows one train of thought to its logical conclusion by asking “Why?” 5 times to get to the root of what happened.
But it’s also a lot deeper than that, too. Let’s take a look at the origin and history of this unique process, and I’ll tell you a bit about how it works for us —and how it could work for you, too.
The Five Whys technique was developed and fine-tuned within the Toyota Motor Corporation as a critical component of its problem-solving training.
Taiichi Ohno, the architect of the Toyota Production System in the 1950s, describes the method in his book Toyota Production System: Beyond Large-Scale Production as “the basis of Toyota’s scientific approach . . . by repeating why five times, the nature of the problem as well as its solution becomes clear.”
Ohno encouraged his team to dig into each problem that arose until they found the root cause. “Observe the production floor without preconceptions,” he would advise. “Ask ‘why’ five times about every matter.”
Here’s an example Toyota offers of a potential Five Whys that might be used at one of their plants.
Today, the method is used far beyond Toyota, and it’s particularly popular in the world of lean development. A lot of what we know at Buffer in implementing the Five Whys has come from The Lean Startup’s Eric Ries, who does an amazing job describing the Five Whys in these two posts.
At our startup, we perform a “Five Whys” after something unexpected has occurred–and that means we perform them a lot! I found about 20 “Five Whys” notes session in Buffer’s Hackpad account. ‘Fires’ of various sizes are inevitable–and probably the only constant in the life of a startup.
We’ve held these discussions in every facet of Buffer, from engineering to happiness to marketing and more, and the same process holds true no matter whether the problem is technical or more human-based. Here’s how Eric Ries explains:
“Five Whys involves holding meetings immediately following the resolution of problems the company is facing. These problems can be anything: development mistakes, site outages, marketing program failures, or even internal missed schedules. Any time something unexpected happens, we could do some root cause analysis.”
It’s important to note that the purpose of the Five Whys isn’t to place blame, but rather to uncover the root cause of why something unexpected occurred. Additionally, it helps a team create small, incremental steps so that the same issue doesn’t happen again (to anyone).
At Buffer, the habit of conducting Five Whys originated from the engineering team. Here’s how our CTO Sunil describes the changes that have resulted from making these a routine part of how we operate:
“What I really like about this is that it lets us worry about issues when they happen, and it helps us work towards ensuring they won’t happen again. At the same time, it lets us not have to worry about issues that haven’t happened. I now trust if something comes up that we didn’t foresee, we’ll conduct a Five Whys and learn from it. We let the Five Whys dictate what documentation we need in place or adjustments to make in our on-boarding process.”
Want to try it for yourself? Here are the five main steps to the the Five Whys.
As soon as the problem or situation is identified (and all immediate concerns are dealt with), invite anyone at all on the team who was affected or noticed the issue to be involved in a Five Whys meeting. As a remote team, we hold ours via Google Hangout.
The Five Whys master will lead the discussion, ask the Five Whys and assign responsibility for the solutions the group comes up with. The rest of those involved will answer those questions and discuss.
In our experience, anyone can be a Five Whys master—there are no special qualifications, and it doesn’t have to be the leader of the project or the originator of the issue. We’ve also found that it’s a good idea for the Five Whys master to take notes for the meeting, unless he or she would like to assign someone else to this.
Dig at least 5 levels deep into the issue with 5 levels of “whys.” This seems like the simplest part, but can in fact get a bit tricky! Getting the right question to start with, the first why, seems to be the key.
When we conduct our Five Whys, it can feel natural and almost beneficial to go down all potential paths and be really comprehensive. However, this can widen the scope of how much learning and corrective actions needs to occur. This is meant to be a ‘lean’ process in which picking one path allows us to perform just the amount of corrective actions needed to solve a problem.
We often have to tell ourselves we just need to pick one and go with it. If the same problem seems to occur again, then we can do another choosing the other route.
Together, we work through each of those Five whys and discover actionable steps that have been or will be taken.
At the end of the exercise, we go through each why question-and-answer pairing and come up with 5 related “corrective actions” that we all agree on. The master assigns responsibility for the solutions to various participants in the discussion.
After each Five Whys process, someone involved in the meeting will write down what was discussed in the clearest, plainest language as possible. Then we add it to a Hackpad collection and—in one of the most important steps of the whole process–email the whole team with the results.
This makes sense to do, and not just for a company like Buffer that focuses on transparency. It’s super useful for everyone on your team to stay in the loop and understand any steps you’re taking as the result of a Five Whys.
Eric Ries explains why the email is so important:
The advantage of sharing this information widely is that it gives everyone insight into the kinds of problems the team is facing, but also insight into how those problems are being tackled. And if the analysis is airtight, it makes it pretty easy for everyone to understand why the team is taking some time out to invest in problem prevention instead of new features. If, on the other hand, it ignites a firestorm–that’s good news too. Now you know you have a problem: either the analysis is not airtight, and you need to do it over again, or your company doesn’t understand why what you’re doing is important. Figure out which of these situations you’re in, and fix it.
Put it all together and the process looks like this:
To take the Five Whys from theoretical to actual, here’s a look at a few moments in Buffer’s history that have called for a Five Whys meeting.
In early 2014, we had a brief systemwide outage. Here’s a look at the Five Whys the team conducted:
And the corrective actions that resulted:
Here’s an example from the customer happiness world. One of our Happiness Heroes wanted to understand how he might have handled a customer’s problem better, so he performed a modified Five Whys as a reflection and shared it with the team.
Five whys supportI have learned so much from viewing these examples and being part of Five Whys processes. It’s been great to develop a habit of reflecting anytime something unexpected happens and taking incremental steps so that we change what happens the next time around.
Although the Five Whys is most widely used for manufacturing/development use, I’ve found that it is also quite applicable to daily life in any situation where one might seek deeper understanding—of a problem, a challenge or even a motivation behind an action.
This quick graphic from Start of Happiness provides a great example:
Ever since learning about the Five Whys, I find myself asking “why?” a lot more often.
What sort of process do you use to get to the root of unexpected situations or challenges in your work or life? Have you ever tried the Five Whys? I’d love to hear your insights in the comments!
This article originally appeared on Buffer and is reprinted with permission.