At the time of this story, I worked in IT in an academic environment. It wasn't a very large IT department -- there were only a handful of us.
The job had its fair share of challenges, but the worst was the IT boss, "Ed," whose management and tech skills were both far from satisfactory. Even though it would cause outages, he'd willy-nilly decide to make changes and upgrades during working hours and without warning to us or to the end-users. He was also slow to fix problems and failed to successfully plan long-term initiatives.
[ The tech inferno is not buried deep within the earth -- it's just down the hall. Do the nine circles of IT hell sound familiar? | Follow Off the Record on Twitter for tech's war stories, career takes, and off-the-wall news. ]
Unfortunately, all that users knew was that their technology always had problems, which made us look bad.
One of my coworkers, "Mark," also caused headaches for us. He'd often make secret changes over the weekend and not show up to work on Monday because he'd, well, worked over the weekend.
We'd arrive Monday morning to find one thing or another not working properly. The router would have been reconfigured, DHCP not working for VoIP, DNS only working for some users, and so on. I'd often ask as I walked through the door, "What's broken this week?"
One Monday morning there were DHCP problems, and Mark was out sick. It was obvious that he had once again made some unknown changes over the weekend.
Ed decided to take control of the situation and refused to let any of us touch or fix anything. Shocked, I mentioned what I thought could be the problem, what we could quickly do to find out what was causing the issues, and how we could very probably have a fix made in minutes. Ed again told us in no uncertain terms to not touch anything; Mark would do so remotely.
Since our orders were "don't do anything unless specifically assigned," we stepped back and waited for Mark to make the changes remotely -- and kept waiting. We had to watch the users suffer for two days with no progress of any kind. Any time we'd ask Ed when Mark was going to remotely fix the problem, he'd just brush us off. I don't think he ever contacted Mark, who was on sick leave, so he never checked in.
Mark finally got well, came back on Wednesday, and very soon fixed the problem. The issue had been that the forwarders in the enterprise router were not fully configured for the changes Mark had made to the DHCP ranges. Only some users could get a valid address, and about half of those on the campus were getting 169s. Apparently, Mark did not follow up and actually test the changes before Monday to make sure there weren't any problems.
Ed voiced his approval that everything was once again working properly. But he never, not even once, acknowledged the flaws in what had happened or the headaches it had caused for the users.
Datacom 101 taught that changes should be made invisible to the user. I guess both Ed and Mark skipped that class -- along with basic common sense.
Do you have a tech story about working with less-than-stellar co-workers? Send it to offtherecord@infoworld.com, and if we publish it, you'll receive a $50 American Express gift cheque.
This story, "Common sense wanted in the IT department," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.