|
The Bitter
Network Administrator |
|
A
Website Dedicated to Computer Professional...and
some not so Professional |
Being a Good Tech is not enough
by Graham Parks

A couple of months back I was talking to a friend of mine who has recently
started a new job. He has spent some years working for a reseller installing
and maintaining all sorts of kit in all sorts of places. He is very
experienced, he knows what he is doing and does it well. He recently changed
jobs and became a sysadmin, a role he has not done before. Talking to him
recently made me realize the difference between a good tech guy and a
sysadmin.
When I talked to my friend he was slightly angry and stressed out because he
had been given a hard time by some of his users. It happened like this.
While doing some upgrades and installing new kit and throwing out very old
kit, he found himself with a few good condition fifteen inch monitors. One
Saturday he was in doing some extra work and swapped out a few really old
fourteen inch monitors for the fifteen inch ones. This is what upset the
users. What!!! Yes really! Apparently the users considered that the newer
monitors were not as clean as their old ones and complained.
Had I known what he was planning I would have warned him. Like my friend, I
have experienced this sort of behavior and know how people react. I asked
him if all the people who complained were women and he said they were and
asked how I knew. I do not want to appear sexist, but a man would not
complain about being given a bigger, brighter, better image quality monitor
with a slightly grubby case.
So I decided to put pen to paper and give you a few of my ideas about
non-technical skills and ideas I have found useful.
It’s All About Money
Business is all about making the boss richer. He calls it “The bottom
line” because he knows that if he were honest and told us he needed us to
work harder because his wife has seen a new dress she wants we would tell
him where to go. But, that’s just me being cynical!
It is true though, a business needs to make money and in my experience
technical people often forget all this as they get sucked in playing with
the latest Linux KDE release or trying out the Office XP speech feature to
make Word say rude things.
As a sysadmin, it is not all installing/fixing equipment and dealing with
the never ending cycle of backups, patches and user problems. You will, no
doubt, have your own ideas about how your network can be improved and in
order to realize your ideas, you will need to adapt the way you plan and
present your ideas.
If you want to convince the boss to adopt new technology, buy some more
storage space, upgrade software or take on new people then you have to speak
his language. You have to talk of business benefit. What will your new idea
do for the business? It all comes down to money. A saving in man hours, an
increase in quality or finding a fault in a process and curing it. It all
saves the business money and that is what will attract his/her attention.
You are no longer at school, telling the boss your idea is “cool” will
get you nowhere. Telling your boss the business needs a new gizmo is not
enough, they will want to see proof, costs, savings etc. Providing proof is
usually not that hard if your idea is a genuinely good one or you have
records of various aspects of your network.
Let me give you an example.
Disk Usage
Well all know that disk usage continues to grow for a variety of reasons and
that managing storage can be a pain. Some years ago I decided that the
company I was working for needed to increase disk capacity on the main file
and print server. I planned out what I though we would need and went to see
the financial director.
”We need to increase our file storage space” I told him.
”But we bought some disks only two years ago” was the reply.
Typical bean counter reaction, but I was ready for this and had all the
answers. Here’s how.
I always try and adopt a proactive approach to managing a network. I do not
want to be in the position of trying to get extra storage space approved
while keeping my fingers crossed that we do not run out in the next week. So
I kept a fairly simple record of disk space usage.
Once a week I took a reading of the disk space left on each volume and
entered it on a spreadsheet and used this data to produce a simple line
graph. On a small network this can be done manually, on a large one I would
recommend automating this process. There are several tools available. Have a
look on www.tucows.com Here is one cheap
example, watchdisk
Once you have a few months worth of data a clear trend can be seen. Using
this, I was able to confidently predict that I would run out of space in
three months. This gave me plenty of time to act to rectify this potential
huge problem. It also allowed me to slap a pretty coloured graph in front of
the Financial Director to back up my claim. Hard evidence is difficult to
argue with and the director had to consider my request.
However, he was still not happy and wanted to know where all the space was
going. I was ready for this as well. Each department in the company had been
set up with a shared area to store files. All I had to do was go to the root
of each department directory tree and record how big each was. This allowed
me to create another pretty coloured chart that showed which departments
were using the most space.
There’s more to the story. We did look at the possibility or archiving off
old files or leaning on the users to clear out their rubbish. In the end I
got the new disks and installed them at a time that suited me and had the
whole project complete a month in advance of my predicted zero disk space
date.
Easy! Literally five minutes work a week prepared me to avoid a big problem
and saved a lot of trouble. It also ought to earn you a few good points on
your annual appraisal.
This same data helped me a year or so later when we decided to archive old
data and make it available on CD. I was easily able to calculate how much
disk space we would gain and how much longer this would give us before disk
space needed increasing again. Weighing the costs of extra disks against the
costs of the archiving system was then easy to do and easy for the boss to
understand.
Records
The key to success in the example above was simple record keeping. I know it
is a chore and a pain to start with, but it can help you a lot.
What you record and how will vary depending on the size of your network, but
you need records. You need to be able to prove you have a problem before
anyone will hand over money to get it sorted. The exception to this is, of
course, when the boss has a problem. Suddenly proof, business need, cost
effectiveness, manpower required etc. go straight out the window.
Help desk logs
Very useful. But help desk systems cost a lot and for a small business are
not cost effective. However I recommend that even if you have to resort to
building a small Access database yourself you have one if at all possible.
If you have regular problems with any kit, or user, then all the historical
evidence will be here and you have the proof needed to get action taken.
Change Control
Keep records of what you do and when you do it to your network. This can
seem a pain, but when problems arise it can be very useful. Quite how
detailed you make it is up to you, but their can be unforeseen benefits in
implementing such a system.
I was working at a company where one person dealt exclusively with the main
database on a Unix machine. They were forever getting requests for changes
to reports, queries on reports, changes to product details and a myriad of
other requests. Although the detail might have been written down all the
requests were made verbally with demands that they be carried out ASAP.
When we introduced change control it was decided that all changes would have
to be documented. This was nothing over the top for small changes. Simply
who wanted it, when and details of the change and a few other items. What
gave us an unexpected benefit was the sign off signature. Once managers
realized they had to sign for all the changes they wanted and that these
could be tracked back to them, the quantity of requests dropped and the
quality of what was requested increased.
We had not anticipated this. It was not out intention to have this outcome,
but it made us realize that a lot of the changes we used to receive had not
really been necessary at all. People made the requests simply because the
work could easily be dumped on us. Once the process was formalized it made
them stop and think.
Uptime
Keep track of all unscheduled downtime. I once started getting a whole load
of earache from managers about downtime. So I started keeping records of all
downtime in working hours. This does not reduce downtime, but once I was
able to prove that uptime was usually 99.7% or thereabouts with the
occasional dip because of serious problems then I had the evidence to keep
the managers quiet. I found a report on the net that showed my uptime was
not unreasonable. I then put together a short report on clustering servers
and failover etc. including costs and sent it to the I.T. manager. I heard
no more. Surprise!
Also try and keep in communication with all your kit. Even if you do not
have enough money to rig everything up with SNMP clients reporting to some
central monitoring system, try using something like WS Ping Plus to make
sure your kit and comms links are up. It’s really embarrassing when you
find out about a server crash when a user tells you.
Communication
I’ll try and avoid sounding like some touchy feeling, patronizing,
interpersonal skills trainer here but some I.T people are not great at
dealing with non technical people. I include myself in this, although I’m
much better than when I started out. I’m not going to preach about dealing
with users face to face, I am sure you are all heartily sick of being taught
about this. I have a few extra pieces of advice.
Tell your users what is happening
Whenever I make any significant changes to the network I inform the users
via email. I keep it simple and in plain language. I tell them
1. What is going to change.
2. When the change is going to be made.
3. What effect it will have on them.
4. What to do if they think they have a problem or want more information.
Sometimes I even do this when the changes are going to be transparent to the
users. I am sure that most of you have made such changes only to be caught
out by some obscure knock on effect that does affect users.
By sending out this email, you cover your ass if something does go wrong. I
learnt this the hard way.
It also makes you look more professional. The downside is that you will have
to endure a few dumb phone calls from users, but what’s new there.
Once I got a reply from one such message from a senior manager praising me
on the quality of my communication.
Presentation
I used to be a trainer. I taught people how to use mainframe based systems.
Learning to teach a group of people was a really useful skill to acquire. I
know a lot of people hate this sort of thing and I fully understand, but
believe me it is worth knowing about. People write whole books about this
but I’ll keep in short.
1. If you are confident and professional in your delivery people will treat
you that way (mostly). If you sound as if you do not believe what you are
saying, why should anyone else believe you.
2. You need to get your message across successfully in order to get the
result you want.
3. Avoid jargon and technicalities, unless you know ALL your audience will
understand them.
4. Practice your presentation. Even if you lock yourself and away and just
talk to yourself, it helps.
5. Keep it simple. Visual aids are very useful, but do not overdo it. Do not
become a PowerPointer (http://www.thenetworkadministrator.com/BritishEnduserlanguage.htm)
Do not use too many slides, 30 should be considered a max for most
presentations.
Do not put too much information on any one slide.
These guidelines are not just useful in presenting to groups of people,
talking to senior managers can sometimes be a little daunting. Adopt the
same approach.
Ass Covering
Here’s a useful tip. How many times have you tried to get a manager to
make a decision without success? You know what you want, you know what needs
doing but you need to get agreement from someone. And that someone has a
habit of ignoring you. Put your request in writing, state the problem and
what your proposals are for dealing with it. End the message with the
following, “These actions need to be carried out soon so, if I do not hear
from you by insert date here then I will proceed as I have detailed
above”.
Now, if the manager does nothing, you just go ahead with your idea. If the
manager tells you not to do it, then he/she has made a decision and your ass
is covered. If the manager says nothing, you go ahead and it all goes wrong,
your ass is covered because your sought the advice/agreement of your manger
who failed to act. Whatever the outcome, you are covered.
Not ASAP
When you get that call from a user with a problem, do not deal with it
immediately. Even if you are sitting on your backside reading today’s
Dilbert, wait for five minutes. I have found that an awful lot of end user
problems disappear in that five minute period.
Sounds a bit cynical, I know, but one downside of offering decent support is
that your users find it easier to dump everything onto the I.T. department
rather than sort out something trivial themselves. Try this. Next time
someone call you with a “How do I?” type question for Word, Excel etc.
ask them what the help text says. I bet you find 95% or more users do not
hit F1 unless prompted to.
Everything I have covered really boils down to one thing. Be professional.
Manage your systems, don’t let them manage you. Do not just run around
sorting out problems as they occur, although we all end up doing this
sometimes. Your boss and other senior people will respect you more. It will
make your life easier in the long term.
Any feedback or comments welcome.
graham@thenetworkadministrator.com
|
|
|