Talking About Your Problems

Once you’ve become a skilled troubleshooter, it’s time to look in the mirror and think about how you interact with the people you call on for help. What’s the best way to present your problems to others? Having been on both sides, sometimes solving issues and sometimes reporting them, I have some thoughts on the matter.

Mixing Fact And Speculation

Since you’ve made the effort to bring your problem to someone else, we can assume that you’re:

  • Unsure about the cause of the issue.
  • Unsure how to fix it.
  • Both.

If you’ve taken the time to read The Art Of Troubleshooting, we can make one more assumption: that you have a keen interest in fixing things. So, let’s sound the alarm and warn ourselves against the very thing we dislike when others bring their problems to us: mixing speculation with facts.

Let me explain with a story. Recently, some friends were getting their hot tub repaired (the water in the tub wasn’t staying warm). When the technician showed up to look at the problem, he was told that the “heater was broken.” A more skilled (or, if we were being cynical, honest) repairman would have responded to this with the right amount of skepticism: “How exactly do you know that the heater is broken?” However, this technician took the provided description as gospel and replaced the heater. It also turned out that this guy really liked to replace heaters, the procedure was squarely in his wheelhouse. Adding to the momentum was that a replacement heater was on his truck, all ready to go. Unfortunately, after replacing the heater, the problem persisted. On a subsequent visit with a different technician, it was discovered that the circuit board that controlled the heater was intermittently malfunctioning. The original heater was probably fine. Oops.

Let’s go back to the start of these shenanigans and think about what went wrong. While it’s true that the words “the heater is broken” were the ones actually spoken, the meaning was that the water in the hot tub wouldn’t stay hot. Mentally, it’s convenient shorthand to associate a particular machine function with a certain component. After all, “heat” comes from the appropriately named “heater.” The cause and effect are easily bound together in your mind; if there’s no heat, the problem seems obvious: the heater. There’s another possible semantic interpretation, some people might use “heater” as a synonym for “the heating system,” which includes everything the heater depends on: the thermostat, power source, etc. Unfortunately, people (like technicians) can take things literally: when they hear “the heater is broken” they might just go ahead and replace—the heater!

Ring Bell For Service
Be careful what you tell them, they might believe you!
(image: Jamiesrabbits / CC BY 2.0)

If You’re Going To Speculate, Be Clear About It

The above example is a good illustration of what can unfold when a supposition is accidentally injected into a problem report. However, we don’t want to have a blanket prohibition against speculating on the cause. That’s no fun! Besides, what if you actually have a helpful piece of information that could possibly save a technician hours of work? It’s okay to speculate, but you need to clearly mark what you’re doing: “I think the heater may be broken because the water is cold. How can we tell if that’s the cause?” This is a more cautious framing of the problem: it points out the symptom you’re experiencing and what you believe is the source of the issue, while leaving room for other possibilities. It also explicitly states that you’re interested in finding the cause. Yep, that would be nice to know.

Symptoms And Goals

Since you’re paying someone for their expertise, consider forgoing speculation entirely. If I’m really a fish out of water with a particular machine, I focus on the symptoms and what I want to be able to do. That is, what is the malfunction preventing me from accomplishing? This kind of formulation sticks to what you know and clarifies your end goal for the technician: “The water in the hot tub is cold. I want it 101° F like it was last week, so I can throw a party.” Including the overarching goal in your problem description is critical because it really doesn’t matter what is broken and what is fixed: if the end result doesn’t put the hot back in hot tub, you’re not going to be satisfied!

Go With The Flow

Reaching out for help sometimes means interacting with a customer service agent in a faraway, exotic land (like Texas). You need to cultivate kindness and patience for these frequently frustrating encounters, where all you want is to talk to someone who understands your problem. But, there are ways you can make these interactions useful, even if the person you’re talking to is struggling to help. You may have heard the expression, “Just the facts, ma’am.” This was television detective Sgt. Joe Friday’s famous admonition to his interviewees, a call to forgo opinions and focus on hard evidence. The problem is that there are an infinite number of facts you could relate to someone about a particular broken machine: its technical specifications, make, model, serial number, when you bought it and from whom, its operational record, repair history, recent changes to its environment, others things that might be wrong with it, etc. Any of these facts might be relevant, but then again they might not. Contacting an expert is useful because they know more about which facts are relevant and which are not. You may think you’re being helpful by passing along a hidden nugget that will crack the case wide open. However, for every time I’ve pointed out something useful, I can think of another example where my instincts about the relevant facts were completely wrong. In those cases, my well-intentioned ramblings were actually a distraction to the technician’s fault-finding process.

Therefore, if I’m going to put myself in the hands of experts, I like to learn what they think are the relevant facts. I do this by letting them guide the investigation process. Even when I’m dealing with someone who I think is reading from a script, I like to give them the benefit of the doubt and let them lead (at first). If I find myself driving the interaction, I fall back to symptoms and goals: “the machine is doing X, and is preventing me from doing Y.” Of all the facts, these are the most important. Keeping an eye on the end goal also opens the door to alternatives: just by saying your purposes out loud, your mind will start looking for workarounds.

