There are two types of troubleshooters I’ve met.
The first holds in their head (or documents) a list of Known Problems, and Known Solutions to Those Problems. They see a problem, and search their internal database for one of the known and accepted answers to make the problem go away.
The second has this, but also has something more: A curiosity and a drive to find out why. Simply making the problem “go away” is never enough — they know that, by the sheer fact of its existence, the Known Solutions list does not contain actual Solutions, but Band-Aids. If the problem were truly solved, then why would we need to continually search for its solution?
The first group tends to run around putting out fires, living in a constant state of medium-to-high stress. They solve a problem and move on to the next, never dwelling on what came before except for how it relates to the current issue and its own resolution.
The second group, by contrast, seems to coast, care-free. They can afford to have more downtime — and, conversely, end up being more productive in the long term.
We’ve all worked with both types of people.
It’s not a personal failing, nor is it a mark of some virtue, to fall in either of these groups. I think by default, almost everyone is in Group One. A rare few fall naturally into Group Two. The rest of us have to learn, or are taught, how to get to Group Two.
The ultimate goal of this “Problem Solver Series” is to lay out a framework for placing yourself, permanently and squarely, in Group Two.
Asking “why” is the easiest and most important step toward getting there.
Think about the last time a five year old got you caught in an endless chain of “Why?”
As long as you don’t lose patience first, you’ll find you eventually start getting questions that you may never have thought of yourself. Or answers you never would have given otherwise.
Continually asking “why?” helps you to peel away layers of preconceptions and arrive at some kernel of truth. In the context of troubleshooting, it’s often a good shortcut to a root cause.
The Benefits of Why
- As discussed, it helps you identify the root cause of a problem
- It helps you determine the relationship between multiple root causes, or multiple symptoms
- It’s easy
How to Do It
Define the problem
You can’t know what to ask until you know what you’re asking about.
Just like we isolate the bug before writing the report, we want to isolate the problem we’re trying to solve. It’s not uncommon to be troubleshooting something and see multiple symptoms, or have multiple things going wrong at once. You need to pick one, separate it from the others, and make sure that each problem is either related to, or distinct from, the rest.
It helps to write down what the problem is that you’re trying to solve. This formalizes it, and makes sure that you and others will focus on the same thing when discussing the problem.
Learn to distinguish the symptoms from the cause
The symptom is the problem that generated the call for you to come help.
The cause is the deepest underlying reason for that symptom to appear. The cause may be one layer deep, or ten, or it may not be technological at all. Asking “why?” is the fastest way to determine this.
There are many great techniques for doing this effectively, and we’ll go over a popular one below.
Ask the right “Why?”
When someone calls and the essence of the question is, “the machine isn’t doing what I want it to do,” there are countless “whys” you can ask, but usually the first and most important should be, “Why is the user’s expectation different from reality?”
Asking probing questions to get at why the user is trying to do the thing they want typically yields results much more effectively than taking the mouse and clicking around to figure out what went wrong on the machine.
The ability to quickly hone in on the right path is usually a skill only acquired over time, enabled by experience coupled with domain knowledge. There’s nothing wrong with taking a little time to get there, or going down the wrong track only to discover you should have been asking a completely different set of questions. As long as you’re cognizant of this, and make sure to take notes and learn, you won’t take long to get there.
The 5 Whys method was originally developed by Sakichi Toyoda, of Toyota fame. It’s an iterative technique (and, I’d argue, sometimes recursive); the perfect tool to explore the cause-and-effect relationships behind any problem. Put simply: you go as close to the problem as you can get, and ask “Why?” five times, until you arrive at its cause.
The purpose of the 5 Whys method is not to simply find a solution to a problem: it’s to find the countermeasure.
Solutions address symptoms. Countermeasures prevent the causes to the symptoms.
A rule of thumb when distinguishing the two is to remember that countermeasures and causes are usually process-oriented. When things go wrong, the symptoms are usually in the technology, but the causes are typically the people who use or maintain the technology.
How to do it on paper
The great thing about this method is it doesn’t require anything more than a pen and paper. Or a marker and whiteboard. Or just your brain.
In a few steps, it looks like this:
- Write down the problem you’re trying to solve.
- Ask “Why is this happening?” and write the answer down below the problem.
- If the answer above is not a countermeasure (i.e., it prevents all of the above from ever occurring), then repeat Step 2
- Go back to Step 3 until you are satisfied the actual root cause is being address
Monitor your solution
You can never be sure your countermeasure was effective unless you monitor your past work.
Follow up with people you’ve helped and problems you’ve solved. It establishes a repertoire with the user. It shows that you can your team care. And it helps you to know that the problem actually went away for good.
A rule of thumb
To bastardize a phrase from the famous Start with Why: You don’t solve what the problem is showing, you solve why it’s happening.