Slashdot Mirror
Are You Annoying?
cweditor writes "This Computerworld article looks at some habits of people in general and IT pros in particular that can drive co-workers crazy."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
The problem is IT people can interfere with my work, but what I do doesn't affect them. For example, I'm a scientist. I know Linux inside and out and have been using it at home and elsewhere for over ten years. Yet, I don't have root access to my *own* Linux PC at work, which is behind the firewall. So whenever I need something installed, I need to ask IT, wait weeks, explain what's needed ten times to different IT people, and my productivity is hindered. As far as I'm concerned, IT is more or less useless, as I could do their job in addition to mine. And of course they know that -- that's why they don't give root access to us scientists.
This all reminds me of a poll reported on by the Register about how end users don't see themselves as responsible for their own actions when related to IT. Relevent quotes: -One in five people surveyed said they are "too busy to download anti-virus updates". -Depressingly, nine in ten of the workers quizzed believe that have no part to play in preventing the spread of viruses, preferring to leave responsibility to "their IT department, Microsoft or the government". With this kind of attitude, it is no wonder IT workers get sufficiently frustrated so as to be "annoying".
As much as you're going to hate this, most users are not toddlers and don't deserve to be treated like they are. The IT tech wants to know the nature of the problem, ie what steps were taken to cause the problem, but in many cases the user will refuse to give any specific diagnosis that will help aid the program. If we were talking about children, they would have an excuse, but we're talking about adults who are refusing to co-operate because they are frustrated or lazy.
If my steering wheel broke on my car, I would phone up the dealership and say that my car was broken and they need to fix it. If they asked what part of the car was broken, I wouldn't shrug and say only "I can't drive it" and "It was working yesterday". If something more complex broke that I didn't understand I would try to describe the symptoms of the problem, what I was trying to do, how it didn't work, and what steps I could take to reproduce that problem.
Many users call technical support without doing that -- they blame IT support as being the reason their computer is broken and berate them. If they would take into account that the IT tech is trying to learn about the problem in order to fix it and needs to know what exactly doesn't work and how to reproduce it, that would eliminate the confrontation. It's common courtesy, not to imagine more efficient -- but people like you insist the problem is with the person trying to do their job and not the person acting like a child with a temper.
501 Not Implemented
That only works if there really is a problem.
I once dealt with a situation where I had a group of users who would have vague computer problems usually "the network is slow" or some other difficult to verify gripe whenever they weren't in the mood to work.
I got my ass chewed so repeatedly over this crap that I invested a massive amount of time and effort in monitoring these users, and documenting their supposed slow downs, and so when the end of the month rolled around and my monthly asschewing commenced I could produce reams of documentation proving that there were no problems.
Did not make me very popular with about half the building, but I was dead tired of taking the heat for their sloppy work ethic and sheer incompetence.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I used to work with an IT guy that was apparently on the path to BOFH-dom. Whenever people used him as a crutch to get a little work slowdown, he'd actually find a problem. And that problem almost always required them to do extra work...maybe they'd lose that report they've been working on for a week, maybe all their personal configuration would get deleted. Maybe he discovered they weren't doing something frequently enough, such as updating virus definitions or backing up their data.
Sometimes he'd even go to management and have a team-wide policy put in place that required extra work of everyone on that team. While frequently using that person, by name, as an example, he'd give a nice, boring lecture on what that person did or didn't do that caused the problem, and how the problem was bad enough, in that person's own words, to cause a big productivity hit.
One thing I learned is that management loves IT guys that spotlight productivity problems and suggests lots of solutions.
sev
but have you considered the following argument: shut up.
Certainly smarter than me. =P
I kept looking for phantom problems. They were mainly running a big database app, and for a good while, there actually WAS a problem with it. But we added about 10000% more server, and it was all fine.
It was after that, that I started getting reamed. After all, I'd suggested more server and they'd paid for it, so why hadn't the problem gone away?
The original system had run at about 99% cpu util. pretty much all the time, with bottlenecks everywhere, CPU, IO, RAM, everything. The new system generally hovered around 10% with spikes to 60% or 80% running across four processors. I checked IO and it wasn't that, I checked the network (which involved about 4 days crawling through ductwork with a fricking tone wand between my teeth. They had the best networking in the whole building---one jump from the server router to their router, and both routers were new and highly functional.
It was at this point when I realized that I was being consciously fucked. It was priceless to watch their faces as I laid out my info. Since their job was repetitive and the database ran consistently (consistently bad. fucking VB.) I could tell what they were doing by the size and duration of the spikes. I even tested it out, after hours.
It was seriously damning stuff; I could show every time they requested a new page, every time they submitted new data, or ran a query, and that stuff was consistently slow as hell. On the days when they claimed the network was slow the cpu utilization looked like a dead guys ekg. It was pretty obvious to everyone that it could hardly be slow if nothing was going on.
The week after that was probably the worst week they ever had...The average utilization jumped through the roof, hovering around 70% and their boss hadn't worked down there since the new servers had been added, so everything looked blazing fast to her.
I never wanted to be a BOFH, but there are times when I completely understand where they're coming from. Users can really suck.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
That people have a 'tact' filter. Some people filter inbound, some people filter outbound, some people filter both ways (rare), and some people don't filter at all.
Non-IT people tend to filter outbound - they don't say something for fear of offending someone. Not always the case, certainly, but by and large that's my experience.
IT people tend to filter inbound. In the days of yore, it wasn't uncommon to see discussions where "What are you, stupid?" was said, and generally it wasn't taken personally. It was just one of those things that was understood.
These days, there's more of a mix of people fitting the inbound vs. outbound filtering groups, and that leads to problems in business.
This article does a pretty decent job of highlighting one of the things I find to be the most ironic about IT personnel (and I have been one for almost 15 years now) - they tend to get into the business because they don't have to deal with people and don't want to. Yet IT work these days requires more interaction with people, not less.
Take Directory Services technology; according to Burton Group's studies, implementation of directory services technologies is 80% politics and 20% technology. The technology isn't really that difficult, but getting agreement between the various groups who own parts of the data about who owns particular pieces of data requires a fair amount of negotiation and people skills.
Insanity is a gradual process; don't rush it.