You might be tempted to blow off a scripted response to your problem, but I suggest you go with the flow instead. If you’re against scripts, then you’re also against things like troubleshooting trees, which are essentially the same thing. Sure, customer service scripts are designed for the “lowest common denominator,” but that frequently is you. When it comes to machine problems, be wary of thinking that you are a beautiful or unique snowflake. I’ve often been surprised at the number of times my issue has been resolved by executing the scripted advice during one of these sessions. When asked to verify something you think is obvious, you may be tempted to scream “This is foolish, I want the advanced techniques! I think the problem is related to…um…wait…sorry, it actually wasn’t plugged in. Thanks.”

Even if canned scripts delivered by a underpaid cubicle dweller fail to deliver a solution, just having a conversation about your problem can lead you to the promised land. There’s something magical that happens when you’re forced to communicate the ideas in your head. It seems strange, but I’ve figured out the causes of problems just by explaining them to others. I don’t have a peer-reviewed academic study to offer on this point, so I’ll just speculate why this happens. To start with, having to explain something to someone else gets you out of your head and shifts your focus externally (to the understanding of the other person). Next, telling the “story” of your breakdown, from beginning to end, exposes the holes in your knowledge. If it’s not clear why A → B → C, it’ll be even more apparent when you attempt to communicate it. Have you ever started to explain something you felt very sure of, only to realize mid-way through that you don’t quite understand it after all? It often takes saying things out loud to trigger these discoveries of what is uncertain. Finally, I mentioned the power of “stupid” questions to facilitate breakthroughs in “A Different Point Of View.” Often, when it comes to interacting with Customer Service, if you want those good “stupid” questions, you can have ’em by the truckload!

Before Talking With Customer Service

Even though I’ve pointed out many positives, I’m not giving a blanket endorsement to always pursuing aid from Customer Service. Getting outside help is a strategy like any other, and therefore must rise to the top versus all the other alternatives. As always, Opportunity Costs should be considered: what else could you be doing with your time? While I’ve shown that interacting with Customer Service can frequently be useful (even if unintentionally), it still must meet the standard of being the best strategy in your universe of possibilities.

Initiating contact with outside help has overhead: in addition to consuming time, some companies will charge you to speak with their support teams. That’s why I like to push my investigation to the point just before the onset of severe diminishing returns. Recognizing where this happens is a judgement call. Now, I have a good feel for where this line is: it’s usually after all of the “basics” have been tried and I’ve entertained (and shot down) some more exotic theories. Talking with Customer Service can be a welcome change of pace when you’ve hit a plateau like this. Just like taking a walk around the block, these interruptions can be a useful distraction.

Finally, I always like to have my ducks in a row before calling for help. A good description of the problem. Check. A series of steps that replicates the problem reliably. Always helpful. The better prepared you are when seeking outside help, the more likely the interaction will lead to a speedy resolution.

Engine detail
Photo op! Imagine describing this scene over the phone: “Yeah…there’s a bunch of pipes…connected to…other pipes.”
(image: Victor Camilo / CC BY-ND 2.0)

Picture Perfect

I named this piece “Talking About Your Problems” for a reason: to highlight the pitfalls associated with verbalizing technical troubles. In addition to the ideas above, you should practice the methods presented in “Skillful Questioning” to become a truly proficient language detective. That’s great, but seize the opportunity to do an end-run around words, bypassing these problems entirely. Any time there’s a decision to be made between talking about evidence and presenting evidence directly, always choose the latter.

In the world of fiction writing, there’s a concept called the “omniscient narrator.” This is a point-of-view the author writes from that has access to all the events and dialogue within the story. Jumping from scene to scene or telling the reader what is going on inside a character’s head requires this God-like power. When it comes to reporting problems to a fellow troubleshooter, you are the narrator. Unlike Charles Dickens or Ernest Hemingway, your narration skills might be lacking, so save them for that brilliant screenplay you’re writing. Of course you must speak, but always supplement your words with primary sources when you are able. Show them pictures of the failure, have them read the relevant documents, or take them on-site so they can conduct their own inspection.

Phone-based technical support is particularly vulnerable to the unreliable narrator problem. I’ve helped a lot of people over the phone, and so I know that a photo (or screenshot, when giving IT help) can be the quick path to a solution. When I was green, I would sometimes think to ask for a photo only after a long and winding conversation that was going nowhere. Seeing the evidence first-hand was stunning and it was interesting to compare it to what was actually related by the “narrator” during our talk. Often, a key detail was misspoken (or misheard by me) at the outset, taking my questioning nowhere. Or, the person focused most of their description on an irrelevant part of the machine (not that it was their fault, if they knew what was relevant they wouldn’t have needed my help). These problems melt away when you can put the actual evidence directly into the hands of someone trying to help you. There’s a reason everyone knows the saying “a picture is worth a thousand words.”

References:

Leave a comment

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

search previous next tag category expand menu location phone mail time cart zoom edit close