Troubleshooting and the art of asking questions.

Computer Trouble

I attribute a lot of the success I have achieved in IT to my ability to communicate with customers, ask relevant questions in the troubleshooting process, and extract valuable information from those questions, without alienating or offending my customers. In fact done correctly you can make any customer interaction into a positive one.

Working successfully in any capacity in Information Technology requires an ability to identify a problem, isolate its cause, and resolve the issue. In other words you need to be able to troubleshoot. This post will be the first in a three part series where I talk a little bit about my experiences troubleshooting and the methodology I employ when faced with any technology issue. Troubleshooting is at it’s core a three step process (identify the problem, isolate the cause, resolve the issue). This is not an in-depth discussion of how to fix a specific problem, these are posts more about how to think about troubleshooting from a high level perspective.

Step 1 – Identify the problem.

Troubleshooting is a learning process and good troubleshooters do not presume to know what the problem is without first asking the right questions.

Identifying the problem is in my opinion the most important step in the process. Don’t fall into the trap of thinking that you are so smart that you don’t have to listen to your clients. In my experience the best IT troubleshooters begin from an attitude of discovery. They want to understand the problem and how it affects their client’s ability to work. Troubleshooting is a learning process and good troubleshooters do not presume to know what the problem is without first asking the right questions.

When a new IT issue is reported through your ticketing system the first  step is to begin a discovery phase. Begin by asking questions, and gathering data. You need to contact your customer by phone, or in person to start an interview process, do not assume that you know what the problem is without first asking for clarification.

Encourage an open and honest discussion with the client

Having a strong relationship with your clients and customers is absolutely essential to helping them resolve technology issues. Traditional IT departments have done a lot of damage to client relationships by losing focus on customer service. It is your responsibility at every level of IT to make sure that every one of your customers feel like they are the most important customer you have, at all times.

Do not ever, under any circumstance, or for any reason begin your interview with the most unfortunate and common of all help desk questions. “What were you doing when this happened?”.

I find that many people who call to report IT issues tend to take a defensive posture with the help desk. I’m no psychologist but I tend to think this is happening because help desks often have a reputation for making users feel inferior, incompetent, and at least partially to blame for the problems they are facing. This defensiveness can be difficult to breakthrough and will often create a situation in which people are not treated fairly (at either end of the call). Presenting an honest and open attitude of learning will help you to breakthrough this barrier. I try to engage my users in a learning process that makes them feel that we are equals working on the same team and towards the same goal … getting back to work.

Do not ever, under any circumstance, or for any reason begin your interview with the most unfortunate and common of all help desk questions. “What were you doing when this happened?”. You will immediately trigger your clients defensive shields and your ability to get the answers you need will be severely handicapped. Remember, unless you are dealing with someone who has malicious intentions, it is not the users fault that the technology they are working with is broken… In fact if anyone is at fault you are, so be prepared to swallow that pride an listen.

Your customer is on the same team you are on. Start coaching them through a scenario, put your pride on the back burner and let them teach you something.

These questions can uncover a lot of the information most help desks are trying to get when they ask the question-that-must-not-be-asked.

  1. What programs were open when you noticed the problem?
  2. Did the problem seem to be related to something that was open?
  3. What was the computer doing differently that alerted you to this issue?
    • The computer is at fault not the user.
  4. Can you show me?
    • Preferably you are at your clients desk or have the ability to remotely connect to their systems. A screenshot is a last best case scenario here but I discourage it because you haven’t really seen how they got to an error. You’ve only been able to confirm that they got one.

These questions will provide you with the answers you intended to get from the unaskablequestion, while still encouraging your customer to be open and honest. You get what you want, they both tell and show you what they were doing, without getting defensive.

Whatever, the results are of the first questions I like to follow up with these important questions to make sure that I have a good idea as to what the user is having trouble with. You don’t want to spend hours, or day’s on a problem that the user does not have.

  1. If someone else performs this task can we go to their workstation so that I can see how it is supposed to work?
    • This is invaluable information.
    • Does the second user go through the exact same process? If not record the steps and see if that resolves the issue your original user had.
    • How will you know when you have fixed the problem if you don’t know how to test your resolution?
  2. When did you first notice this issue?
    • This question can help you determine the urgency of the request. If this has been happening for 6 months it’s obviously not stopping them from working and probably doesn’t require immediate action (unless it is related to a task that is only done twice a year).
    • It also could give you a clue about possible causes. If it just started today you need to find out what has changed since yesterday. Updates? Virus scans? New person using the computer?
  3. Can you show me how to reproduce this error or problem?
    • This serves a dual purpose. It gets the customer thinking about tasks that they normally do automatically reducing the risk of user error. Secondly it shows you what to do to reproduce the problem and start looking for possible causes to isolate.
    • It also convey’s a certain amount of respect. Let the people you work for know that you recognize them as a competent and valuable member of the team. Whether or not it is true, let them feel as if they know more about the job they are doing than you do. Show an interest.

These, I’m sure, are not the only questions you should ask for most individual IT issues. The point I am trying to get across is that you should focus a lot of time and effort into customer relationships. Having customers who know you personally, and can put a face to the person behind the phone, or email will make you better at your job. You can not assume that you know what a problem is before you have even spoken with a customer, as a business you cannot afford to have people on your team that cannot be trusted to treat your clients with fairness and respect. The day’s of IT pro’s being isolated from the rest of the world working by themselves is over… and has been for a long time. If you want to be a good troubleshooter, learn to ask the right questions, and always strive to make your customers happy.

Author: Luke

Linux Systems Administrator RHCSA, LFCS, ITIL v3 Foundations.

One thought on “Troubleshooting and the art of asking questions.”

Leave a Reply