Slashdot Mirror
Making the Most of IT support?
wetfeetl33t asks: "On Slashdot, we've seen quite a few stories about employees who are unhappy with their company's IT department, or are seeking advice on how they can whip their company's IT department into shape. So, enough of the complaints about the supposed stupidity of technicians, the incompetence of sysadmins, or the excessive network down time. A better question is: how can users work peacefully and effectively with their IT department and make the interaction between the IT people and other employees as productive as possible?"
Isn't it obvious?
Treat the people with some respect. Not only is it the right thing to do, but they'll probably fall over from you even doing it. Most IT people I know get treated like crap, and they don't deserve that.
Nobody does.
I find that bombarding IT with little requests like help with my desktop background, system volume, printers, plugging peripherals like my iPod into the desktop, and a bunch of other things that I could presumably do myself really helps keep those IT monkeys busy running up and down the stairs from their dungeon to my ivory tower.
The networks seem to be okay, and I have all my files, so it's not like they have anything better to do. Maybe they'd rather be surfing Slashdot. I don't know. But I'd rather they lost some weight and became more pleasing to look at. All the running around is helping their looks.
Maybe we should also install a shower...
When Joe Cubicle calls the building manager about his heat or AC problems, he has (or soon learns) a reasonable expectation of what he can ask for, and what will get done for him.
/Napster /Skype / weatherbug/ etc.. and the company VPN connection won't work - they expect instant gratification.
When Fred Copyguy calls the Xero/Canon tech because he jammed the double-sided collated stapler function again, his company is paying for either a hefty contract or a site visit. If Fred does this too often, he is dealt with.
When Phil McCracken gets sued for sexual harassment, he makes an appointment to see counsel, and waits while the case is dragged through depositions and hearings.
Unfortunately, when these same nitwits call IT because they installed the latest Free Poker game
Corporate-think needs to perceive the computing infrasructure,including the personnel, as an expensive, specialized tool. If you want me to replace this [machine, router, 1st-level support tech] like a $10 pencil sharpener, then always keep a dozen spares around and ready, or give me an expense account so I can just run down to CompUSA and buy 6 or 8 on any given day. OTOH, if you want me to save that $80,000+ in dusty equipment and redundant training then treat the entire system with the respect and care just like you do the building / campus / Corporate Counsel office.
Plan ahead. Respect the time of your coworkers. When you suddenly come to your sysadmins with set of tasks which "needs to get done today", remember that your sysadmins need to push out other projects to work on your project.
The stereotype of a "Grumpy Sysadmin" probably comes from the fact that one minute we're deeply involved with a technical project performing mental gymnastics and the next minute someone is standing at our desk, demanding attention. Now. It is very difficult to return back to that project or remember where we were.
System Administraton is different then other jobs in the business. We typically deal with a very high level of interruption & multitasking-- and probably more then anyone else in the company. It's not unusual for me to have 12 hour workdays where absolutely NONE of the tasks were on my todo list when I walked in that morning-- a day and a half FULL of interruptions.
"Can of worms? The can is open... the worms are everywhere."
They only give you 15 minutes to implement the design in 30 minutes?
I guess they're looking for over-clocked engineers.
As a professional systems administrator for nearly ten years, I have certainly been in my fair share of crappy IT environments. I think the issues can usually be fixed by adhering to two principles:
1. You get what you pay for
This is a far-reaching statement. The first aspect is salary. Companies (well, universities) are always trying to get by with meager salaries that are NOT competitive at all (let alone poor to non-existent raises, benefits, etc.). In my opinion, it is better to pay one really competitive salary than two or three shitty ones. That one person is going to be so much more valuable than three scrubs; more experience, better attitude, maybe actually be happy with their job and stay for a while. Sure, you can get good people for cheap on occasion, but they are going to be miserable because they know how badly you're screwing them. That demotivates otherwise good employees, leading to decline in work performance as well as leaving for greener pastures.
In a field like systems administration, there is a really big emphasis on personal initiative. You have to proactively go looking for problems before they become problems, come up with bizarre-ass ways to fix things immediately or within the confines of your budget (usually small or zero), man-power, etc. If you're seriously unhappy with your job, it drains your initiative. I have personally experienced this. I want to do a good job, and I take pride in my work, but since I know that I'm being treated like shit (in ways other than pay too), I have a harder time caring as much as I would like to about my work. Thats just the way people operate; if you want the best out of your employees, you have to recognize that.
Stemming from this: you need to fire worthless people. The inability or unwillingness to fire worthless employees is one of the biggest problems for employers that I see. If a sysadmin is always causing more work just by his attitude and ineptitude, then they need to get the boot. If you don't do that, all of his co-workers who aren't fuckups are going to see that you don't care about the quality of their work. Another demotivator.
Also pertaining to this: you are paying these people to administer your computers. NOT to move furniture. NOT to hang pictures on the walls. NOT to do anything with anything that doesn't plug into the wall and beep when it turns on. Its one thing to do a favor for someone, its another to turn into a moving man when you ought to be doing a highly skilled job for your salary.
Aside from salaries, you need to pay for equipment. IT costs money, computers cost money, software costs money. Just because computers are $800 instead of $5000 now doesn't mean that they're free. IT departments need budgets, they need control over those budgets, and they need to be set at reasonable levels. There is a lot of waste here, from sending people to training seminars and paying for support contracts that you don't really need (or use). That isn't what we need. We need money for hardware. If you have to cobble things together, or use a production server to test out things, you're going to run into trouble sooner or later. A lot of the time out-dated, overly heterogenous or inadequate hardware is one of the biggest contributors to an overburdened IT staff. Getting rid of all those 400MHz PCs running Windows ME (when the rest of the place is using XP) is a huge help, more than worth that $800 you need to shell out.
Number two is: Let the experts handle it.
I have worked in a few places where computer decisions were made by someone with no technical knowledge, often based on the latest buzzwords or something someone told them or who knows what. Professors who need 24" LCDs because it will make their computers faster (false), people who think they need a LaserJet 1300 because its a higher number than 1200 (the difference is so minimal as to be a complete waste of time and money). On a larger scale, the complete decision making process of the computer infrastructure may be entirely out of th
There's just no substitute, on both "sides".
In my experiences, users who don't know crap about IT consistently generate the kinds of user problems noted here, and IT people who don't bother to learn anything about the concerns of their users (and who tend to be like Nick Barnes) create the rest of the problems.
It takes time and effort to understand the other guy, and lots of people are unwilling to do it. Senior management has to set the example, which they often don't (though they like to give it lip service).
- Systems/Services will have a criticality assigned to them
- business critical (BC)
- department critical (DC)
- service critical (SC)
- non-critical (NC)
- The level of criticality will determine levels of response time/support expected for that system or service
- (BC) Reporting person is contacted by IT professional within 10-15 minutes with an assesment made to determine the nature of the problem and contact appropriate person(s) including possible management to get IT personnel immediately working on the problem
- (DC) Reporting person is contacted by IT professional within 10-15 minutes with an assesment made to determine the nature of problem and management contacted to determine if action is immediately required (if after normal hours of operation) or if it can wait until normal business hours and worked on by appropriate IT professionals, BC events take precidence
- (SC) Reporting person is contacted within 10-15 minutes (normal hours) or next morning by an IT professional with an assesment made to determine the nature of the problem and the appropriate IT professions start working to fix the problem BC, and DC events take precidence
- Processes are created for tasks
- Process for adding accounts
- Process for installing software
- Process for purchasing equipment
- Process for installing equipment
- Process for moving user desktop equipment
- Process for recovery requests
- Process for foo bar
- Expected levels of uptime are agreeded upon
- Budget requirements are tracked (i.e. tasks themselves are tracked so that time spent installing xyz piece of software on y number of systems can be used to show that X number dollars were needed for that task)
These are just some suggestions. This helps both the IT department as well as the user community because actions are tasked and tracked and accounted for. Budgets are also kept track of so that the money spent can be tracked (like when a Department Head starts yelling that the IT department is costing too much overhead the IT department can show that they spent $500k in time/manpower/infrastructure moving that Department Head's engineers to the shiny new building because he/she wanted the big office on the 4th floor).We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
Here is the problem from my perspective. Lots of IT people have the mindset of 'your work' vs 'their work' because often it's the difference between what they've been hired to do and what a user wants them to do.
They are hired to keep everything up and running, implement new systems and plan ahead. Often because they are competent they also get to do other things like format and excel spreadsheet. Which then turns into "create a summary page, automate the process and draw conclusions". If I'm doing that then what is the point of the sales manager???? Some other examples:
* Training the training officer on how to use word.
* Video editing for the company day.
* Creating power point slides for presentations.
So when someone else is hired to do something but isn't capable of doing that because they aren't computer literate I consider that me taking time out of 'my work' (keeping the backend working smoothly) and helping you with 'your work' (what you a payed to do). Now when the company gets angry at me because the backend stops working because I've been helping everyone else to do the jobs they are paid to do I get grumpy and stop helping people with 'their work' because now the company has told me not to help any more because then bad things happen.
So the timeline is something like this:
1. My Work - New employee.
2. My work + your work - You discovered I was competent. Company agrees.
3. Less of my work and more of your work - You found it was easier for me to solve the problem than figure it out yourself. Company agrees.
4. My work isn't getting done so something minor goes wrong. I'm told to do my job and policies are put in place to make sure it doesn't happen again but I still have to help you when you need it.
5. My work isn't getting done and now I have lots of documentation to fill in as well as helping you. I can know choose two of the following documentation, my work and your work.
5.i. I choose not to do your work. You yell and I get told to do it.
5.ii. I choose not to document. I get yelled at and told that I have to follow policy.
5.iii. I choose not to do my work. The company is happy, your happy BUT
6. Something big fails. The company gets really made I explain why it happened and they tell me to "do my work"
7. You ask me to do something BUT the company has told me that I'm not allowed to without documentation so I tell you that you need documentation for me to help you and you complain.
8. Present.
There is a truism involved in all IT affairs: if you ask someone you'll be told "no".
Try it. Ask through the proper channels if you can have Firefox on your PC at work (for instance). You will be told "no, that would be too much extra work for our technicians; we need to have everything be the same on all the machines." They said this because if they tell you yes this one time, it will "set a precedent" that could cause the whole house of cards to come tumbling down. They install Firefox for you, now they have to take application installation requests from the 15 people you mentioned that to, etc., etc.
Now on the other hand, make friends with your systems administrator and ask for the same thing in a non-official manner. More than likely you will get what you asked for as a personal favor, because in this case it really wasn't much work to do.
This type of thing comes up CONSTANTLY in the IT field. As in about every five minutes. It applies equally well to much larger scale issues as well. Lets say you need some network ports from the central IT division in this one room. Oh well thats going to be $25,000. Or we could use these unused ports in the room next door by routing long (optical cables, no worry about exceeding the length limit) cables around in a crazy fashion, total price $300. This is a violation of the central IT division's terms, but it not only saved that $24,700 it also made the task possible at all -- if left at $25k it would have been a complete failure.
There is a definite need to circumvent the power structure and bend the rules in most corporate environments if you are focused on getting the results you need. Some people would just shrug and say thats the way it goes; other people come up with ways around it to get what they need. The real point is that there are a lot of worthless rules that clog up people's work, and a lot of inflexible bureaucratic people (particularly in the upper echelons of most IT divisions) who you have to bypass to get any work done. The downfall is that if you're bending rules, you may come to one that really shouldn't have been bent for real.
Thanks for the post, it's exactly the kind of thing I was hoping for.
I take your point that IT departments ought to be split between user support and infrastructure support. However, I take exception with the idea that any company with only a couple IT staff is "too small to be of consequence". With the vast majority of companies being too small to be of consequence, doesn't that make them consequential?
What I'm getting at is that an overworked IT staffer in MicroBiz is no more replaceable than one in Megacorp500. If you treat them badly or overload them with work, they will quit (or grin and bear it), and losing 50-100% of your entire IT staff is much worse than losing 5-10% of the staff.
What it requires is some way to minimize the impact of a minimal IT department, I think. Easily-configured networks, plug and play servers, and automatic failure detection and prevention software are all necessary. To some extent these exist, but not to the extent that IT staff can be replaced by them wholesale.
It is usually much easier to debug a problem if you at least have direction in which you can search.
I usually work for smaller shops with a Windows SBS Server and 10-20 Computers.
Users usually feel intimitated if you ask them what they did, before it stopped working. You need to tell them that you're not blaming them in any way, and just want to find out what might have caused the problem, and that nobody will ever hear what they tell you. You need to sound calm and professional when you talk to a customer.
But for me, this usually works.
"Well, i want to a pornographic website, and there was this dialogue i didn't understand"
"I tried to install this wireless network at my home, and.."
Etc. pp. This usually works very well. Never get mad at someone who made a mistake, suppress your emotions, always stay calm, and tell them that you're there to help them (and get 200 bucks per hour).
But most importantly, it is nice to be able to vent to people who have gone through this (and much much worse)
Next week we talk about how we can never take a vacation (and yes, I have accumulated so much leave I am maxed out).
I Am My Own Worst Enemy
A few days ago I received a laptop from the IT department for a business trip the day after. I told them to install some software on it. Net result was that I received a laptop with the software I requested - but without a login, and the software wasn't activated.
If the IT department thinks along with you those things shouldn't happen.
A very big question I would ask in this scenario is this: Who put it off to the last minute, and why? There may be a very good answer to this, but one thing that is generally not understood is that system builds never go smoothly. It is absolutely mandatory that enough lead time be in place that the little problems that will be encountered can be squashed before the deadline.
This entails cooperation on the part of both parties. The user needs to make the request in a timely fashion; the IT guys need to act on it in a timely fashion. The user should perform acceptance testing well before the facility is needed (in this case, a day or two would probably be OK). If something goes wrong in the acceptance testing, then the IT guys need to act on it straight away.
The IT world is frought with problems that refuse to solve under stress. Yes, thinking is a good idea, but it is no substitute for timeliness.
www.wavefront-av.com
how can users work peacefully and effectively with their IT department?
Simple.
STFU.
RTFM.
Dialectician. Archology.