A Different Point Of View

If you’re buried deep in a troubleshooting problem, it’s easy to get stuck in a rut. Since we can sometimes talk ourselves into confusing pretzels, my guide to skillful questioning will help cut through the muddy words often used to describe problems. If it’s a limiting belief expressed through language that’s holding your investigation back, those techniques will help you detect and overcome it. While the language patterns are powerful and can clear certain types of roadblocks, they won’t always be enough to get you past a stuck point. Sometimes, the description of a problem will be clear and yet a solution will continue to be elusive.

To get over the hump, consider soliciting an outside perspective. Even better, multiple outside perspectives. Here “outside” simply means “not you”: that’s right, anyone that isn’t you (or on your team, if you’re troubleshooting with a group) can be considered. Asking other people can snap you out of the trance you’re in and help you see things you may be missing.

When considering the benefits of other perspectives, Eric Raymond’s “Linus’ Law” comes to mind:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.”

Eric Raymond, The Cathedral and the Bazaar ¹

Raymond is talking about the world of software development, but I’ve found the principle to be universal. My own formulation of the “many eyeballs” phenomenon is:

For every problem, there is someone who will make solving it look (relatively) easy.

Jason Maxham, The Art Of Troubleshooting

So, that’s what it feels like to quote yourself. It wasn’t as good as what I had built up in my mind… Anyway, the “relatively easy” clause is important: just because you put your dilemma in front of lots of people doesn’t mean someone will magically come up with a brilliant quick fix. Think of all the thousands of scientists who have battled cancer, and yet a cure still eludes humanity. The benefit of “many eyeballs” is extracting the most from the experiences of others and generating new possibilities for solutions. That process may not yield a definitive answer, but hopefully you’ll be pointed in the right direction.

There are five types of relationships, each with different benefits, which will generate useful feedback:

1. You

That’s right, you’re at the center of the circle—it’s likely that no one knows more about the problem you’re working on than you. Have you gotten the most out what’s in your head? This section is about getting a new perspective, but you might not have considered that a different point of view can come from—within you! Have you ever talked to one of these?

It’s okay, your secret is safe with me and so let me introduce the “Rubber Duck” method. This is where you explain your troubleshooting problem to an inanimate object: a rubber duck, pencil, the ceiling, etc. Programmers and IT professionals have long used this technique to resolve issues:

Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed “Never mind, I see what’s wrong. Sorry to bother you.” This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.

Brian W. Kernighan, The Practice of Programming ²

Something special happens when you’re forced to verbalize and explain your problem to someone else. “Rubber Ducking” proves that you don’t even need another person to get a different perspective: often a quick conversation with yourself is all that’s required.

2. Your Peers, Subordinates, And Managers

Besides yourself, these people are most likely to understand the details of and be sympathetic to the troubleshooting you’re doing. It might even be part of their job description to help you out! What you’re hoping is for them to say “That failed on me last week too. I fixed it by doing this…” Even if they haven’t encountered your problem and they don’t have a quick fix, plow on and ask them: “How would you solve this problem?” Since they are in your organization, they will be familiar with the resources (people, tools, etc.) available to solve the problem. For that reason, the questions they ask and suggestions they give might actually be useful.

Ironically, it’s even better if they’re a little bit surly about the whole thing, because it might nudge you to reconsider things you missed. Here, we can take a lesson from Kevin Dunbar’s research into how scientific breakthroughs are made (taken from an article in Wired on the benefits of failure):

Dunbar found that most new scientific ideas emerged from lab meetings, those weekly sessions in which people publicly present their data. Interestingly, the most important element of the lab meeting wasn’t the presentation — it was the debate that followed. Dunbar observed that the skeptical (and sometimes heated) questions asked during a group session frequently triggered breakthroughs, as the scientists were forced to reconsider data they’d previously ignored. The new theory was a product of spontaneous conversation, not solitude; a single bracing query was enough to turn scientists into temporary outsiders, able to look anew at their own work.

Jonah Lehrer, “Accept Defeat” ³

I’ve personally observed the power of well-intentioned pushback while investigating. So, go forth and solicit questions and comments, “stupid” or otherwise, from your colleagues!

3. People In Your Field/Industry/Occupation

