Slashdot Mirror
Ask Slashdot: Best Practices For Leaving an IT Admin Position?
An anonymous reader writes "I've been the server admin at a university for the past five years. Recently, I was given the chance to move from servers to networking, and I jumped at it. I now find myself typing up all my open-ended projects, removing certain scripts and stopping others. What would the community recommend as best practices for passing on administration of some servers? I am trying to avoid a phone call that results in me having to remote in, explain something, jog to the other side of campus to access the machine, etc. Essentially, I'm trying to cover all my bases so any excuse my replacement has to call me is seen as nothing but laziness or incompetence. I am required to give him a day of training to show him where everything is on the servers (web and database), and during that day I'm going to have him change all the passwords. But aside from locking myself out and knowing what is where, what else should I be doing?"
Build an internal Wiki. You won't be free from questions since you can 't cover everything in a one day training session. I'd make that two half days with a month or so in between.
Here, here and here. :-)
Make sure they know where everything's been documented.
Everything is documented, right?... If not, expect many, many "please help" calls.
Let me clarify,
The guy coming in has no server experience and I have a rep for just doing other peoples work because it's easier than fighting for it. I don't want to be stuck in the position where i'm doing 2 jobs.
I had no say in his hiring, hes a friend of the boss.
The servers are linux and there is nothing that is not documented, i'm meticulous he does not know how to use vi, doesn't know of nano I have my work cut out here and i'm looking to avoid sitting there 2 months to bring him up to speed.
So in your pessimistic view of how i operate you would of been right however you assumed too much. I don't see where I admitted anything was undocumented do you? Yes, i have open projects, who doesn't? I'm removing them because they are my projects that are unfinished, he might want to go in a different direction. Put your pitchfork away and try to be a little more constructive in your response
I'm going with the Wiki idea,
what i was trying to prevent was a call every 5 minutes and him hitting the staples that was easy button when i'm done doing the work.
I worked at a University, and now I work at a different university...
First of all, you can't cut the person off the minute you walk out the door. The job I left, the I.T. manager was still there after I left, and even though I thought I showed him everything there was, stuff still came up(mostly due to annual license renewals). I took the 30 seconds to jog my memory, then sent him a quick email telling him what to do. I think the last email came a year after I left.
Second, and this is a general rule that all I.T. people should follow, use the generally accepted method for running things. If your flavor of Linux doesn't use apache.conf, then make sure you don't run it that way just because that's what your used to. Should something happen to you, being able to follow online wikis makes it much easier for the next person to not only figure out what you did, but not break more stuff when he/she starts patching things.
Third, in relation to #2, train the new person in whatever custom scripts/tools/etc. you created. Each one of these should be fully documented, both in a wiki and in the code itself. Make sure the new person understands each script/tool before you go.
Finally, IT people at universities know each other. Their reputation preceeds them, and if you prove yourself to be a douche to your previous department, that will hang over your head for the rest of your career.
I, inadvertently, experienced this "job security" once. It wasn't an experience I want to relive. It's much better to earn job security by being an outstanding contributor rather than by being the keeper of keys.
-- no sig today