Ask Slashdot: Best Practices For Leaving an IT Admin Position? 290
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?"
Just Leave (Score:3, Insightful)
You are not as important as you think you are. Just leave. They will figure it out. Worked for me.
One Day? (Score:5, Insightful)
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.
You should (Score:2, Insightful)
Seriously? (Score:3, Insightful)
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).
Re:Wiki (Score:2, Insightful)
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.
Indeed. It is not realistic to expect that you can cover everything in the documentation you are now creating and a single day of training. There's always things you forget. Things you find totally self-evident because you have grown so accustomed to them but that are not for your replacement.
Scheduling another training day somewhere down the line after the replacement has settled in a bit. If you agree to handle any remaining questions at that time there's no reason for the replacement to bother you in the mean time, unless it is really urgent.
Wow (Score:4, Insightful)
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?
Leave the keys on the kitchen counter... (Score:5, Insightful)
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.
Re:Just Leave (Score:5, Insightful)
Yep.
If you really are that important, have them contract the work to you.
And to siblings, it's not about saying screw you guys - it's a job, it's not your life, they will dump you the second you are redundant.
Stay in touch with your workmates if you liked them enough, but the second you are off the clock, it's someone elses problem.
Re:Just Leave (Score:5, Insightful)
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.
Re:Just Leave (Score:5, Insightful)
Definitely good advice, there would be so much more unnecessary stress and emotion if this attitude was more widespread.
Don't be a dick, dick (Score:5, Insightful)
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.
One Day is Insufficient (Score:5, Insightful)
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.
Re:Have him/her sign off after your training (Score:5, Insightful)
Don't know about you, but if I was the new worker and at the end of the day you came to me with a paper for me to sign saying I now know everything my first reaction would be "WTF?" and the second "No way." I have no idea how much you forgot to tell me, even if it says "managing the $foo server" you may have forgotten to tell me about some job or routine or process related to that. In fact, it'd probably be the start of a drama scene with the new boss as I go to him to talk about it.
If you get called, you'll quickly figure out if it's (1) help me do my job, (2) I couldn't be arsed to read the documentation or (3) something genuinely non-obvious. Dismiss (1)s, even if you do remember (2)s point them to the docs instead and answer (3)s. At least so far I'd say 100% of my past employers have asked for a few minutes of my time and 0% have abused the privilege. Just stick to answering how it was but you can't say what direction to take going forwards anymore and it'll be over quickly and friendly.
Relax (Score:5, Insightful)
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.
Re:Wiki (Score:5, Insightful)
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).
Lemme try this on (Score:5, Insightful)
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.
Re:Wiki (Score:5, Insightful)
"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.
Re:Wiki (Score:5, Insightful)
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?
Re:Wiki (Score:5, Insightful)
Honestly, why would Anyone work for free?
No idea.. but I've done it and still do from time to time. Someone calls me up with a question that I can answer without a great deal of effort, especially if it's a reasonable question (not documented, ambiguous, etc..), I'll answer it.
Big part of it is everywhere I've worked I've considered most of my co-workers friends and still hang around with several from previous jobs. I see it more as helping a buddy out than providing free labour (and again, a lot of the time we are talking a 10 second question.. usually followed by 5 minutes of enjoyable conversation / catching up). I guess if you are in an uptight all-business environment or didn't really like your previous co-workers I can understand.
One day? X hours over a year is better (Score:4, Insightful)
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.
Re:Wiki (Score:5, Insightful)
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.
Re:Wiki (Score:5, Insightful)
The other consideration here in my opinion is that he's not even really "moving on". I've worked in universities, changing departments is certainly changing jobs, but you're not going to get out of being helpful that easily. I spent at least a few hours a weeks helping out other departments, and I wasn't even in the position OP is in of having moved internally. Barring some kind of university politics that make Old Boss and New Boss hate each other, universities tend to be friendly places with lots of resource sharing. All it will take is for the old department head to call down and be like "$newkid is having some issues can you spare Soulskill for an hour or so?" and new boss will not only probably agree, he'll likely be glad to help. Old department head is likely a friend, and at the very least having him owe a favor is worth a few minutes of the new hire's time. Much better to just accept ahead of time that another day, or at least half day, is likely to be needed a couple of weeks in, and plan accordingly.
You should grow up (Score:5, Insightful)
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.
Re:Wiki (Score:5, Insightful)
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.
Re:Just Leave (Score:5, Insightful)
Re:Wiki (Score:4, Insightful)
Yup, building a network of people is awesome.
Sometimes building relations is more important than money and you get paid in ways that are not immediately obvious.
If only more people worked that way :D
Re:Lemme try this on (Score:2, Insightful)
You might have tried clarifying in your original posting. Notice that this far from the only person responding who thinks you're being an ass. Go back and read what you wrote. And then try to do a better job at getting your point across when you're writing your documentation, because if that's your best, you'll be getting a lot of phone calls.
Re:Wiki (Score:4, Insightful)
I suppose I will just be told that my documentation must be crap. Ok, I'm here to learn, IF you've got relevant long-term experience and aren't just spouting off.
Re:Wiki (Score:3, Insightful)
Re:Wiki (Score:5, Insightful)
Bullshit they don't. You think the CEO gets escorted out by security?
Re:Wiki (Score:4, Insightful)
Now on the flip side if you are switching employers, I would (and am currently on) a contractual arrangement with "oldjob" while I am working for "newjob". This is actually the second time that I have done this sort of agreement while transitioning between jobs. The contract basically says.
1) My full-time "newjob" is my first priority, so while I might take calls during the day, if they need me to actually _do_ anything that might need to wait until the next day or after hours.
2) Option hours, my "oldjob" pays me option hours, currently I have 10 option hours per week, "oldjob" can choose to exercise them or not, regardless I get paid. As far as flexibility goes, I have to be able to provide them 10 hours a week, although I have no requirements as to when. So I plan on 2 hours a weekday, and if something comes up I can make it up on the weekend. Although I don't _have_ to work 10 hours for them every week, only if they need me.
3) Term, my term is 3 months + 3 month option to renew at the "oldjob" discretion. In my current situation I am about to be renewed for the second 3 months.
4) Notice, when originally setting this up "oldjob" wanted me to give 30 days notice if I was going to move on (or separate from the contract early), but wanted to be able to terminate me at any time. This is the type of slanted language you need to watch for. If they want to terminate at any time then you should get the same rights. We mutually agreed on 14 calendar days.
So bottom line if you are switching employers you should be willing to help out your replacement and prior company, but you are under no obligation to perform any work once you are no longer in their employ. They need to understand this, as do you. But since technically you are still in there employment with a "transfer" I think you should just get used to being a happy helper...
Re:Wiki (Score:4, Insightful)
Yup.
It's amazing how often something comes up and you think "hey, I used to work with a guy who practically wrote the book on that.. and I think he owes me a favor".
At the very minimum, everyone you keep in touch with/on good terms with is someone who might someday let you know about an upcoming job / recommend you to someone else. I'll admit this has only happened to me personally once but several people I've worked with were recommended by other people who knew them from a previous job. In my case I didn't take the job (was happy in my position at the time) but it's still a really awesome feeling for someone to call _you_ asking if you'd be interested in working for them where a huge chunk of more experienced people out there are struggling to even get an interview. Reputation still means something!
Re:Wiki (Score:5, Insightful)
stuff gets missed because we NEVER get administrative time scheduled to do documentation.
/* Note: This is an article to demonstrate in practical terms, how to improve lack of documentation */
The way you "fix" this problem, is to make documentation part of the work. Dont write code, before you have first written the spec for it. Even if it's "inline" documentation, it sure beats zero documentation.