It’s probably fair to assume most of us are paid to solve problems, and we’re darn good at it. More than likely, you make a living by troubleshooting problems, so I know I’m preaching to the choir by trying to describe or define the word “troubleshooting,” but here’s my spiel. My troubleshooting process revolves around two core ideas: Communication and Validation, and Collaboration and Research.


Communicating brings details and details bring context, all of which bring you to a resolution more quickly. An example would be a ticket I received recently which only contained a single sentence: “Wireless is down in room 110A.” There are so many questions needing to be answered. Where is room 110A? What kind of device is having a problem? Are there any error messages? Can they even see the WLAN? All these things would provide me with context to troubleshoot the issue efficiently. Since the person who created this ticket didn’t communicate properly, we have only a few details and almost zero context. In this case, I had to start the troubleshooting process from the beginning and reach back out to the user. Once I feel like I’ve gathered enough detail and context around the issue, I immediately begin validating the information. I probably don’t have to explain why it’s a bad idea to take a user’s word as law but before you even begin troubleshooting, it’s important to validate the information you have, otherwise you run the risk of going down the wrong path and getting stuck. Ever been lost in a corn maze? We all know the feeling.


This is where I begin the actual troubleshooting. Checking logs, looking at charts, making ritual sacrifices to vendors…the usual stuff. From here, there are three possible scenarios: I might find the problem and implement what I assume to be a solution, realize I can’t solve the problem alone and reach out for help, or come to the conclusion I don’t have enough data/context. The first option is obviously what I’m hoping for, and the third option dictates I move back to the beginning to gather more information. The second option, though, that’s what we call “bringing out the big guns.”


If I’m troubleshooting something and have a good idea of what the problem is, but still can’t seem to find a solution, I do what any other educated IT professional who has spent years accumulating knowledge does…I Google it. To me, this means I’ve reached a new stage of troubleshooting: Collaborate and Research. This is the humbling part where I admit I don’t understand why the issue is occurring and need to work with someone (or something) else to get the job done. This collaboration could be with a coworker, a knowledge base, a vendor, or a random stranger on the internet who had the same issue six months ago. Either way, I consider this a separate step in the troubleshooting process. From this point, I hope to find an answer to be implemented as a potential fix, but that’s not always the case, meaning I need to go back to the beginning and get more detail/context through communication.


Let’s say I’ve managed to find a “solution” to the problem, and I implement it. This is what I consider the Testing Phase, and from here you can either confirm the issue is resolved, or, once again, go back to the beginning and get more information. If the issue persists, I try not to re-enter the testing phase without additional communication, otherwise it feels like I’m shooting blind. Do you see the emphasis I’m putting on communication? I hope so.


As IT professionals we fight the stigma stating we’re “nerds who lack social skills.” If communication is a pain point for you and your troubleshooting process, I implore you to start sharpening this skillset. It opens a whole new world of professional and personal possibilities but also improves your troubleshooting. It’s important to note I’m not only talking about small talk at the watercooler or workplace banter with your coworkers. Communicating technical ideas to non-technical people is, in my opinion, one of the most important skills an IT professional can have. Failing to translate something technical to your users usually causes them to get confused and frustrated, which can snowball into mistrust and resentment toward you or your systems. Do your users hate calling IT? Have you considered there might be a breakdown in communication causing this behavior?


Here’s a little flowchart to summarize my thoughts. What does your troubleshooting process look like? What tools are you using, and how do you collaborate? Are there weak points in your process needing to be improved?