Most IT pros will do whatever it takes to ensure they perform well on the job – they’ll update certifications, take online courses at home, come in early, leave late. So after all that effort, it would be a shame if their careers were stifled because of something as pedestrian as poor interactions with end users.
But sometimes the biggest mistakes are the ones we don’t even know we’re making. Here are six of the most common blunders that IT professionals make in their user encounters.
- Talking in techie lingo
Many IT professionals don’t really think about the actual words they’re using. But as Steve Aponte, program director at Intelligent Product Solutions, puts it, “You often know when you talk to IT that you’re talking to someone from IT. They have a language to themselves.”
What does this language sound like? Think of how you’d explain to a user why they’re having problems with a network connection. Would you tell them the DHCP server didn’t give their PC the right IP address? Well, Aponte says, even though that may be the exact problem, “the user may have no idea what that means.”
The result: Communication breaks down, and frustrations boil up. “IT may not see a problem with the language they’re using, but it is confusing to the average, everyday end user,” says Tyler Mikkelson, team lead at technology talent recruiter Mondo in Chicago. “They need to use terms that users can fully understand.”
For instance, Aponte suggests, “I could say, ‘Every computer has its own IP address, and in order to communicate on the network, it needs to get that from the server, and it looks like yours didn’t receive the address it needs.’ It’s all about which words you choose and using less technology jargon.”
This can be a difficult habit to break because most techies are accustomed to speaking in that language, Aponte says. “If your mom called and needed help with her e-mail, talk in that language,” he says. “It changes your whole demeanor.”
- Not communicating at the right level
Of course, not all users are alike in their technology understanding, and without a sensitivity for the user’s starting point, IT professionals can end up aiming too low (and insulting them) or too high (and confusing them).
Ken Piddington, CIO at MRE Consulting, suggests starting out using layman terminology and then adjusting your language as you begin to understand that person’s level of understanding. This requires developing a few simple communication skills, like looking for feedback through body language, facial expression or just out-and-out asking for it. “It’s important to look for signs, or ask, whether they understand what you’re saying,” Aponte says, “and if they don’t, to explain it in a different way.”
To be sure the understanding is flowing in both directions, Aponte says, IT professionals should also summarize back to the user what they think the user is saying. “It gives you an opportunity to resolve issues on the spot rather than walking away, trying to fix something and coming back only to find out there’s been a miscommunication,” Aponte says.
You might even learn something from what the user has to say, Piddington points out. “With today’s consumerization of IT, my 9-year-old can set up a wireless network,” he says. “We’re accustomed to thinking users are less technologically capable than we are, but it’s often a case where we can work together to solve a problem.”
3. Not understanding the business
IT professionals have long been advised to better understand the business, but something they often overlook is how business activity is impacting users in real-time. This awareness can help you avoid providing support or system maintenance at the wrong time of day.
Piddington provides the example of a trading company, which experiences peaks and lulls of activity at very specific times of day. During one of the peaks is not the time for a help desk professional to respond to a trader’s request for a trivial fix to his laptop. “He’s going to be short with you, and it will hurt the credibility of yourself and the IT organization because it’s clear you didn’t understand the situation,” Piddington says.
Also keep an eye on what’s going on in the market or industry outside the four walls of your company, Piddington adds. Back to the trading company example, Piddington says, “If the market just tanked, you should be aware that everyone’s focused on trying to stop the bleeding.”
- Seeing users as customers
Although this might sound contradictory to what many companies promote, Piddington sees a danger in thinking that users are customers. IT, he points out, is just as much a part of the business as accounting, sales, production and HR. So, logically, “Your customers are the people who buy your products, not who you provide service to internally,” he says.
Seeing internal users as customers, he says, can block IT from understanding how they --- like their business counterparts – are responsible for supporting the business in its goal to generate revenue and maximize profits.
Seeing the IT organization as a service department is dangerous, he says, because it relegates IT to a back-office function. “I used to hear, ’The business said this.’ But who’s the business? We’re all the business. IT needs to emphasize how it contributes to the goals of the organization. The customer is the one buying our products and is the reason we’re in business.”
- Over-promising
Everyone wants to be the hero, the one who saves the day. But there’s what you want and what you can actually do. And if you commit to finishing something “by the end of the day” and then fail to do that, no one is going to be happy just because you had good intentions.
“If your phone system is crashing, and your e-mail and servers are down, and 30 end users are asking for help with their computer, you can’t promise everything will be fixed in the next hour,” Aponte says. Those 30 people who were temporarily happy with your promise will soon be frustrated because you missed the deadline.
Instead, IT should create SLAs that define how it will respond to help desk requests, using a system of critical, high, medium and low priorities. It should define what a critical request looks like (something that will impact the end customer or keeping an employee from carrying out a normal business function) and prescribe a defined time window, say 30 minutes, in which it can reasonably attend to it. Something that is lower in priority could have a promised delivery time measured in days (a PC that won’t connect to a particular printer when there is another one down the hall).
- Establishing the wrong priorities
Another common mistake is catering to executive requests for help even when the need is less crucial than another problem at hand. Instead, Aponte says, IT should prioritize based on the issue, not the person. For instance, a local printer failure is always lower priority than a laptop hard drive failure, whoever is experiencing the problem, he says. “Often, IT will run to the president and help with the local printer even when there’s another printer right around the corner,” he says. “Meanwhile, there’s a guy in the field with a hard drive failure.”
Bottom line: Just because the person making a request has a higher title doesn’t mean you should give him or her priority. Once again, Aponte says, it comes down to setting expectations and communicating effectively, even in the sensitive area of dealing with a high-level executive.
In IT, as in life, it is only by recognizing our mistakes that we can correct them. Don’t let these user errors get in the way of your career success.
Brandel is a freelance writer. She can be reached at marybrandel@verizon.net.