One stage removed from people in your organization are people in your industry or who share your occupation. They might be working at a competitor or have retired long ago. Included in this category are former co-workers, bosses, mentors, teachers, professors, etc. These contacts can be really valuable for troubleshooting because they will be used to solving similar problems using similar tools. However, because they have been at a different organization (or worked in a different era), they might do things…differently. That’s great, because seeking out what’s “different” is what this section is all about. If they’re working at a competitor, they might not share their secret formula with you, but you’d be surprised at the amount of help available to you in a crisis, if you just ask.

Included in this level are technical contacts at your vendors, who typically will have worked with others in your industry and will therefore have a similar breadth of knowledge. Also, because they “work for you,” they’ll be motivated to help you out and may be less guarded about sharing information than a direct competitor.

It’s important to set up these contacts in advance and maintain these relationships, so think about opportunities to network and build contacts through industry associations, trade groups, conferences, trainings, etc.

4. People In Related Fields/Industries/Occupations And Those Who Use The Same Tools

Still useful, but further out, are people who work in a related field. They will be familiar with the problems you are trying to solve, but at a more abstract level. For example, an auto mechanic and an airplane mechanic will have this type of relationship. People in related fields are great to bounce ideas off because they will likely have very different solutions. Given the economics involved they may have fixes that simply aren’t feasible for your situation, but there’s no downside in asking for their perspective.

People who use your same tools, machines or processes (but work in a completely unrelated field) can also be included in this tier. If you’re a toymaker that uses the same type of industrial robots as the automobile manufacturer next door, you’ve got something very important in common, especially when those robots break down.

5. Everyone Else

Consider presenting your problem to: a doctor, a physicist, a biologist, a psychologist, a mechanic, a programmer, an artist, a musician, a carpenter, an electrician, etc. How would they solve your issue with the resources and strategies with which they are familiar? The answers from this tier will be the most hit-or-miss. However, the payoff can be huge: there’s a long and storied history of cross-pollination of ideas from seemingly unrelated fields. For instance, Eugene Stoner took his experience using lightweight materials like aluminum for building aircraft and applied them to firearms to create the iconic M-16 assault rifle. Builder François Hennebique saw how gardener Joseph Monier was using steel reinforced concrete for his planters and it led to the amazing skyscrapers, bridges and dams we see in the world today. Especially for very difficult or chronic troubleshooting problems, you may need the insights of someone in a completely different universe.

You might be saying “There’s no way I’m going to ask a musician how to troubleshoot a fuel injection system.” Thanks for the great segue:

Just Grab Someone, Anyone!

You can involve someone who knows “nothing” about your problem with a technique I call “get someone to ask stupid questions.”

If you’ve hit a wall, go grab someone who you’re sure can’t help (like someone who works in “HR,” “marketing,” or “management”). Briefly explain the problem, tell them you’re stuck and then say, “Go ahead, ask me some stupid questions to help me figure this out.” They’ll probably start with something like “Is it plugged in?” (is it?) and so you’re probably thinking “How is this even remotely useful?”

Here’s what I’ve learned: it doesn’t actually matter what they ask you, but it frequently works to get your mind pointed in a new direction. I’ve personally come up with breakthroughs in the middle of an “ask stupid questions” session with a co-worker. You’ve gone over the same facts and solutions in your mind a million times; this exercise breaks through the trance you’re in and the mental loops you may be running. Having to answer stupid questions gets you out of your head, and forces you to consider the problem from a different point of view.

This section is all about new perspectives, and having to explain something complicated to someone who knows nothing about your work will force your mind to consider a new point of view. Even if the perspective your colleague is offering isn’t very useful, your subconscious will get the metaphor: there’s probably another way to look at the problem. Again, I’ve found that just a few minutes of “stupid questions” will be enough to get me going in a better direction. Try it!

References:

• Header image: “Four trees from below.” Adam Nieścioruk. Retreived from Unsplash, https://unsplash.com/photos/53KPnkKjkAY.
• ¹ Eric Raymond, The Cathedral and the Bazaar, “Release Early, Release Often.”
• ² Brian W. Kernighan, The Practice of Programming (New York: Addison-Wesley Professional, 1999), pg. 123.
• ³ Jonah Lehrer, “Accept Defeat,” Wired, January, 2010.