By Becky Roberts
You think you’re a good communicator: You keep your users informed and you
listen to their problems. So why is it that no one appears to read your
e-mails or seems capable of following your instructions? Are you surprised
to learn that the users have been living with computer issues rather than
ask you for help? These are all signs of a breakdown in communication--which
we, as support techs, frequently misinterpret as user indifference or even
stupidity. Before long, we find ourselves on a downward spiral toward
complete communications failure. Even with the best intentions, it's
possible to sabotage our own attempts to communicate with the users by
inadvertently committing one or more of the following deadly sins of
miscommunication.
1. Inappropriate nonverbal communication
Our words may say “Absolutely, yes, of course I don’t mind helping you
change the toner cartridge,” while our facial expressions, tone, and body
language simultaneously scream, “You complete and utter gimboid, do you
honesty think that I spent four years in school, have an IQ of 167, and
earned 53 technical certifications just so I could change your toner
cartridge? Would you like me to breathe for you too?” . It's not necessary
to be a behavioral psychologist to know that tutting under your breath,
rolling your eyes, and suppressing little smirks combined with your
apparently kind words, sends a patronizing, insulting message to the user.
Instead, if you are frequently asked to perform such seemingly menial tasks
as changing toner cartridges, turn it into an opportunity to educate and
empower the user.
2. Showing off
Just because we happen to know all the correct technical terms and concepts
does not mean we should use them when communicating with users. Providing
instructions that are overly technical and contain far more information than
users need is not the most effective means of conveying our message. Instead
of impressing a user with our superior knowledge, it alienates and belittles
them and makes us seem supercilious and pompous. For example, telling users
to clear their cache and delete their objects to solve a browser issue may
be technically correct. But the chances are, if a user knows how to carry
out these instructions, he or she has already done it. Try giving the user
click-by-click instructions on how to perform these tasks, perhaps
accompanied by a single line of explanation in terms the user can relate to.
Aim to impress with your attitude instead of your knowledge.
3. Losing patience
If William Langland had not coined the expression “Patience is a virtue” in
1377, I am firmly convinced that it would have been invented by an
enlightened support tech sometime during the latter half of the twentieth
century, just as humans were being introduced to computers in the workplace.
Even though the computer literacy of the general working population has
steadily improved over the intervening years, there always seems to be at
least one user who simply doesn’t get it, and whose persistence in demanding
help for the same problem stretches our patience to its breaking point.
Calling the user a brainless twit and bashing him or her over the head with
a gel wrist relief may provide a moment of immense satisfaction, but it's
likely to result in a miffed user and an unemployed support tech and should,
therefore, be avoided at all costs. A better alternative is to develop
techniques for (a) preventing such situations and (b) handling them
appropriately when they do occur.
4. Being dismissive
Imagine going to see your doctor because you have a mysterious green knobbly
growth in your arm pit and all he does is pat you reassuringly on the back
and tells you not to worry but do come back in a month or two if it hasn’t
gone away. How would this make you feel? What if the doctor didn’t even look
at the growth? This is precisely how we make the users feel when we fail to
engage with their problems, dismissing them with platitudes and vacuous
reassurances. Even though we may be 100 percent certain that Bob’s computer
isn’t really taking twice as long to boot up and that Marcie must be
imagining that high-pitched whine, telling them not to worry about it and to
let you know if the problem doesn’t go away achieves absolutely nothing
except to make them feel stupid and insignificant. Whether a computer
problem is real or perceived makes little difference to users. All they know
is that they have a problem that needs to be resolved. Even merely perceived
problems can be fixed with some sensitivity and a little creativity. However
insignificant the issue, by engaging in the problem and treating users with
respect we increase their confidence in us and open the lines of
communication.
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 organizations, 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 organized 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 laborious 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 summarizing 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.
Becky Roberts has worked as a database developer for the British aerospace
industry, a mainframe programmer for a ceramics manufacturer, an
applications developer for an employment agency, and an IT-do-everything
person for international management consultants. She’s currently playing
with the networks in a chemical plant in Texas. Becky is an avid mountain
biker and rock climber; she lives in inner-city Houston with too many pets,
including four cats, three ferrets, and two teenagers.
