Slashdot Mirror


How Do IT Guys Get Respect and Not Become BOFHs?

An anonymous reader writes "I work for a small software company (around 60 people) as the sole IT guy. It's my first time in a position like this and after about 1.5 years I'm starting to get a bit burned out. I try to be friendly, helpful, and responsive and I get no respect whatsoever. Users tend to be flat-out rude when they have a problem, violate our pretty liberal policies constantly, and expect complex projects to be finished immediately upon requesting them. My knee-jerk reaction is to be a bastard, although I've avoided it up to this point. It's getting harder. For those of you who have been doing this a lot longer, how do you get a reasonable level of respect from your users while not being a jerk?"

17 of 902 comments (clear)

  1. Try the slow down method by jackb_guppy · · Score: 5, Interesting

    If they are not nice, delay the response.

    Nice people get fast turn responses.

    Just check with your boss first.

    1. Re:Try the slow down method by teh+moges · · Score: 4, Interesting

      No need to check with the boss, just make sure you prioritize first. Urgent requests get answered first, nice requests second and bastard requests... later. Direct everything through a helpdesk system, so when people are bastards you can inform their bosses that their behavior is making you uncomfortable. At my last job, we had a constant problem of new staff turning up on their first day and their bosses ringing us to say that they need a new user setup straight away. For one-off cases, this wasn't a problem*, but for those that didn't learn, we took a good few days to do it. Paying to have staff sitting there with nothing to do usually teaches them quickly. * we usually left it a day anyway, firstly because some of the aspects of the setup did take time, and secondly, to allow us to stall if they become repeat offenders.

    2. Re:Try the slow down method by Eivind · · Score: 5, Interesting

      Oh, you just need to make it clear to them in a language they understand: Money.

      We've got "rush-jobs", as in "drop whatever you're doing and do this NOW" jobs.

      They are charged triple the normal rate. The intention is loud and clear: If it's not important enough that you're willing to pay triple to have it fixed right-now, then it's not a rush-job.

      Works fine. I seldom get more than 2-3 rush-jobs in any given month.

    3. Re:Try the slow down method by Sobrique · · Score: 3, Interesting

      Make it departmental chargable, make it clear to the user, and ask for a cost code and manager approval. If their boss agrees that it's a rush job, then fair enough. We do this for backup restores on a 'priority service' - it's because our tapes are offsite, and so we have to wait for the daily collection, or pay for a courier.
      It's amazing how many 'this is urgent DO IT NOW' type requests disappear in this situation.

    4. Re:Try the slow down method by stonewallred · · Score: 3, Interesting

      When I ran an HVAC/R company, I did not charge for emergency (after hours) calls, unlike every other company in town did. And my logic was very simple. When I advertise an after hours service and set a price for the service, I am saying I am willing to come (or send a tech) at any time and fix your HVAC/R problem. I never liked working after hours when i worked for other companies, and never knew a tech that liked it either.So with my business, there would be no charge for emergency calls. That way I got to define what was an emergency, not the customer. Probably lost a customer or two over the years, but the customers I gained and kept from this policy more than made up for those losses. Nothing like a customer who you just fixed their equipment at 2AM on a Sunday morning and charged them the same if it had been 9AM on Monday morning. It engendered a lot of customer loyalty and referrals.

    5. Re:Try the slow down method by imneverwrong · · Score: 3, Interesting

      What a god awful method... pay for service to a service person who is already paid to do the job they are asking you to do.

      You have misunderstood the OP, and basic economic theory. Dealing with a rush job is costly to the IT staff, and to the other customers whose jobs are delayed in response. Recovering the full cost of such a job is the only way to not waste resources. Without such cost recovery, people will gladly cause a loss to other internal divisions of $80000 to save their own division $500, and everyone will flag their jobs as "rush".

      He is not advocating getting paid twice for the same job.

  2. Well.. by jessejay356 · · Score: 5, Interesting

    I couldn't do it, I became a programmer and now am one of the annoying people bugging our IT guy.

  3. Re:Move to a different company by Dare+nMc · · Score: 5, Interesting

    worked in my case. IE when I switched companies a year ago, the people who had respect for me before, knew enough about PC's they still got by. Those without respect got to deal with your more typical corporate IT guy (not a total bastard, but at times). The guy who disliked me the most (actually accused me of sabotaging his win 95 box from the network, to our boss, just 18 months ago) publicly wished me back.

  4. Re:Remember... by Opportunist · · Score: 4, Interesting

    That's why I turned to telling the users in advance what's in for them. Often they even get to "vote" if a certain update should be done.

    People want to have the feeling their opinion is valuable. Sure, I eventually get what I want, but they think they've "influenced" my decision when it's actually the other way around. It helps if you tell them what they need to know to make the choice that you already did. They're much more willing to support your choice if they think it was theirs.

    Yes, that's not nice and that's not really user friendly. But it gets the job done and keeps the users happy.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  5. Re:I Set Expectations by Opportunist · · Score: 3, Interesting

    A techie respecting a manager? Respecting someone who thinks a tie is a sign of civilisation, who thinks a blackberry is the pinnacle of technology? Gimme a break. :)

    I've been in both positions. And I slowly get to see just why it was so hard as a "techie" to respect managers, now that I'm turned into one: The mindset and goals are vastly different.

    I don't strive for a perfect solution anymore. A solution that works... no, not even that. I'm looking for a solution that doesn't break the budget, that I can "sell" to my higher ups without having to tear down walls of resistance (yes, that means "Windows good - big successful company behind it that has been in biz for years", "Linux bad - No company behind it, smells like some geek toy project"), that looks like it could get the job done and that can be administered without having to hire additional people.

    Yes, I hate myself too, why're you asking?

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  6. White Board by Ozoner · · Score: 5, Interesting

    Here's what I did in that situation:

    I put up a large white-board, and each time someone requested a job, I wrote it on a strip and put it at the bottom of the list.

    When they complained about the delay, I pointed to the white-board and suggested that they negotiate with those above them for priority.

    It worked well.........

  7. Re:Can't get no respect! by Opportunist · · Score: 4, Interesting

    Could someone drop a few insightful mods on that guy? It's straight to the point.

    You're essentially a repairman. Nobody wants to deal with one until whatever he can fix breaks down. And when it breaks down, people are usually anything but happy about it. Especially in today's offices, they can't do jack without their computers, so they're under heavy pressure when they call you: They can't work!

    So they stand there, getting angrier by the minute because their deadlines aren't going to be pushed back just because that computer doesn't work. They maybe don't even blame it on you. But you're there and they're angry.

    Once the machine works again, you've become obsolete. They don't need you anymore. But they need to catch up because they lost time.

    I admire people who work in helpdesk, and I make sure they feel acknowledged and thanked when they fix a problem for me. I know well that they don't get that a lot, but they'd sure need it to balance out the abuse they have to deal with.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  8. Re:Patience! by SatanicPuppy · · Score: 4, Interesting

    I agree as far as "They treat us like crap when everything is working perfectly." I've been in places where everything worked smoothly, and we were treated like garbage, and I've been in places where nothing worked, and we were treated like kings.

    I don't find that communication helps much, but it may just be my situation. I miss deadlines constantly because I have a job that is (in theory) equal parts deadline-driven code generation, and crisis-driven maintenance and administration. When a crisis pops up, everything gets a little later, and thanks to cutbacks, I'm in charge of way more than 1 person can effectively maintain (5 years ago it was 8 people, now it's me), so there are always fires that need to be put out, and there is very little time for the original code which is technically still part of my job.

    To add insult to injury, about 70% of my work is done remotely, so all the people who work where I happen to have my desk have this mistaken idea that I work for them and that, since they don't have any current problems, I should be working on their code requests.

    I don't know. I'm on the edge of adopting world class BOFHdom in self-defense. Last week I dropped 40 hours (in 2 days) on a site that wasn't even technically mine because their me equivalent was in the hospital in critical condition, and they had had a massive systems crash at the same time.

    The level of sniping and whining and posturing I put up with from the other whiney bitches at my other sites for their ridiculous bullshit problems almost drove me over the edge, despite the worshipful gratitude of the people I was helping.

    --
    ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
  9. Re:Teach them! by scamper_22 · · Score: 3, Interesting

    Make your workload visible!

    I guarantee you, whatever workload you think is causing you to burn out, the software developers are under the same workload.

    1. Get yourself an issue tracking system. Since you're the lone IT guy... you don't need anything complex, but get something... preferably web based.

    2. Make the wait queue public. So people can see how much work you have to do. They also know how long to wait for things.

    3. Let this run for a few weeks, and if you feel you could use a second set of hands, you now have the data to take to your manager. Get a coop student, get another IT person...

    I say this as a software engineer. I now insist on everything being tracked on an issue tracking system. Nothing is worse than random people asking you to do work and no one realizes how much it all adds up to. I don't be an ass about it, but I do insist everything be tracked. If I have to, I submit the issue myself and assign it to myself.

    Do this and people will come to understand.

    Now then... you naturally understand that software engineers are generally reasonably computer savvy people. Nothing would frustrate them more than knowing they *could* fix a problem if only they had the rights or passwords to do so. You are lucky you are in a small company. You can bypass 'official' policies once in a while. If you can't handle the workload, maybe see if there are software developers you trust that can handle certain things. Maybe expose some scripts you run...

  10. Re:Teach them! by JWSmythe · · Score: 5, Interesting

        The last place I was at, I was driven absolutely nuts with incomplete trouble tickets by people who had no clue what they wanted.

        "I want an FTP account for a user in [city]."

        So I'd reply, give me a hint of which server, what username, what password, and why you're requesting this. Each server had dozens of machines.

        I had written up a very clear and concise list of what was expected in a ticket. That was overridden by middle management as unnecessary.

        "Can you search the Apache logs for [customer]?" That would be a customer who had a presence in several cities, and each one had several sites. No hint of what was being searched for, the date(s) to search, what server, what city, or anything more than the customer.

        And my favorite. "We need this project documented. You have 2 weeks.". That's it, no more real explanation. I'd never worked on the project. Had been categorically excluded from the project. Was not allowed to know anything about the project, and suddenly I was to recreate the project (document building each and every custom app from source), which the steps weren't documented and only vague ideas were given about any of it. I asked for information. I begged for information. I was told "This has to be done or the company won't be paid for the project." One week went by and finally information started trickling in. The last day of week 2, I had everything I needed (at like 5pm on Friday). I wrote up a 20 page document, included both sources and compiled versions, with an explanation of how things worked to the best of my understanding. I made ISO images, and put them on an internal server so the requestor could get them either that night, or Monday morning.

        "What were you thinking? Why would you make ISOs. I wanted it exactly as we'd ship to the customer." Ahhh, well beyond spec, but reading minds was part of the job, right? I can read minds, and theirs are drawing a blank most days.

        So I burnt the CD's, printed the document, put it in a FedEx envelope with a bogus shipping label, and put it in the managers chair, like it had just come in. He sat on it for two more weeks before handing it off to someone else in house to "test". A month later, he hadn't finished testing. Another week later I was told "You didn't include instructions on ...." No shit, I didn't know anything about ..... No one told me about ..... You're only coming to me now to tell me ..... exists. Why wasn't I told about this when I started, so I could complete your request. The truth? Because they don't know what they want, what any other middle manager has had someone do, or even what other departments are doing. Countless meetings all day long, and no one has a clue.

        Am I ranting?

    --
    Serious? Seriousness is well above my pay grade.
  11. Wrong company to work for by LostMyBeaver · · Score: 5, Interesting

    I am a software engineer working at a firm that has 50% engineering and 50% sales and administration. We use an outside firm for IT support since :
      1) We can change our own printer toner
      2) If something is broken on our PCs, we either don't trust anyone else to fix it for us or simply need a new PC at which point we reinstall it anyway.
      3) There's no such thing as an IT guy that would even understand where to begin to install and configure our tools (which actually suck since we have to enter in hardware addresses just to get them to start)
      4) We don't use much more than an e-mail server, a file server, and a Cisco. None of which requires a system administrator on site.
      5) Subversion and Wiki servers are run on a separate machine that the developers take control of.

    I would seriously pity any fool that would even consider being the first IT guy to start working at this company if it ever grew large enough that it should need one on site. Being the IT guy at a small engineering firm where the people on site have historically simply fixed their own stuff would be a disaster. I've seen it before as well. You just don't ever want to be that guy. The problem is, most software engineers learned a lot of what they know by grinding through these problems on test networks, home networks, school networks, etc... It is very rare they ever had to do a good job and make something that could stay live 24/7. So they don't know what it takes to make a system stable for 60 users that can be depended on, instead, they know that it's just a line in a script, what's so hard about that.

    If you want a position where a system adminstrator receives more respect, then go to a non-tech company. For example, the happiest system admins I've heard of work at places like paper mills. Remember that you're working at a company where you're more of a convenience than a necessity. If you got hit by a bus, the software engineers would hate doing it, but they'd just start doing the work themselves instead. In a way, at the company you're working at, you're nothing more than a single person that asks the boss for money for new stuff instead of having 40 engineers dropping receipts on his desk. So, in a way, where you are working, you're simply a secretary.

    If you want recognition for your talents, go to a company where instead of being "The guy who could have been a programmer/engineer but wasn't smart enough" and head to a company where you're "The guy who keeps the company running".

  12. Re:Huh? by PitaBred · · Score: 3, Interesting

    Not just that. One of my professors was very well regarded in the algorithms field (can't remember exactly what for) and I remember he asked me to look at his Windows 2000 email machine once. Luckily he did all his important work on Unix, because that Win2K machine was probably the most spy and shitware infested POS I have ever seen. He was wondering why it was going "a little slow". It was at a constant 70%+ CPU usage from the amount of crap running. *shudder*

    Someone who is a very good algorithm developer, or even a very good programmer doesn't necessarily have to have the sense to know how to properly admin and maintain a machine.