#5: Failure to inform
This may seem like stereotyping, but in general geeks are
not natural communicators, at least not when it comes to communicating with
members of our own species. Unfortunately, the ability to meaningfully
communicate with fellow human beings is a prerequisite for being effective in
our role as support techs. In many organisations, the support tech is the
user's prime interface with the IT department. Support techs function as Babel fish, translating
between geek and human, and are ultimately responsible for ensuring that users
are kept informed and up to date.
Constant communication is a critical part of fulfilling any work order, from acknowledging its receipt all the way through the process to a follow-up phone call to make sure the user is satisfied with the work performed. Often, a user can accept a delay provided he or she knows about it in advance and can plan accordingly.
#6: Lack of documentation
Not providing the users with consistent, clear, and easy-to-follow
instructions is another way in which we frequently fail to communicate. Various
aspects of our jobs require us to write user-consumable documentation, such as
instructions for new procedures, explanation of corporate computer-usage
polices, and manuals for new employees. Before distributing new documentation,
test it out on a few users. Well-written documentation, kept organised and
up-to-date, should ultimately save you time, as it provides users with an
immediate resource for answering their questions.
#7: Lying
What should you do if you're asked to perform a task you
find labourious or boring? Or what if you're asked a question to which you don't
know the answer? What if the answer to a user's inquiry is something that will
make them unhappy or that they don't want to hear? In such circumstances, bending
the truth or misrepresenting the facts can be alluring, especially if the lie
seems harmless and the chances of being caught are small. Is lying to the user ever
justified?
Sometimes it's necessary to simplify the facts to give users an explanation they can comprehend, but this is different from deliberately lying to avoid work or save face. Many years ago, I worked with a senior support tech who was in the habit of blaming Microsoft for everything. When users came to him with a problem he could not immediately resolve, he would tell them it was a Microsoft issue and they just had to live with it. After awhile, users stopped going to him with their problems and he took to bragging about what a great job he was doing, as his users had so few issues. This situation continued until the next IT reorg, when he was assigned to a different group of users who were more computer-savvy and accustomed to being treated with more respect. A few weeks later, the tech was out of work due to the high level of complaints and his declining skills.
In short, when presented with a problem we can't resolve, for whatever reason, it's far better to be direct with users and help them find a resolution by some other means rather than mask our ignorance or unwillingness as an insoluble technical issue.
#8: Giving too much information
Honesty may be the best policy, but this does not mean it's
appropriate to overburden the users with too much information. A mother of five
grown-up boys once told me that in her experience, the average teenager will
tune out all but the first three sentences of any lecture... so you want to pick
those sentences carefully. It may be unfair to compare users with teenage boys,
but the principle still applies: Limit communication to what's absolutely
essential and don't expect users to absorb too much information at once.
It's possible to fail to communicate by overcommunicating, in terms of both frequency and detail. If we e-mail everyone in the company every time the slightest imperceptible change is made to the users' environment, many of the users will simply ignore the messages. Before long, work orders to set up inbox rules deleting messages from the IT department will start flowing in to the help desk.
Limit mass e-mail to the users who will actually be perceptibly affected by an upgrade, downtime, or some other change. If the impact is for a limited period of time, such as a lunchtime reboot of the e-mail server, set an expiration date and time on the message. Be careful not to overwhelm users with details or explanations that aren't relevant to them. For example, if the e-mail server needs an unexpected reboot at midday, give the users the time, expected length of outage, what it means for them, and what -- if anything -- they need to do. Users don't need to be given full explanation of why the reboot is necessary, although a single sentence summarising the problem may help them appreciate the urgency and is more likely to elicit their cooperation.
#9: Not providing training
Training is not restricted to sitting in a classroom for
three days learning how to create a PowerPoint presentation. Support tech-provided
training can be as simple as a 30-second demonstration to a single user on how
to add a contact to his or her address book or as complex as a multi-day onsite
class on advanced report writing in Crystal. Even if providing training is not
part of the support tech's formal job description, it's almost impossible to
effectively fulfill the job function without training users. Some techs
deliberately avoid educating users because they regard knowledgeable users as a
threat to the integrity of the network or to their jobs. Although these
concerns should not be dismissed as mere paranoia, they aren't valid reasons
for failing to improve the computer literacy of users.
#10: Failing to listen
Communication is a two-way process. As support techs, we
need to actively listen to our users. By definition, our role is to support our users, to enable them to
perform their job functions, something we can hope to do only if we have a thorough
understanding of their needs. As time allows, listening can be a proactive process,
with the support tech spending time with users to learn their routines and to
see where technology can be applied to improve productivity or safety.
Opportunities for user feedback can be created through feedback forms, satisfaction surveys, follow-up phone calls, and even brown bag lunches. Although it may not be possible or even desirable from a business standpoint to implement all of the users' requests, without making a concerted effort to align the IT function with the business directive, it's all too easy for the IT department to become wholly self-serving and to perceive the users as little more than an inconvenience.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2006 TechRepublic, Inc.
