One of my favorite parts of my job is troubleshooting. I enjoy troubleshooting issues for users, and I enjoy helping my coworkers troubleshoot issues they encounter. There’s just something satisfying about seeing a mysterious problem and picking it apart until you find the cause.
As a result, people sometimes ask me how to get better at troubleshooting. It’s a hard skill to explain — sometimes it feels like I just know the correct solution to a problem, and sometimes it feels like I’m just intuiting where the issue lies. Those aren’t really helpful to someone who wants to improve, and the truth is that I didn’t walk into this job with all of the answers or intuition I have today. So where does it come from?
One key that I realized is that to be good at troubleshooting, you have to be curious. Specifically, you have to ask questions (either literally asking another person or just asking yourself as a step in the process) with the intent to learn, not just the intent to get an answer for the one problem you are currently facing. Whether you’re getting help or you’re eavesdropping on someone else who’s troubleshooting an issue (also a great way to learn!), here are things to consider:
- How did someone else break down the issue I’m looking at and approach or investigate it?
- What is the general subject underlying this issue, and what information can I brush up on (with further reading, classes, conversations with experts) that will help me solve an issue related to that subject later on?
- What keywords (error messages, feature names, descriptions of the problem) can I use to search for past occurrences of this issue?
- What tools do I have access to that could possibly give me more information about the problem that underlies this issue?
A lot of the time, my troubleshooting is a lot of trial and error. I might pop open my browser console to discover it’s completely blank, and later find out that my terminal could have given me more useful information. Or I’ll be absolutely sure I’m encountering a theme bug, only to discover that the problem is solved by changing a widget. That’s ok.
Learning to troubleshoot is learning how to approach a problem, and going down the wrong path is bound to happen in that process. But the more practice you get, and the more techniques and information you learn, the better you’ll become at identifying the likely cause of any given issue and figuring out how to resolve it — without having to rely on someone else handing you the right answer.
My coworker Kelly shared a fantastic lesson recently:
Tell me the problem, not how you think I should fix it.
This is really much harder than it seems at first glance. While talking with users, I often end up with all sorts of suggestions about how we could improve our products. Add a feature, change the layout, remove a roadblock, etc. Even if a user didn’t make the suggestion explicitly, I sometimes come away from an interaction thinking, If only we did this instead of that …
It’s really easy to think you know the solution to your problem. If I had a penny for every time I told a developer or designer, “Our users want X,” or “We could resolve the issue by doing Y,” well, you know. But the fix you come up with might not be the best fix for everyone using the product, or even the best fix to help you reach your own goal — and pushing for minute fixes can also mean missing out on fixes you can make to the bigger picture.
Slowly, I am learning to recognize that instinct to come up with a fix and refocus on identifying the problem. Here are some things I ask myself to help with that:
- What assumptions did we make when designing the product about how it was going to be used, and what assumptions is this user making about how the product should work? Where do those assumptions clash?
- What was the user’s goal, and where did the product fail to help them meet that goal?
- What patterns or trends have I seen recently in the problems our users are telling us about (or the fixes they are asking for) that might indicate a bigger breakdown?
With those questions in mind, I can engage the people who use our products in conversations about the problems they are encountering, and communicate those problems to the people who create our products. And I’m happy to brainstorm and offer suggestions when it’s helpful, but unless I start by communicating the problem, we are all missing an important step along the way to the solution.
As a remote worker, I get to know a lot of my coworkers by chatting with them on Slack. (It makes those years of using AIM feel like job training. Or at least I like to rationalize it that way!) As a result, I have a lot of conversations that go something like this:
- Coworker: Rachel, I’m dealing with [this tricky issue]. Can you help me sort it out?
- Me: Sure! You can learn more about that in [one of our knowledge bases] or try [this solution I’ve learned from experience].
- Coworker: Thanks!
- Me: [insert appropriate phrase for accepting thanks here]
The first part of the conversation is the easiest, really. It’s the part where I’m thinking and researching and teaching and guiding. It’s in the last part, where I have to figure out how to accept the thanks, that I overthink it. Why? Because I can never, ever decide if I should say, “No problem,” or “You’re welcome.” (Or sometimes just a quick “Sure thing!”)
This internal struggle was highlighted when I read the conversation about “No problem” vs. “you’re welcome” on All Things Linguistic, and even more when I got to the article on You’re welcome on Separated by a common language (a blog that compares American and British English). The basic issue is a divide between people who find “You’re welcome” acceptable and “No problem” rude, and people for whom “No problem” is the most natural response and “You’re welcome” sounds sarcastic or over the top. Add to that cultural differences in how to accept thanks, and you’re headed for a minefield any time you help someone out.
I realized that I fall into the generation of speakers who prefers “No problem,” although I try to avoid it in a lot of situations out of fear that I’ll be seen as rude or dismissive. I actually had to make a conscious decision to start using the phrase “You’re welcome” both online and offline, after I realized my habits could be offending people. That said, if you’re going to pick apart the meaning behind the words, I’d argue there isn’t a big difference between “No problem” and the ever-so-polite “It was no trouble at all.” (The latter is the sort of phrase that feels so proper I pull out a silly fake British accent as I say it, until I remember where I live and swallow the words before they can come out of my mouth.)
I could go on for ages with the intellectual exercise, mulling over the various ways everyone accepts thanks. At some point, though, I have to stop thinking and type out a reply to my coworker (because nothing feels as rude as an answered “thank you”). How do I do it? I’ve decided to try to use “You’re welcome” as much as possible, as a sort of standard polite American English response. But once I’ve done that a bit, or I’ve gotten to know the person I’m talking to, I’ll fall back to “No problem.” Or I’ll try to avoid the seriousness of the reply with a quick “yw” or “np” or — to avoid this dilemma altogether — just a quick thumbs up. 👍
I came across an interesting logic puzzle in the New York Times today. You get 3 numbers and have to figure out the pattern:
If you like puzzles, take a moment and check out A Quick Puzzle to Test Your Problem Solving. Then continue on to see what this has to do with testing software …