Three Problems You Can Solve With a Modified "Five Whys" Approach

By: March 31, 2016

The "Five Whys" approach is a technique that's generally used to determine the root cause of an incident. It's done by taking a symptom of the problem, and repeatedly asking “why?” until you get to the root cause.

So why did I modify this classic approach? Well, it's because you don't always have to ask the single-word question "why?" to get to an answer. In fact, you can solve different classes of problems by implementing the same general pattern of going down through the layers of logic to get at some kernel of truth that is more valuable, actionable and accurate.

Now, let's take a look at three different situations where you can apply this problem-solving tactic.

1. Are You Monitoring The Right Things?

Building software for the Internet is challenging, and keeping your site available for users at all times is absolutely critical. However, there are times when teams can get a little too obsessive about what’s monitored and the priority of different classes of alerts. Down the line, they might find themselves feeling frustrated and in a pager-induced haze caused by lack of sleep – which is typically due to the number of times they woke up at three a.m., only to find the issue already resolved itself by the time they finished rubbing the sleep out of their eyes.

Sure, in some of these cases, thresholds set a year ago are no longer where they need to be based on growth. In some cases, there’s a service that’s actually flapping and needs real attention. But it helps to ask questions: Does the alert need to exist? And if it does, should it wake you up at three a.m.? 

To help you figure it out, here's how you could use the "Five Whys" approach: 

Complaint: “We keep getting ‘disk IO utilization’ alerts on this host that wake us up and then resolves themselves a minute later!”

Why 1: “Why do we need this alert?”

Answer 1: “Because this important service is on this node, and it’ll slow down or maybe become unavailable if 'disk IO utilization' is too high.”

Why 2: “Why is that service so important?”

Answer 2: “Because it provides data via an API endpoint to the customer, so if it goes down, the customer experience is bad.”

Why 3: “Why is there only one node providing that service instead of having a pool for redundancy?”

Answer 3: “There already is a pool for redundancy.”

As you can see here, the point of "Five Whys" isn’t necessarily to ask “why?” five times. It’s simply a method that can help ensure you’re focused on the right thing and headed in the right direction. If you have to ask the question six times, fine. Usually, though, you'll begin to realize something's amiss in your approach, or something important hasn't been considered, before you get past the second or third "why."

In the case above, after asking “why?” just three times, the conversation should quickly turn to something like, “Well, if there’s redundancy here, and we already have an alert to let us know the whole node is gone, what’s this IO check buying us?” Soon there’s a realization that your pager or smartphone is being relegated to acting as a debug log – giving you low-level information you should be able to easily discover when you’re alerted to an actual higher-level problem.

From this point, you can take action. You can either remove the alert, or you can have it report to a common "Alerts" inbox that gets scanned daily by the on-call person. Or, you can just lean on the monitoring system’s UI to get some quick context if the actual node becomes unresponsive.

2. Are You Setting Good Goals?

A good goal is one that is well-defined, and has the ability to be evaluated in terms of completion in a binary way. It should also be ambitious; I try to set goals to achieve something at some later point that, right now, I’m unsure I have the ability to achieve at all. When you achieve that kind of goal, there’s a great sense of satisfaction, confidence, achievement and growth.

For example, a developer with a couple years of experience might decide they want to learn Python. That’s a great thing to want to do, and it might be ambitious if their primary language isn’t Python. However, it’s not a well-defined goal.

To turn this into a good goal, this person might want to try building an open source or locally deployable version of a SaaS solution their company uses (or one they don't use, because they don’t want to pay for it). Doing so would prove that they can put together an actual solution with Python. Plus, the feedback they'd get if they open sourced it or paired with someone more experienced would be awesome for professional development.

As you set your own good goals, the "Five Whys" could bring some clarity. Some engineers define goals like "read x book." But I'd challenge you to dig a little deeper:

Why 1: “Why that book in particular?”

Answer 1: “Well, it’s about this language I want to learn more about.”

Why 2: “Why do you want to learn that language?”

Answer 2: “Well, it leverages some paradigms in programming I’d like to be more familiar with.”

Why 3: “Why are those paradigms interesting?”

Answer 3: “Well, I think it could help our team write better software more efficiently.”

Why 4: “Why do you think that?”

Answer 4: “Because we currently have a lot of overhead that comes from having to do x, y and z with language A, and that overhead is dramatically reduced in language B. As a result, we write less code that’s easier to test, whereas we’re now writing more code that’s harder to test.”

Based on this conversation, this individual hopes to write less code, and they want that code to be easier to test. Additionally, they think applying a paradigm (not the language, specifically) could be a key to getting there. Great! To achieve this, they could pick an item on the roadmap or a side project, and set a goal to implement it using this paradigm to prove or disprove their hypothesis by a certain date. The book will be a supporting tool to help achieve the goal, but it’s not exactly a goal in and of itself.

3. Are You Working On The Highest Priority Projects?

We all get tunnel vision sometimes. We get obsessed with a problem and head down a rabbit hole... or we get stuck on a solution and just keep iterating in the same space for a little too long without looking up. Although it might take a while to realize you're doing this, you can use the "Five Whys" to help out another person who seems to be stuck in this mode of work, like so:

Why 1: “Why are you working on that?”

Answer 1: “Because I just got all this working, and if I can just get the frobulator to integrate with the flux capacitor, we’ll be able to take over the world!”

Why 2: “Why is it a priority to do that right now?”

Answer 2: “Because it’s Q1 now, and we’re looking to get to the Thunderdome release by Q4! If I can do this now, we can move that up to Q3 if everyone else gets their part done!”

Why 3: “Why is the Thunderdome release scheduled for Q4 if it’s such a huge priority?”

Answer 3: “Because we have other projects in the roadmap ahead of it.”

Why 4: “Why do you think they’re ordered that way?”

Answer 4: “Well….”

We all have our pet projects, favorite technologies and nits to pick. However, they don’t always align on the same project, and sometimes the things we want to do are just not the highest priority.

If you want to make an impact and help the team get where they want to be, it’s important to stay the course in terms of what’s worked on, and when. Otherwise, you might connect up that flux capacitor, only to have it sit around for six months collecting dust because everyone else is too busy with higher priority projects to complete their pieces of that lower priority mission. Meanwhile, doing that work could put your own piece of the current high priority project at risk.

But if you ask the right questions, it could help you re-focus onto the right task.

...There’s More!

There are plenty of other issues or challenges that can be clarified and simplified using the "Five Whys." It could also help determine if a technical implementation is solving the right problems, and if a team’s development process is actually working for them (instead of the other way around). So be sure to keep it in the toolbox, and share your own experiences and examples in the comments!