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 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.

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.

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.

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.

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 ( 
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.

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.