How To Make Your System Admin Go Postal.

So you’re a large company or government organisation with a decently sized IT department. Everything is running smoothly as far as you can tell but there’s something missing. You can’t quite put your finger on it but there’s just no “buzz” or “synergy” or any of those other words you heard other middle managers use at that conference you went to last week. You can’t let this go on too long or something terrible will happen, so what can you do?

FEAR NOT MIDDLE MANAGEMENT CREATURE!! THE REFINED GEEK PERSCRIBES YOU THE 10 FOLLOWING STEPS TO MAKE SURE YOU GET ALL THE SYNERGY YOU NEED!!!!!

1. Have one of your system administrators design or redesign a system. Make sure its business critical.
2. After several long meetings with that administrator get them to start implementing it.
3. Ensure that no documentation is created regarding the design, implementation or required maintenance.
4. Make sure everyone knows about it but not enough to be able to figure it out.
5. Halfway through them implementing it give them another high priority task.
6. Let the system stagnate for about 6 months. This ensures that everyone who was working on will no longer have any idea how it was implemented and if you used a contractor for it they’ve either moved on or been fired (they were useless anyway, right?)
7. Bring up the unfinished project at some meeting and tangle it up with another project that’s less than a month away from its final deadline.
8. Now here comes the great part, find your target and dump the system on them. Make the costs of the project failing so high that they’ll have no choice but to complete it on time or be fired.
9. Additionally get them to redesign the system. This means that you can instantly go back to step 1 and repeat the process on another target should you so wish.
10. Sit back and relax. Your little worker bee is now a couple weeks away from going completely postal on your entire company!

Using this secret technique you to can ensure that none of your projects are delivered on time, your staff overworked and most importantly none of the blame will ever reside with you. Also you will get RIPPED IN 4 WEEKS!!!!#()*$)#*$)(#$*)#$*

END TRANSMISSION…

Reading the passage above you may be lead to believe that I’ve gone completely bonkers after an incident at work. You’d be right to since I’m here at work on Australia Day thinking up a plan of action for something vaguely approaching what I described above. Sure I was probably going to be in here anyway but I was going to get a lot of work done that was really quite interesting and fun. Instead I’m now going to be spending the next 3 weeks unravelling yet another mess of what can only be described as fire-fighter¹ architecture. I’m beginning to question how sane I was taking the extension in the first place.

Sure there are benefits to doing something like this as I’ll be learning a bit of tech that I’ve only dipped my toes into previously. Still when I get given something like that I don’t like having to dive in head first into it without the proper information which is, of course, no where to be found. I’ve never left a workplace without documenting all the inane crap I did to make sure someone else doesn’t end up in this situation. It seems more and more I’m amongst a minority in this case.

I was decidedly more livid about this whole situation yesterday when trying to voice my concerns (and possible solutions) and having them fall on deaf ears. Today however I’ve decided to isolate what I can and can’t do and start hacking away at it. If this bit of work is going to be my downfall I’ll go down swinging, but I would’ve still preferred to have not been put in this situation in the first place.

So ends this little foray into crazy rant world. Hopefully tomorrow I’ll be back to my regularly scheduled blogging and we can all put this behind us.

That or I’ll find those 10 steps above on a management website and I’ll just have to give up on the IT industry completely 😉

¹I use this term to describe something that arose out of an immediate problem. One example I was unfortunately responsible for was copying files from a Unix share to Windows. The program that needed the files couldn’t read the share directly, no matter what we or the vendor tried. So I made a script that copied them from the Unix system to a Windows share. This of course was a band aid solution on a much bigger issue and of course anytime the system broke down they instantly blamed it. I put out the fire with a quick solution, but it became a critical part of the architecture.