I’m pretty sure everyone has had an experience with tech support where they called into question, either verbally or mentally, the qualifications of the person on the other end of the line. Its even more frustrating when that person is struggling through the same problems you were struggling through, and seems to know little about the problem or how to even begin to fix it.
The truth is, your IT guy doesn’t have all the answers in his head already. He has to understand the problem and develop a solution. Technology is as powerful as it is today by compounding the knowledge of thousands of programmers over decades of development. This knowledge combines on our technology to create an ecosystem. In order to diagnose problems in this ecosystem, one must understand what makes it tick.
Your IT guy knows these ecosystems. He knows how the different components react with one another. He knows what components require other components. He knows what components conflict with each other. But no two ecosystems are alike, and it takes your IT guy time to build a representative model of that ecosystem in his mind. You don’t pay your IT guy for fixing your problems. You pay him for knowing how to fix your problems. If you were paying him for simple action without knowledge you wouldn’t need an IT guy at all. Anyone could do it!
So What’s Taking So Long?
Your IT guy is going to want to verify the problem for himself. This doesn’t mean he doesn’t believe your description of it. This means he needs to see for himself all the factors that go into the problem, and what about the result was undesirable. He will want to see the affected system. He will want as much context about what’s going on as possible.
He may want to setup his own ecosystem where he can tweak some of the variables and recreate the problem on his own. This will allow him to measure the problem and the effectiveness of his solutions. This will also help to identify anything about the problem that you might have missed. Maybe the problem you’re reporting is a side-effect of a larger problem.
He’s also probably going to search online for other instances of the problem. As much as this can be seen to non-techies as a weakness, it is most certainly a strength. There’s millions of people out there searching for solutions for things online. Why duplicate work when someone else could already have the answer? If you’re considering shaming IT for utilizing an internet browser because you don’t consider it work; you’re costing yourself productivity. It’s like telling a mechanic to use a ratchet instead of a pneumatic wrench because he might use the air compressor to paint his car instead. Besides, learning is work. If your IT person didn’t have a knack and passion for learning they wouldn’t be in IT in the first place. You should encourage your IT personnel to set aside some time on a regular basis for learning new skills and researching things they aren’t confident about. This will pay off in the long run when your IT staff are better prepared to solve problems and better equipped to tackle projects. It also increases morale which improves productivity and effectiveness.
Are You Sure He’s Not Just An Idiot?
That depends. I know I certainly don’t have a 100% solution rate and I sleep just fine at night. Some problems can require expertise outside what you’ve got, which is why it’s important you allow your IT people to learn and expand their skills on the job. You can consider lack of specific expertise the fault of the IT person, but keep in mind that NO IT person on Earth possesses expertise in all subsets of IT. It’s just too much for one person to know. Take me for example. I can write computer programs and scripts in 6 Turing-complete languages. I know 4 markup languages and am familiar with 2 database engines and their query languages. On any given workday I’ll use 4 different PC operating systems. While that sounds impressive, and I’m quite proud of myself, there are still dozens (if not hundreds) of common languages, databases, and OS’s that other shops require and I’ve never seen before. So expertise is a matter of context. Plain and simple.
Of course some bugs are just outside the scope of IT in the first place. Even the best IT person can’t solve a bug in proprietary enterprise software. The best they can do is communicate the problem to your software vendors and hope that they take the problem seriously. Perhaps an even larger subset of problems are user-created. That means that if your other users were more knowledgeable that they would never have experienced a problem in the first place. As tempting as it might be to lay all of your organizations problems at the feet of your IT department come review time you must realize that not every problem has a solution. There are other metrics you should use to measure the performance of your IT group.
What differentiates a “good” IT person from a “bad” IT person, from a problem solving standpoint, is:
- How well they organize themselves and their tool-chain,
- How well they keep track of problems they encounter and solutions they deploy,
- How proactive they are towards avoiding problems in the future,
- How automated their operations are,
- How willing they are to change the way they operate once they realize improvements are possible.
- How well they communicate with the people they’re helping.
- Do they follow-up?
How Can I Help IT Help Me?
Report the issue promptly and include plenty of information. Don’t be offended if they seem to re-verify what you’ve given them. It’s nothing personal and it’s not because they don’t trust you. This story about a 500 mile email reminds me to always take a client for their word. After that you will simply want to give them space.
After your ticket is closed you should be sure to report any recurrences of the issue to the same person you reported the original issue to. If a developed solution stops working and IT isn’t made aware they may continue deploying an ineffective patch and making things worse rather than better.
Ultimately being understanding of the fact that solving IT problems isn’t an exact science is the best thing you can do for your IT department. Sometimes just trusting that they want to solve your problem as much as you do is all it takes. Sure it’s hard watching someone fumble around the same buttons you were just fumbling with, but that’s the process just about any IT professional is going to take.