Us system administrators are territorial people, especially when it comes to systems that we’ve set up ourselves. In fact I bet you’ve even run into someone who’s the only one who knows something about a certain system or policy, and heaven forbid if you ask them to tell you how it works. I can’t say I’m innocent of this kind of behaviour either as there’s been more than a few times when I’ve built something to what I consider perfection only to have it sullied by others. I like to call this the baby syndrome, as when something is your baby you’ll do everything in your power to make sure no harm comes to it.

Now I’d be lying if I said that this kind of behaviour was detrimental to people like me. Many of the places that I’ve worked in hired me as the other person was leaving, usually leaving a trail of systems that were usually not documented, except for in their head. My first couple months of any of these kinds of jobs is to get the systems to a state where anyone could come in and work on them which I believe is a good exercise when bringing new people in. Not only do they figure out how everything works they also usually break something in the process, and you never know a system well until you break it in some odd way.

However this kind of behaviour is exactly what leads to IT departments spending 90% of their time playing catchup with the routine issues of their environment and 10% trying to innovate. The issue for the system administrator however is justifying their existence to their employer. It’s pretty easy to keep your job when you say “I”m the only one who understands the mission critical business systems” but the more reasonable “As long as they follow my documentation anyone could do it” is likely to make you an easy target when it comes time to cut the fat, as it were. It’s this strange dichotomy of wanting to make everyone’s lives easier and making yourself irreplaceable that causes many IT shops to end up not caring one way or the other. That is, until something like Gershon comes around.

There’s another side to this coin however, and that is no matter how good you document your system there’s guaranteed to be some uncanny situation that works its way out of the woodwork that you could never plan for. If you’re still working with the system its pretty easy to start tracking the problem down, however if you’ve moved on the person in charge of the system you created is up the proverbial without a paddle. I’ve been in this situation a couple times before and it usually ends up with them calling me. Now it’s tempting to be a complete ass to them and tell them where to go, but for someone like me working in a small area like Canberra that’s career suicide, and I’ll usually spend an hour or two working it through with them. I wish I could say the experience was the same for me calling other ex-employees, as the majority are more than happy to give me the metaphorical middle finger.

In other words stop off loading your boring work onto others, you selfish gits 😛

About the Author

David Klemke

David is an avid gamer and technology enthusiast in Australia. He got his first taste for both of those passions when his father, a radio engineer from the University of Melbourne, gave him an old DOS box to play games on.

View All Articles