In my professional life, I encounter a lot of folks who cannot solve problems. I’m not referring to clients seeking professional services; I’m talking about professionals whose
very job is to solve problems. This is most often demonstrated in an inability to handle unfamiliar situations. Essentially, they freeze up, stop processing the information
available to them and cannot step through a plan to resolve an issue, even when it is handed to them. These situations are the source of the classic ”RTFM”.
My current role professionally is to basically tell experienced support staff to RTFM and time and again they just don’t. The will to do it just isn’t there. As a result of this,
I spend a large part of my work efforts trying to identify why people fail to solve problems they should be capable of, as well as try to encourage them to use the resources that we
have made available.
In the domain of technical support there are three main strategies of problem-solving employed to resolve almost any issue:
- Process of elimination
- Hypothesis testing
- Divide and conquer (breaking a problem down into smaller, solvable parts)
One note that I’ll add about the above is that they’re in order of their effectiveness. Let’s quickly take a minute to describe these with an example and move on.
Process of elimination: Remove as many extraneous data points from your problem as possible. This is an iterative process that continues until you either have either cannot
further reduce the problem or until you can no longer reproduce the problem, in which case you step backwards and will usually be looking at the cause of the problem or something
that suggests it. One great place to use this is when you have vague errors after Windows startup and you don’t know which application is the source of the error message. You can
simply start turning them off and rebooting until you no longer see it. It’s also great for troubleshooting browser issues potentially caused by software add-ons.
Hypothesis testing: I’ll simplify this from statistical hypothesis testing but basically this is done in four steps:
- Describe and reproduce the problem
- Develop a plan to eliminate the problem
- Implement plan to eliminate the problem
- Evaluate results: prove the problem is solved
We can use the same situations the previous examples. If you think you know what the cause is, rather than go through the steps to eliminate other factors, do the four steps
Divide and conquer: If a problem is large and complex, break it down into issues that you can solve to make it more manageable. This is especially useful in dealing with some of
the sophisticated malware floating around today. Often these tricky pieces of software will provide you with a series of roadblocks to arriving at a fix: they will change
permissions, remove tools and cause misleading errors in other applications. When you take care of these smaller problems piecemeal, you will arrive at clues to what the malware is
doing and why.
Rather than use these as separate processes, I’m going to wrap them up into one step by step process below:
- Describe and Reproduce the problem. (Bonus: Sometimes the person describing the problem to you is wrong. And by sometimes I mean often. Always do this.)
- Research the problem. Gather as much information as you can before proceeding.
- Eliminate extraneous data points. Remove as many factors as you can from being possible causes of the problem.
- Develop a plan to resolve the problem.
- If roadblocks hinder problem-resolution, deal with those first.
- Implement plan to resolve the problem.
- Evaluate the results of your efforts.
That’s really it! It’s that simple… …or is it? Earlier I mentioned a will issue. Time and again I find professionals who know the process but fail to reason that it needs to
be used. That or they throw their hands up in defeat. If there’s not some button to click or tool to do everything for them, or if they can’t just get somebody else to do it, they
dig their heels in the ground and halt all progress. One thing those of us with experience doing this come to understand after a while is that it’s a skill that cannot be simply
taught. There is a mindset required to be able to follow this process and solve problems.
That mindset is one of curiosity. Eventually problem-solving becomes habit, but you have to be a curious person to get there. If there’s one thing that I’ve learned in my
professional life is that most people just aren’t curious. If something isn’t immediately need-fulfilling, their minds will not be engaged. The minds of curious people are always
engaged. Above experience, above credentials and above everything else, curiosity is what I look for in those who want to work for me.
Marcus “djWHEAT” Graham (@djWHEAT) tweeted something that resonates with me pretty strongly here:
All I want more than anything, is to work with people who give a fuck as much as I do
Give me curious people. Give me problem solvers.