Despite our best efforts in preventative maintenance and monitoring, our technology is destined to fail. Our hope is for a graceful failure but inevitably it ends up more like a catastrophe! While I’m being slightly hyperbolic, the core statement is still true: stuff breaks. This is where the art of troubleshooting comes in.
Yeah, that’s right. I said “art,” not “science.” While there are many variations on troubleshooting methods and models, and many training courses and certification paths that cover steps to troubleshooting, the best troubleshooters don’t necessarily follow a strict manual or script. They use their knowledge of the working system, past experience and yes, a little intuition, to determine the root cause and a path to a solution. It’s not always a straight path. Even the most experienced troubleshooter can be surprised on occasion by an off-the-wall solution.
For you fledgling troubleshooters out there, here are four tried and true guidelines to help you work through a challenging repair, reaching a solution without much wasted time and resources.
1. What’s wrong?
It’s nearly impossible to properly fix a problem if you cannot see the problem, especially with computers. There are really only two ways to “see” the problem. Either someone can explain it to you in the correct amount of detail or you have to somehow recreate the problem in order to observe it yourself. Considering that most issues present to basic users, individuals with little to no technical skillset, it’s unlikely you’ll get everything you need from them. So, we must attempt to get the computer to do what the user claimed it did. In the end, if you cannot reproduce it, the best thing to do is nothing. Tell the user to get screenshots of the issue the next time it occurs, or to allow a technician to see the problem before it goes away.
2. Keep it simple, stupid!
No, I’m not calling you stupid … it’s an expression. But I like the sentiment. It’s easy, especially as we get more technical knowledge and experience, to get really creative in our troubleshooting and seek out complex (and exciting) solutions. Maybe it’s because we are trying to impress our boss. Or maybe it’s because with experience, we forget about the simple stuff. But I would argue that finding simple solutions will make your boss happier with you.
Let me say it this way, if you cannot connect to the network, would your boss prefer a request for a new router or to swap out a cable? Probably the cable, because the solution would be cheaper, faster and the least disruptive to the network. As a general rule, try to think of the cheapest and easiest solutions first before moving on to more challenging and expensive options. And don’t talk yourself out of the more obvious solutions, either. While we tend to poke fun, “is it plugged in?” “is it turned on?” and “have you tried turning it off and on again?” are often successful solutions to fixing most of our issues. It is estimated that more than 80 percent of networking issues are related to the Physical Layer of the OSI model.
3. Practice, practice, practice
There are a lot of books, courses and study guides on troubleshooting. As an instructor, I find great value in having resources to consult while getting started as a technician. But if you really want to excel as a troubleshooter, just get in there and do it. Find a broken computer and try to make it work. Hands-on experience is invaluable in building your skills. You can read about bad memory, but until you’ve actually held a memory module in your hand, heard those beep codes during POST or replaced a module on a motherboard, you don’t really understand memory errors.
4. “I don’t know”
That phrase often strikes fear into the heart of a technician. No one likes to admit when they are in over their head. But a good technician doesn’t run from lack of knowledge. Instead, not knowing something should drive you to learn. It’s especially difficult when you have a customer or end-user waiting with bated breath for you to swoop in and save the day. You don’t want to let them down. But I guarantee, a user will be much happier if you say, “give me a few hours to research this issue and I’ll get right back to you” than if you waste time pretending to fix something even though you have no idea what you are doing. Honesty does go a long way in this situation. But where do you go to get more information?
| For more: troubleshooting jobs |
