When it comes to troubleshooting, skepticism is a virtue. That’s because so many troubleshooting projects begin with someone else’s account of the situation. Be nice about it, but never take a problem report as gospel truth. I can’t tell you the number of times I’ve been sent down the rabbit hole by taking someone’s description of a failure at face value. A person comes to you and says, “X is broke”: the truck won’t go, the Interwebs are down, the refrigerator is dead, etc. State something is broken and your mind will leap to consider ways it can be fixed. However, in my experience, people are much more likely to mean: “I can’t do Y” (as in, “I can’t haul the dirt…,” or “I can’t send this email…”) when they assert that something is broken.

I stumbled on skepticism as a virtue of troubleshooting the 207th time someone came to me with a problem, along with associated speculations on the cause, and sent me on a wild goose chase. Taking their report at face value led to a long exercise of debunking: not only of the actual problem, but ultimately the person’s report itself. At the end, I thought “You lied to me!” Fool me once, shame on you, fool me 207 times…well, you won’t fool me again!

There must be a lot of good troubleshooters here.
(image: LeeAnne Adams / CC BY 2.0)

You should expect most problem reporters to have the best of intentions, but not necessarily the knowledge or expertise to relate even the most basic facts of a breakdown (much less the underlying cause). After all, if they were that knowledgeable and wise, they might have just gone ahead and fixed it by themselves! You’ll find all kinds of wild guesses about causes embedded in user reports. Parsing those messages by asking the right questions is an art in and of itself, as you’ve seen in “Skillful Questioning”.

Until you master that, train yourself to say these words: “show me.” Even better, “What exactly are you unable to accomplish?

With regards to “show me,” there’s nothing like actually observing a person attempting to do something they think they can’t do. Watching is frequently a powerful antidote to any speculative words that may have been uttered during the reporting phase. Unfortunately, it’s also an entree to the “intermittent” class of troubleshooting problems: if you’ve ever had the IT guy come over to your desk only to have the problem disappear, you understand that unexpected things can happen when you’re being observed. Watching a person perform a task can also be a moment to suggest a workaround that may placate them until a real solution can be found. You may notice that their workflow or use of said machine is somehow suboptimal, in which case you might be actually improving their process:

You: “This copier is definitely broken, but did you know that you can use the one next to your office, rather than this one twelve floors down in the basement?”
Them: “You’re amazing.”

The question, “What exactly are you unable to accomplish?” brings the problem back to the land of facts (versus the assumptions that frequently accompany bold assertions like “X is broke!”) and what is actually vexing the reporter of said problem. No one uses a machine for its own sake (exception: my motorcycle), so that’s why “the printer is broke” can easily be turned into “I can’t print my monthly accounting report from the computer in the conference room.” Which, in turn, may lead to the discovery that the printer is fine and that an automated updater installed a buggy printer driver that is causing Microsoft Excel to crash when printing. That’s way more specific and definitely not as dramatic as “the printer is broke!”—but it’s a problem that can actually be solved or worked around.

As I introduced them, I said that the Virtues of the Troubleshooter are to be practiced in moderation. When it comes to being skeptical, I’m not telling you to disbelieve everything you hear. Likewise, this isn’t license to mercilessly question every fact offered by someone reporting a problem. The point of skepticism is to keep open the possibility of a disconnect between words and reality, between someone’s description of a problem and the problem itself. The deeper implication of skepticism is to realize that you have a choice in what will become germane to your investigation and that it’s your job as a troubleshooter to determine what is relevant and what is true.


4 thoughts on “Skepticism

  1. I had someone call in saying “I forgot my password for such-and-such system.” Okay, confirmed the user’s identity and reset their password. Still can’t log in. Hmmmm, that system’s password reset is well known to be finicky, let’s try it again. Still no go. “Can you send me a screenshot?” They sent me a screenshot of a COMPLETELY different system.


    1. Ha! How frustrating. There’s nothing like a screenshot to clear up confusion. A picture really is worth a thousand words.

      I talk more about the value of direct evidence (especially when doing phone-based tech support) in “Talking About Your Problems”.


  2. You're saying that getting through medical school requires a healthy dose of skepticism? 🙂


  3. Sounds like you're ready to go to medical school!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close