“I’m about to launch the nukes.”

It wasn’t even noon yet and it was only Monday.

It would make a better story if I could say there were a few minutes of stunned pause from my coworkers at me saying that, but by now we’ve all been around the block a few times and said that or something like it.

I did; however, take a few minutes to pause and reflect on whether or not I should flame out and end my career in spectacular fashion. Most fortunately, I work from home and beer is ever a handy problem-solving tool.

Unfortunately though, when you’re sitting there with your finger on the nukes, it’s probably time to go. Nick Chirls wrote something similar to this a few days ago and I won’t spoil it for you, but my answer is definitely “Shit on the face.”

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 above.

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:

1. 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.)
2. Research the problem. Gather as much information as you can before proceeding.
3. Eliminate extraneous data points. Remove as many factors as you can from being possible causes of the problem.
4. Develop a plan to resolve the problem.
5. If roadblocks hinder problem-resolution, deal with those first.
6. Implement plan to resolve the problem.
7. 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.