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.
You are not as important as you think you are. Just leave. They will figure it out. Worked for me.
Here, here and here. :-)
Be fair of course in how you word it, but nothing speaks better than "I showed the new Admin X,Y,Z and he knows how to do X,Y,Z; here the signature to prove it". I know you are trying to avoid a new Admin coming in and then complaining about how the previous guy didn't know what the hell he was doing. Happens to everyone I'm afraid, but at least have your bases covered for what any replacement needs to know to operate in your permanent absence. It will also discourage the new admin from making any drama scenes with his/her new boss when he/she knows you have something in writing that is suppose to demonstrate/validate his/her new skills in the position. Other than that, don't burn any bridges, try to be helpful to the new Admin, when you have the free time, but don't go out your way and sacrifice your new job to help a struggling admin who might be in over his head due to fluffing up the resume.
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.
change your name and get a new phone number, and let the new guy figure out everything on his own, from reading your properly written documentation. You did write good documentation, right?
You seriously expect he'll be able to take in everything in a single day? Better make sure he records the session, isn't love-sick, in perfect physical and mental health, and not nervous. If those servers are important at all, chances are he's competent (unless there's nepotism, which could be even more dangerous to you).
Wow -- seriously? I'VE been doing IT for FAR longer than 5 years, and the attitude you're displaying right now I'd notice and either not hire you or fire your ass.
I'll be the first to agree if you end up with some incompetent boob, you want that on him and not you ending up doing two jobs, but if you had any maturity or experience, you'd recognize it _might_ take longer than 1 day to do a full knowledge transfer (in fact, if it only takes 1 day, frankly, you shouldn't have had a full time job.. you must have had a lot of downtime to post on Facebook). I'd do my best to document everything in a wiki, show him the ropes his first day, and provide him with my contact information. If a month later he was still bothering me for minutiae, we'd have words -- if three months later he was calling me for an emergency, I'd handle it and then handle him. But 1 day and gone? Either your 'sysadmin' position was 'sit on ass all day' or you need to realign your expectations. What would you want to happen if it was you coming in blind?
Make sure they know where everything's been documented.
Everything is documented, right?... If not, expect many, many "please help" calls.
Let the bank deal with all the trash you left behind and how to clean it up before they try and resell the place.
Oh, you weren't talking about being foreclosure. On second thought, my first thought stands.
Honestly, what's wrong with the new admin coming to you with questions, as long as s/he doesn't abuse the relationship? You'll find that in moving to networking, you're probably going to be doing some work with he new admin anyway, just not directly. Might as well maintain a healthy relationship.
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.
Do you hate the guy? Sure people can be time wasters, but you wouldn't be blowing off a user, but an admin who's hands you might need at some time in the future.
I now find myself typing up all my open-ended projects, removing certain scripts and stopping others.
What's with all the last minute changes? Clearly it's not a 'best practice' to change anything just before you hand it over, as some issues can take days, weeks, or months to become noticed, if they can be traced back you your last minute 'unwarranted' changes, you'll be at the other end of those 'incompetence charges'.
The force that blew the Big Bang continues to accelerate.
Ideally administrators should aim to automate everything with scripts and then document the use of the scripts. That way, if you're hit by a bus the whole system is already in a good shape for others to continue. Personally I think it's part of the administrators responsibility to keep the system in such a good shape. Management should also understand the importance of this and allocate enough time to keep systems in good shape. Doing things like that as an afterthought takes a really long time and makes knowledge transfers really painful.
If your management has allocated only one day for the knowledge transfer, they're taking a huge risk. There's no way you can teach everything about a system in a day. What you can do, is tell your current management realistically about the situation and the risks. After you've gone through the system with the replacement talk to the management about how the knowledge transfer went and make a signed contract about how much support you are willing to give afterwards and how much it will cost them.
With a contract it's up to the management to decide on how much their system is worth to them and you'll get compensation on doing extra work. Who knows, maybe the management will realise that spending a week on the knowledge transfer upfront might be cheaper than paying you afterwards.
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. . .
Put together a very detailed checklist of everything you are going to hand off. Make him own the list and take notes then make him do a review with you and his manager of what he's learned and then have both of them sign off on the training. Be available for quick questions but keep very detailed notes about how much time you are spending during the first couple of weeks. When he calls you should ask what he's done already with the problem to make sure he isn't getting into the default behavior of calling you first. You need to make sure he can be successful (as in the don't burn bridges philosophy) but at the same time is taking ownership of the job.
Good luck,
-c
Wait for the first phone call.
Grab flash gun, keep it hidden.
Disappear behind server rack, muttering "I'm so lucky Health and Safety never came back here...."
Discharge flash gun.
Scream, swear loudly, and wave hand as if burnt.
Wait for "It's OK, we've got this."
Relax.
You should of documented everything as you went along.
Now it bites you in the ass, lucky for your replacement you haven't just been run over / killed some how and they CAN question you.
- http://www.milkme.co.uk
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.
One day is not realistic. Even if you are super-organized, and actually managed to touch on every single topic in that day, there's no way the new person will understand it all.
It's a slightly different context, but when I turned over a software system, I agreed to this: 40 hours consulting included, anytime over the next year. The first few hours were obviously used immediately. After that, questions came in less-and-less frequently. For me: I knew there was an end. For the people taking over the system: when unexpected issues came up, they knew they could count on help. In fact, they were so restrained about questions that I didn't mind answering a couple of questions after the year was up.
Long story, but I think the same idea would work for you. To keep things clear, write up an agreement and get the right people to sign it. However, as others have pointed out: wanting to be able to prove the other person to be lazy or incompetent is worrisome. You are all on the same team. Check your attitude - it's better to be colleagues than enemies.
Enjoy life! This is not a dress rehearsal.
I should recur to standard industrial practices. The rather lovable character known as BOFH compiled a comprehensive canonical volume. A standard opus for all sysadmins. I fancy you will find ample advice on how to behave in the situation whereby handover must be effectuated imminently.
Indeed I am so pleased to know your valiant endeavours are not within the organisation I am currently engaged with.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
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.
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.
removing certain scripts and stopping others.
That leads me to believe you have been abusing your access. There should be no need to stop, let alone remove, scripts any scripts from a production server when turning that server over to a new person. The only two explanations are either you are trying to hamstring him or you are doing something unethical, probably immoral, possibly illegal, and would definitely get you in trouble with your boss.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Unfortunately, you're too late to do this properly. The best practices for leaving an IT position are practices that should have started when you took the position. At a high level, these should have included:
Documenting your setup as you set it up.
Documenting changes as you made them.
Documenting common problems that you run across and how to fix them.
Setting things up in the most common/default way unless you have a real reason for changing them
Avoiding making too many tweaks (unless you have a big support staff, minor performance gains from tweaks aren't worth having a non-standard setup)
If you've done a good job in your job, another decent IT person should be able to pick up your job at any time, without you having time to prepare. Because what if you get sick, or hit by a car, or fired, or whatever? Admittedly, I can't claim that I've always done that good of a job.
Unless you are very sure you will continue to have an amicable relationship, I would suggest some kind of internal code audit in addition to having all passwords changed. My little personal hell went something like this in a small business situation (many years ago) ... I am abruptly terminated due to change in ownership and a brief transition period. 10 days later the main server crashed, and all the kings men could not put it back together again (due to really, really poor choices of who was hired). The company went several months without any of the company data (sales, etc). An insurance claim was filed that claimed I left behind a "bomb" that was mysteriously remotely triggered and physically destroyed hardware on one system, deleting all data irrecoverably, and destroyed all the backups (even though externally stored on removable media). In essence the entire system was inoperable and because it contained custom, in house code, could not be rebuilt. The insurance company took this hooey, paid the claim. Then sued me. Some time shortly after this, they replaced all the systems in the business (this was part of the claim I was sued for), and destroyed the original systems thus removing any evidence that might exonerate me. Clever stuff. It was not difficult to prove my innocence to all this utter nonsense, but it took several years and > $10K to get out from under it. Fun stuff.
I retired 8 months ago. There was no need for me to do much of a handover since there were 5 other people doing the same job as me. We all covered for each other occasionally and theoretically any of us could step into the others shoes at a moments notice.
Other than changing a couple of passwords and the code on the door and surrendering my key cards, my retirement should have consisted of nothing more than some cake, some punch, and me walking out the door.
Since I left, I've been invited to every single office party. I've gone to a few; those people were my close associates for decades.
I have not been to a single party where someone didn't pull me aside and ask me if I remembered an obscure password or the procedures for adding a new disk to an on-location encrypted storage cluster (It was a govt agency and we had the fairly unusual problem of being forced to leave sensitive information on machines where the physical space was on the premises of and accessible to the customer. Relationships with customers were generally adversarial. You get one guess which agency.) or something like that.
I get the feeling the OP will be getting the occasional call two years from now. My advice is to stay on friendly terms and swap favors when you need them. We all do, from time to time.
The last time a went from one system administrator job to another, I proposed a very simple plan...
I told my employer that if they would hire the new sysadm with a month overlap, I would do my best to train him in everything. I would even allow the new admin to call me from time to time over the next few months, if he panicked. I asked my new employee if they we're okay with me answering a few phone calls from time to time, they saw no problem at all in that.
It all played out very well. They hired a new guy with a month of overlap as I proposed, but it didn't take longer than a week or two before he was up to speed. My employer suggested than in return for them to be able to call me in the future, I could take the last time off as paid vacation. Great!
They eventually did call ~6 month later - not because they we're in panic, but they had a difficult problem that needed solving and they thought of me. I talked to my new employer, and we we're able to help them out within a few hours. Everyone was happy! :-)
Moral of the story; don't be a prick. If you treat people nice and give them a fair way out, chances are the won't bother you.