Posey's Tips & Tricks
When Fixing IT Problems, Is It Ever OK To Guess?
DIY troubleshooting only works for IT problems you're certain you have the skills to fix. For everything else, it's better to call the experts.
Lately, I have been spending a lot of time thinking about IT skillsets. Modern IT systems are so complex that it is nearly impossible for an IT pro to have a comprehensive knowledge of every system their organization uses. That being the case, there will inevitably be issues that the IT staff does not immediately know how to correct.
So when this happens, is it ever OK to take a guess as to how to correct the problem, or is the answer to always call an expert?
I'm not sure there is an answer to this question that is applicable in every situation, but I think a decision has to be made based on the risk and consequences of guessing incorrectly. Let me give you a couple of examples from outside the world of IT.
Over the past couple of weeks, I have been doing something a bit out of the ordinary: automotive repairs. I have a 16-year-old vehicle that is unfortunately too large to fit into my garage. The years of allowing it to sit out in the weather have really taken their toll; some of the vehicle's rubber seals have dry-rotted and allowed rain water to get in, shorting out the electrical system. Thankfully, this vehicle is not my daily driver, but I do use it from time to time. Because it has relatively low mileage and is otherwise in good condition, it seemed prudent to repair the vehicle's various problems rather than buy a new one.
Unfortunately, automotive repair has never been my forte. I have family members who are real gearheads, but I definitely did not inherit the automotive gene. Even so, I decided to attempt to do the repairs myself. It has definitely been a learning experience, and I made plenty of mistakes along the way, but the repairs are nearly complete. I'm just waiting for one last part to be delivered. Even though the repairs were way outside of my comfort zone, I took a chance and have thus far been successful.
In this particular case, the risks were minimal. At worst, I might do something stupid and make the vehicle undrivable. If that were to happen, I know a mechanic who makes house calls. On the other hand, if my efforts are successful, then I will have saved a lot of money by doing the work myself. As an added bonus, I will have learned about automotive electrical systems in the process. In this case, the risks were minimal and the rewards were substantial enough that it justified taking on a project that I initially knew nothing about.
Now, let me tell you about a different learning experience. Over the last several years, I have spent a significant amount of time studying medicine in relation to my spaceflight training. At the end of one particular course, the doctors who taught the course gave me a skills assessment to see if I could accurately diagnose and treat various types of injuries. During the assessment, one of the doctors threw me a minor-league curve ball by giving me a situation I did not immediately know how to handle. I tried to think logically about the situation and used what I already knew about trauma care to make an educated guess as to how to treat the patient.
Once I was done, one of the doctors told me I had treated the injury correctly and asked how I knew what to do. I answered honestly: I guessed. The doctor then explained that even though I had done everything correctly I had violated one of the most fundamental rules of medicine by doing something that was beyond my skillset. If that had been a real-world situation, I could have jeopardized the patient's life by making a diagnosis and administering care without the proper training. Never mind the fact that I could have faced severe legal consequences if things had gone badly.
Clearly, taking a guess was not the best course of action. This was one of those situations in which the risks posed by guessing far outweighed any potential benefit.
Let's circle back to the world of IT. As with medicine and automotive repair, one has to consider the risks and potential consequences when deciding whether to attempt to fix an unfamiliar problem. The biggest factors to consider are the system's importance, the consequences of making a poor decision, and how long you can tolerate the system being down.
With that in mind, guessing how to fix a system that is running a mission-critical workload is always a really bad idea. Over the years, I have seen a few situations in which an attempted repair of an IT system went horribly wrong, resulting in data loss. A mistake like that can be a career-ender. It's just not worth the risk.
I will be the first to admit that there is a big difference between guessing how to fix a problem and using the available resources to figure out how to correctly diagnose and repair a previously unfamiliar problem. Even so, I would recommend calling technical support any time there is an issue with a mission-critical workload -- unless you know you have the skills to fix the problem.
There are two reasons why I say this. First, if a problem is unfamiliar to you, then it is probably going to take some time for you to diagnose it and figure out the correct course of action. Conversely, the support engineers probably see that same problem all the time and can therefore fix it a lot more quickly than you would be able to.
Second, if something goes wrong and SLAs are violated or data loss occurs, then you are in a much better position to defend yourself against being terminated if you can prove you did the right thing by going through technical support.
On the flip side, there are plenty of situations in IT in which it's fine to guess about how to fix a problem. For example, there is little -- if any -- risk associated with guessing as to how to fix a problem with an application that is installed on a user's desktop (assuming there is no data on the device). At the very worst, you might waste some time or have to reimage the operating system. Just don't fall into the trap of spending too much time trying to fix the problem.
This brings up an important point: You have to consider what your time is worth.
Many years ago, I saw someone who was brand-new to IT spend two days diagnosing a disk controller failure on a PC. Given this person's hourly salary, it would theoretically have been less expensive to buy a brand-new PC than spending two days trying to sort out a hardware problem.
Don't think I am trying to discourage the do-it-yourself approach; believe me when I say that I am a big-time do-it-yourselfer. Over the course of my career, however, I have learned that there are situations where it is best to let someone more knowledgeable take over, even if there is a strong temptation to fix the problem yourself.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.