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?"
That seems like an awfully small window to brain-dump all the info the new guy will need. I think you'll find yourself doing an "oh, yeah, I forgot to tell you about this" thing for awhile. Trying to make the guy look lazy or incompetent for not knowing everything after 1 whole day of info-sharing sounds mean-spirited.
That tactic is too common, and leaves people thinking you're an idiot because they get no chance to find out _why_ you did things certain ways. This role is in the same university: you do _not_ want to leave enemies behind in your old workgroup. Unless some other political issue is driving you out, plan a much longer hand-off period. Unless there's other staff that can fill him in on common practices after beginning, you should schedule time every day, then every week, then occasional emails to touch base. Have lunch with him and a notebook occasionally in the first month. Just be careful not to become a crutch.
The server admins and the networking group should remain on friendly terms: you're going to need favors from each other in the future, and keeping things helpful will help the server team grant those favors gracefully. It'll also let them know that when you say yes, it's as a colleague who wants everything to work, and when you say no, it's not personal.
If the guy who replaces you needs a hand, give him a god damned hand!
If you've failed to adequately document your role in the time you've been there, you're the one who is lazy and incompetent - it is in your best interests to convince your replacement not to point this out to your old boss, who might point it out to your new boss.
Get your management to buy into you sharing your time between networking and systems for perhaps two or three weeks (you decide based on volume and complexity of what needs to be handed over) and spend as much time as needed to (a) evaluate the skills of the new 'guy' and (b) get them up to speed on whatever they need to know. If you don't do it in the beginning you'll be doing it for months.
During this 'handover' period, track questions, answers, issues and concerns in one document that you and the new admin review at least once a week (again I don't know the scale of your environment). If any questions come up later and you've documented the entire handover period this way you're covered.
blindly antisocialist = antisocial
It sounds like you are taking most of the right steps already. Writing up projects, one last round of cleaning. . .
The rest really depends on how big of a job you are handing over. If you were a full time admin, then a single day of training is probably not going to be sufficient. If it was a part time position, then perhaps one day is sufficient. That said, I still wouldn't assume that the new guy is incompetent if he has questions after the first day.
I'd suggest that you tell the guy up front: You are moving to a new job and you won't have a lot of time to answer questions, but you don't want him to feel like you screwed him over. Do your day of training, offer to field emails for a week or two (you'll reply within 24 hours) then schedule an additional session for two weeks later. You should scale this to the size of the job you are handing over: perhaps an hour phone conference for small stuff, up to another day of training if you are handing over a full time position. At that point, he or she can ask any further questions and you can call it quits.
This buys you a bit of goodwill from both the new guy and your old boss. (Going to be wanting a reference from him someday? Show that you care and want things to go well, even after you leave.) Besides, odds are that the new guy is even moderately competent, he won't email you after the 3rd day, and will cancel your 2 week phone call. Plus, if he really is incompetent and starts seriously leaning on your expertise, you should call your old boss and tell him that the new guy has issues - that's probably more valuable than a slip of paper with a (now-known) incompetent's signature.
Best of luck.
Lets start refering to The War Against Terror by it's initials. . .
I agree with this, but in reality the time when you are leaving is not the time to be setting that up, it should have been set up on the very first day the person started - lets face it, you are *never* going to be able to document everything now, its a hopeless task. If you manage to touch on everything, then you will miss the little foibles that even you have forgotten (until the next time you have to touch that function yourself).
OK. Lemme try on:
You installed a bunch of open source software all over the place, removing Windows, Unix, and or Novell. (Probably Windows.) Your documentation is, admittedly, less than complete. You, admittedly, have scripts running here and there, which are also likely less than documented. You also are doing a job that should take a month, bringing a new admin up to speed on your (literally) custom built network, in a day.
And your primary concern is (and I quote):
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.
If I was your boss, I'd fire you and might consider bringing you up on charges of interfering with government property. What, is your name Terry Childers? Probably not. He at least was trying to do a good job. You're just the sort of tool that gives Linux users and computer guys in general a bad name.
The best practice for leaving an IT position? You should start by improving your attitude.
Hoist Number One and Number Six.
"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."
Great idea, but I charge $90.00 an hour with a 1 hour minimum for EVERY call I get after my last day. Honestly, why would Anyone work for free?
This tactic stopped the calls, today I do this on my exit interview. I charge a per hour rate unless the company is willing to give me continued free stuff if they expect free stuff. For example I told Comcast that I'll answer question on the phone for free if they continue my free Ultimate cable TV with all pay channels and top tier internet. Otherwise I charge per phone call and per hour.
Most of my calls were answered with, "did you look in the lumpy operations manual I left on my desk the last day I was there? as the answers you need are in there. and Manager X has all the passwords. I cant give you any passwords over the phone."
I left a good detailed file, but some people are too lazy to read a document or ask the proper person for the login information. It's another reason why I charge. I get to tax laziness and stupidity.
Do not look at laser with remaining good eye.
Sounds great, most managers refuse to allot time for IT to do this. do you give them 4-8 hours a week to get documentation proper?
Do not look at laser with remaining good eye.
Thankfully, unlike in politics(where we call them "culture" or "institutions" or "traditions") everybody in IT fucking hates legacy systems.
That is how you can tell a good IT person from a great IT person. The one who is truly brilliant will sit down and learn his way around everything, he might hate it but he will learn every last wire or line of code before making any improvements of his own.
The ones who come straight in and want to change how everything works from day one before they fully understand how it all interrelates are going to screw something up sooner or later.
I dont read
It's unrealistic to expect everything to just work smoothly under a new person after 5 years working (I presume) mostly by yourself. It's not laziness or incompetence for the FNG to consult the person who architected the system when the documentation inevitably falls short. Grow up, be a professional, and help the new guy out.
Sounds great, most managers refuse to allot time for IT to do this. do you give them 4-8 hours a week to get documentation proper?
I'm sorry but documentation must always be accounted for when working and planning projects. Much of the documentation should have been drawn up even before the project starts with the rest of it being completed once the project is completed. I have a hard time finding pity for those who build a server and don't document it or add on a service or recurring task through a scheduled script without writing it all out on paper. I have on several occasions had to sort out the resulting mess when moving into a new job. (in fact, I am working through such a situation now).
Any manager who does not allow time for documentation is either incompetent or lacks experience. When I leave a position with a company, I always leave a wealth of documentation behind. Don't forget how much time is saved trying to troubleshoot a problem because you have some documentation available. It sucks being in a position of trying to figure out how something is configured and is supposed to work when it is down and you have people crowding around you waiting for it to be fixed.
To the original poster, the reality is that you failed to properly document the environment. Now you have to suffer by being available to constantly answer questions as your replacement tries to sort out the mess he has inherited from you. The organization suffers because it is exposed to risk as the administrator does't know how everything works and has no resource (documentation) to refer to. Your replacement has to suffer as he tries to sort out what you've left behind. If I left a mess like that behind me, I would be embarrassed and take steps to ensure that it does not happen again. Since you'll still be working there (in a different position) you'll have the pleasure of walking around knowing that your co-workers know what a mess you left behind. If you want a solution, spend a lot of time going through each system and write up detailed documentation and prepare an overview or summary of the entire environment which shows how it all interconnects etc. From now on, take some pride in what you do by doing it properly.
If you're not replaceable then you're not promotable. I *want* people to be able to do what I do so that I have the option of doing something else.
Those are my principles, and if you don't like them... well, I have others.
Groucho Marx