I have been in the computing industry for almost 15 years. In this time, I have encountered enough anecdotes where I am comfortable with the claim: A lot of people don’t like their IT department. There is even a Forbes article about people hating IT. I work in my company’s IT department back office as a Linux and Unix Systems Administrator. I am writing this article to help people in any part of an organization get more from their IT people.
Think about how much an organization relies on its computer infrastructure. It is relied on for accounting, billing and payment processing, inventory and asset management, payroll, and customer service. Good IT systems aren’t an optional if you want your organization to fulfill its purpose. Bad IT can cost you your organization. Here are few cases of bad IT that had huge costs:
- Email Provider Loses Almost 20 Years of Data
- Healthcare.gov Budget Overruns
- Airline IT Outage Delays Flights
Everything in this article boils down to one thing, good communication.
Be Nice
Mutual respect and consideration help improve relationships significantly. We need each other, so we should make an effort to have good relationships.
Keep in mind that IT people are humans with the same emotions, needs, desires, and families as anyone else. One Thursday night after I had been asleep for a few hours, I wake up to the sound of my phone ringing. It was the person from our finance department who processes payroll. They told me that they were unable to get our payroll file to the bank. I grabbed my laptop, login to our network, and after an hour or two we were able to get the information to the bank. I went back to sleep and go into the office the next morning at the usual time. Sometimes our lives have to take a back seat to keeping the organization operational.
According to this 2015 Dice article, a lot of tech workers are unhappy with their jobs. The reasons are things you would expect from any unhappy employee, such as coworker relations, advancement, feeling valued, etc.
My point is, there is a good chance a person may have been up half the night and generally unhappy with their job. I’ve been there. I can only speak for myself, but all I ask is for you to be cordial and have realistic expectations. It doesn’t sound like much, but it makes all the difference in the world.
Getting Help
There are a few things you can do to get better results when reporting problems to IT. We want to get back to what we were doing just as much as you. Faster fixes are better for both of us, since when we aren’t fixing things, we are often doing things to prevent problems and improve the systems you are using. Even if all we do is service end users at the help desk, it will improve response times for other people.
Describe Your Problem Well
When submitting trouble tickets or emailing us, clearly describe your problem with as much detail as possible. Systems that seem simple like a web based time sheet are often very complex. The more details we have, the faster we can isolate the problem. Here are examples of a good and bad description of a problem with a time sheet application.
Bad:
My time sheet isn’t working.
Good:
When I try to submit my time sheet, the following error message pops up: “Error 123”. Here is a screen shot. I am able to do other things on the portal, just not my time sheet. My PC is part of the “special” group that have different PCs than most people. It is working for everyone else in my department.
The bad example doesn’t tell us much. There are tons of reasons it might not be working. Without more information, we can’t do anything other than ask you for more information.
The good example gives us a lot to work with. The screen shot will help us determine if it is a simple typo. Perhaps you typed the letter ‘O’ instead of the number 0. Knowing if you are the only one helps us decide where to start looking. The error message might be something we have seen before. Knowing that your machine might be different than most clues us in that it might be worth considering it as the source of the problem.
Error Messages
If you are going to contact us about a problem, do not do anything to make the message go away until you have copied and pasted the text of the message, taken a screenshot, or, preferably, both. They can be very helpful for us to figure out what is causing your problem.
If you are submitting a ticket or emailing us, please send us exact error messages. As mentioned before, we may have seen it before and have a quick fix for it. Even cryptic or obscure error messages are helpful because we can usually look them up in the product documentation, search the web for them, or in the case of locally developed or in house applications, read the code that generated it. If we end up contacting a vendor for support, they are probably going to ask for it.
Send Good Screenshots
We like screenshots– they make it easier for us to troubleshoot your problem. The best thing to do is send the whole screen. Here are a few examples that demonstrate why.
This screenshot is ok, but it could be better:
A typical screenshot.
It helps us get a general idea what is wrong, but leaves multiple possible causes for us to eliminate. Since it is a problem with a web application, having the URL bar in the screenshot would help tremendously.
The same error message, except this time the screenshot is the entire screen:
Screenshot of whole screen.
In this example, seeing the URL browser makes a big difference. The red box around the address bar indicates the problem. The URL is for my wireless access point. I don’t have it configured for https. If you were an employee in the company I work for, having the screenshot with address bar showing this would save us both a lot of time.
Here is a screenshot after the fix.
The correct URL.
Notice how I removed https://, which means the connection will use http instead of https.
Avoid the XY Problem
The XY problem is when you have already solved a problem, can’t get the solution to work, and ask for help.
I almost always ask people who request help: “Why are you doing this? What are you trying to do?”
Suppose a developer in my department has a Linux machine. They come into my office and ask me for help with a problem they are having with their Samba configuration. I respond with the questions above. They reply, “I am trying to move this jar file containing from my Windows PC to my Linux PC.” I might say, “If it is just one file, I wouldn’t bother with Samba. I would download WinSCP onto your Windows PC and use it to transfer the file. Your Linux box most likely has an SSH server running out of the box that will allow you to transfer files with SFTP. It is much easier to set up WinSCP than Samba.”
If you are asking for help from your IT department, let us know what your end goal is. I’m not saying you shouldn’t try to figure it out or tell us what you have done so far. It may be the case that what you came up with is the best way to accomplish your goal. There is also a chance we have experience with your problem and have an easier, cheaper, or better way to do it.
Accurately Describe Priorities
I was recently asked to get a web application up and running as soon as possible. I spent most of my time for a week working on it. The main users didn’t bother to start testing it for almost a month.
I understand why some people claim things are more urgent than they are. They have probably had experiences where accurately reporting the priority resulted in it not getting done or an excessive wait time. This is a double-edged sword. If you do this and it turns out not to be as urgent as you claim, it hurts your credibility. Next time you come to us with an urgent request, don’t be surprised if we respond with some probing questions to ensure it actually is urgent.
Follow Up
We are human. We forget things and even procrastinate on occasion. If you aren’t getting what you need in a reasonable amount of time, a quick follow up email is usually all it takes.
When we ask you for more information, your response time and availability to work with us is a good indicator of how important (or not important) your request is.
Understand Policies
Sometimes policies are truly bad, such as common password policies, sometimes they exist for a good reason.
We have to keep your systems functional and secure. Think about the most damaging thing you can do with the access you have. It is probably more costly and damaging than you think. This why policies that limit access exist. Limiting your access isn’t because we don’t trust you and think you are evil. It is to prevent the damage that can be caused if you are hacked or conned. Our security measures can only do so much. There are things that most users can do to compromise the security of an organization. Hackers know this and use social engineering techniques to get you to do things for them. Some hackers that use social engineering are very, very good. A well known hacker known for being a master at social engineering explains how it works.
Depending on the system and industry, we often have to do things for compliance reasons. For example, if we handle credit cards, we have to comply with PCI DSS. Sometimes our policies aren’t by choice, but due to third party requirements.
Seriously Consider Our Advice
In my opinion, one of the worst things you can do to your organization is ignore good advice from your IT department. Things like backups, redundancy, patching, and penetration testing cost time and money. I can’t answer whether the consequences of bad practices are always more costly than good practices. It depends on your organization. Here is some food for thought. IT problems have caused businesses to go under. This Reddit discussion has some examples of it happening.