Getting Unstuck: The Five Whys

Even though my name is Vince, let me be Frank: There is no one singular “best” troubleshooting methodology. Yes, to the uninitiated, there are methodologies for solving problems. To answer your follow-up question, yes, they’re actually pretty fun. And no, that’s not just me trying to keep you from closing the article.

With my start in the IT world, I’ve had my fair share of troubleshooting computer problems. From not being able to print (printers still suck), to figuring out a network outage (surprise, it’s always DNS), to working with well-intentioned users who misdiagnosed the problem, you’re going to get stuck if you don’t get to the root of the issue.

When you try to fix a symptom, you’re assuming what the real issue is. If you don’t understand the real issue, you might get lucky, but you’re probably going to waste time, money, or both. A simple way to cut through the noise is by using a deceptively powerful exercise: the Five Whys.

In “The Lean Startup,” Eric Ries explains that it’s an “investigative method of asking the question ‘Why?’ five times to understand what has happened (the root cause).” Ries gives an example from Taiichi Ohno (originator of the Five Whys):

  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.)
“The Lean Startup” (p. 230)

Turns out there’s science behind the relentless line of questioning built into every preschooler.

Now, this is a pretty self-explanatory methodology when it comes to mechanical problems. I think that if I tried to put this into my own words, it’d be a pretty redundant and boring second half of the article. Here’s the piece I haven’t seen written anywhere:

Slow down, pay attention, be humble, and THEN ask “Why?”

Paying attention can’t be overstated. Slow down so you’re not reacting on impulse. Practice active listening and document what you hear. If the issue comes in writing, take the time to truly comprehend what you’re reading. That’s how you’ll know which questions to ask.

The why is also not a rhetorical gotcha. Think of it like a story. When you ask why, transport yourself to the perspective of the situation or the person and then try to analyze it from that point of view. For example:

  1. Why did [problem] happen at [account]? [person] didn’t [action]
  2. Why didn’t [person] do [action]? [answer]

The second why is where I can get tripped up. When building arguments, if you have a faulty premise, your conclusion is going to be tainted. The same principle applies here.

If I can truly try to think like the user, imagine myself in their environment, and think about which paths lead me to a certain action or decision, I can then find ways to remove friction and engineer more happy paths to the proper destination.

When the whys start having some meat on them, fight the urge to assume; sip on some humble tea and pay attention. When you ask why, the answers that reverberate back need to be trusted. This is how you’ll prevent yourself from getting stuck and build solid systems.