And on those occasions, it helps to know exactly what happened—so it doesn’t happen again.

Moments like these are when we at Buffer turn to a simple but remarkably effective process: The 5 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 at Buffer—and how it could work for you, too.

The origin of the 5 Whys

The 5 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.”

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 5 Whys has come from The Lean Startup‘s Eric Ries, who does an amazing job describing the 5 Why’s in thesetwo posts.

How the 5 Whys process works

At our startup, we perform a “5 Whys” after something unexpected has occurred—and that means we perform them a lot! I found about 20 “5 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 5 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 5 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 5 whys and learn from it. We let the 5 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 5 main steps to the the 5 Whys.

Invite anyone affected by the issue

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 5 whys meeting. As a remote team, we hold ours via Google Hangout.

Select a 5 Whys master for the meeting

The 5 Whys master will lead the discussion, ask the 5 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 5 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 5 Whys master to take notes for the meeting, unless he or she would like to assign someone else to this.

Ask “why” 5 times

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 5 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 5 whys and discover actionable steps that have been or will be taken.

Assign responsibility for solutions

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.

Email the whole team the results

After each 5 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 5 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:

Some real-life 5 Whys examples

To take the 5 Whys from theoretical to actual, here’s a look at a few moments in Buffer’s history that have called for a 5 Whys meeting.

In early 2014, we had a brief systemwide outage. Here’s a look at the 5 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 5 Whys as a reflection and shared it with the team.

I have learned so much from viewing these examples and being part of 5 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.

The 5 Whys in daily life

Although the 5 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.

So those kids who are always asking “but why?” really ARE on to something!! But you’re right–we have to ask questions to learn and to discover where our motivations, faults, insecurities, and problems lie.

About 3 months ago, we made a very exciting change at Buffer. Upon exploring our current setup as a company, and after Joel’s discovery of a truly transformative book titled Reinventing Organizations, we decided that we wanted to reinvent Buffer taking some inspiration from the book. At its core, we’ve switched to a fully self-managed, […]