The Art of Troubleshooting

I’ve come to believe that troubleshooting is less a technical skill and more a way of thinking. Anyone can memorise fixes. The people who are genuinely good at this have something else going on, and it’s usually curiosity paired with a stubborn refusal to guess. Sherlock Holmes put it best: “It is a capital mistake to theorise before one has data.” If you’re like me, you’ve watched plenty of problems get worse because someone started swapping parts before they’d asked a single sensible question.

So let me walk you through how I think about it. Not a checklist of fixes, but the mindset underneath the work.

Start by ruling out the obvious

There’s a scene in I, Robot where Detective Spooner is questioning a hologram of Dr. Lanning, the scientist who built the robots. The catch is that the hologram can only respond to the right questions. Spooner keeps pushing and getting nowhere, until he finally lands on the one that matters and Lanning replies, “That, detective, is the right question.” Everything before that was data gathering. Troubleshooting is the same. You can rattle off a dozen questions and get nothing useful, because half the battle is working out what you should actually be asking in the first place. This does allow you to rule certain theories out along the way.

And the truth is that the right question is nearly always the boring one first. Is it plugged in? Is it turned on? Has it been restarted? Is anyone else affected, or just this one person? Did it work yesterday, and what changed between then and now?

I know how basic that sounds. But I’ve lost count of the times a “major outage” turned out to be a network cable someone had unplugged, or a cleaner unplugging a server to clean around the rack. The obvious stuff is obvious precisely because it’s common, and common things are common. When you rule out possibilities one by one, you’re not being slow, you’re being systematic. You’re shrinking the map. Every “no, that’s not it” is progress, because it’s one less place the problem can be hiding.

The trap is assuming. Assuming the cable is fine because it looks fine. Assuming nothing changed because nobody mentioned a change. Occam’s razor is your friend here: the simplest explanation that fits the facts is usually the right one. Don’t reach for the exotic theory when the mundane one hasn’t been tested yet.

Work through the obvious, prove each thing rather than assume it, and let the process of elimination do the heavy lifting. By the time you’ve genuinely ruled out the easy stuff, you either have your answer or you’ve earned the right to start digging deeper.

Learn to search like you mean it

A huge part of this job is knowing how to find things out, and that’s a skill in its own right.

The image of the lone genius who knows everything off the top of their head is mostly a myth. Yes, there are people out there who are specialists in their domain, but when it comes to IT and Technology in my industry, the scope of this domain is so broad that more often than not you have generalists, not specialists. (These people do exist, and they’re brilliant in their own right) The best engineers I know are brilliant at searching. They can take a vague error message and turn it into a search that actually surfaces the answer.

The knack is in the query. “Printer not working” gets you nowhere. The exact error string, the specific model, the version number, the operating system, that gets you somewhere. Learn to spot the part of an error message that’s unique to your problem versus the generic noise around it. Strip out the bit that’s specific to you (usernames, file paths) so you’re matching the pattern, not your particular machine.

And these days, the same principle applies to how you ask AI, whether that’s ChatGPT, Claude or Microsoft Copilot. A vague prompt gives you a vague answer. Feed it the real error, the context, what you’ve already tried and ruled out, and it becomes a genuinely useful thinking partner. Treat it like a very well-read colleague who wasn’t in the room: it can only help you as well as you brief it.

However, never trust a single source. One forum post from 2014 telling you to disable a security feature is not a solution. Read three, four, five sources. Look for the consensus. When several independent write-ups, a vendor’s own documentation, and a couple of recent discussions all point the same way, you’ve got something you can rely on. When they contradict each other, that contradiction is itself a clue that your problem is more nuanced than it first looked.

Aggregate, cross-check, then act. The internet will happily give you a confident wrong answer. Your judgement is what turns a pile of search results into an actual fix.

Lean on documentation and the people around you

There’s a stubbornness that IT seems to attract, a sense that asking for help is admitting defeat. I’d 100% push back on that. As Isaac Newton wrote, “If I have seen further it is by standing on the shoulders of giants.” Nobody does this alone, and pretending otherwise just makes the job harder than it needs to be.

Documentation is the first giant to stand on. The vendor’s own knowledge base, the internal runbook, the notes someone wrote up after the last time this happened. Good documentation is troubleshooting that’s already been done for you, wrapped up and left on the shelf. Read it before you reinvent it. And when you do solve something new, write it down, in your company’s knowledge base. Knowledge is best when it’s shared. The version of you six months from now, facing the same issue at half four on a Friday, will be extremely grateful.

Then there are your colleagues. Take it from someone who works in a large team of outsourced IT support engineers, someone on your team has almost certainly seen your problem before, or something close enough to matter. A two-minute conversation can save you two hours of going in circles. Even just explaining the problem out loud does something useful. Ever started describing an issue to someone and solved it halfway through the sentence? There’s a name for that, rubber duck debugging, and it works because articulating the problem forces you to think clearly about it.

Asking for insight isn’t weakness. It’s how good teams work. The goal is a solved problem and a happy user, not a medal for having struggled alone. Share what you learn, ask when you’re stuck, and the whole team gets sharper for it.

Bringing it together

Strip away the tools and the jargon and troubleshooting comes down to a handful of habits. Stay curious. Ask the right question rather than the loudest one. Rule out the obvious before you chase the obscure. Search well and never trust just one voice. And lean on the documentation and the people around you, because you were never meant to do this on your own.

The technology will keep changing. The methodology doesn’t. Get the thinking right and you can troubleshoot things you’ve never even seen before, which is most of the fun!