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.
... I find it's best to leave a turd on a keyboard. In other words, literally move on it.
I'm trying to cover all my bases
Perfection is unattainable. This is like trying to write some code and anticipate every possible bug before you ship. There will be bugs - accept that there will be a beta phase to your handover.
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
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.
Run, run like the wind, burn every bridge and make it known you will be moving on far away and never communicating with the ex employer again then disappear into the wild not seen or heard from into eternity and you might just avoid being burned at the stake or sent to prison for having a password.
Five years, no site documentation? Bit of a failure right there. Right now the best course would be to stay on for a couple weeks, set up a wiki or anything else to aid taking notes, and work with your replacement to bring it to completeness while he gets up to speed. He can explore and write down, you fill in the details. If you don't have weeks, you give him the wiki but keep access for a while and fill in the details as and when you can. Any question answered that way --and most won't be time-critical-- is a phone call avoided.
That your red Swingline stapler with you. It's yours, you earned it!
On a more serious note, document any kind of common troubles (networking problems, services that need special care, whatever) as they come in. Consolidate that information and provide a nice little package.
This is what I am doing where I work. We have a client on old, legacy software with some really quirky behavior in some circumstances. So I have a document detailing common issues, what the symptoms are, how to troubleshoot, and how to fix. This is THE FIRST document I am handing off to the next guy and will cover 95% of the issues he's going to be dealing with. I don't mind if he calls me for the extra 5% - that's where the dragons are anyway.
Cover the worst case scenario stuff first with the limited time you have left. If that means you don't have time to document the mundane stuff like a normal server configuration, then that's okay. They can piece together the non-critical stuff during normal business hours. They may grumble at you then, but they'll worship you if you can save them during that 2am emergency phone call.
Love sees no species.
Then they won't invite you back
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
The best way to do this is to ensure that your documentation is up to date, provide him with a list of key events in the year. You work at a University so it should include the following -
Tasks carried out at the beginning of the academic year
Tasks carried out at the beginning of the academic year
Significant times of the year e.g. exam times.
You are running a full change control system, ;-) Universities in my experience don't but they should. List every change you make to the systems from now until you hand over.
Don't burn any bridges, expect to be called by your replacement, remember you are not leaving the organisation and the management are within the rights to ask you to help out. Eventually you will realise that you have not had a call for 6 months.
Remember people who post things like "change your name and number" have either never worked in the industry or have just started out. They will not get far with that attitude.
Disclaimer I’ve worked for three universities in the UK, this is based upon experience.
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.
Make sure you answer all support requests via email CCing your new boss (and possibly his) so everyone knows how much time you are spending on the handover. Additionally, it also allows you to track duplicate and repeat questions and to just forward the old email, again including your new boss and possibly his. This is a STRONG encouragement for the new guy to truly take over and your support duties will diminish over time.
"Computer Scientists can count to 1024 on their fingers" (non-mutant, non-mutilatated, human computer scientists)
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
As a good admin, you have documented the server configuration. Especially which services are there, which serivce uses another service etc. In short the architecture of your system existsin a document (or better in a Wiki). there is al ist of all admin-passwords for these services in a separate location (in paper). If you have a wiki, you normally you have a page per machine, containg a service list of it on that page including services which are used by that machine (LDAP for auth). Also you have a separate page for the architecture of all machines.
If you have kept you documentation in a good state, you can just pass that to the next admin. Every open project has a ticket and its progress documented in a ticket system (we use trac so wiki and bugtracker are combined in one tool, but the tool as such is not important, only the function is important). Such projects comprise requests for SSL certificates, request for service deployments, changes etc.
If you do not have such system, then help the next guy to establish one.
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.
Oh I don't know, maybe you should treat the guy that is replacing you, how you would like to be treated by the guy you are replacing.
1. Put a backdoor in all of the servers.
2. Don't tell anyone about it.
3. When you are trying to get another job, show off your backdoors to the interviewers.
4. Demonstrate how you could cripple the servers with a simple keystroke.
5. ???
6. Profit.
You had to have all scripts documented. You had to have all your job documented. You had to start prepare for leave from the first day. If you did then just hand all stuff to replacement and half day speak on what is what and then go to have a drink. If you didn't then you got paid for not doing your job, phone calls should be ok.
Pretty much, no matter what you do, even if you build a wiki, have everything amazingly documented, and are in the top 10% of all shops in terms of best practices, the new person will find reasons to find fault with what you have done. Servers will be rebuilt, upgrades will happen, etc. A year from now, things will either be better off than when you were running them or worse off, but the reality is that re-use just doesn't happen enough in our industry. So if re-use isn't happening, then it's really just up to the quality of the individual.
A days handover for five years worth of running systems seems foolish. If it was me I'd have ideally arranged one to two weeks overlap so the new guy can shadow you and go through a few cycles of standard stuff in progress...
scorched earth is the best policy. It just makes things easier for everyone.
It does seem like you are expecting trouble for some reason. A few things:
1. You've worked in your old job for 5 years - if you haven't convinced your old boss that you are good value it is probably too late to start now.
2. Does it really matter what your old boss thinks of you once you move?
3. You should help your replacement to the limit your new boss will let you (and you should advocate strongly for providing the assistance). The idea of a one day handover after five years under your administration (I'm assuming you are full time) is not reasonable.
I know there is a bit of a culture for inexperienced techs blamestorming when they arrive in a new environment because it is unfamiliar/not setup like their last job. Just accept it is human nature - geeks are the worst because they like to be in control. Help them get the control they are after, and then enjoy the benefit of a productive working relationship with a colleague who will respect your site knowledge and be prepared to help grease the wheels of the machine so you can be more effective in your own job.
You sound like an ass from your statements. A smooth transition will take more than 1 day. Likely several weeks. Dont you have some sort of log book/run book/wiki where you note all the crap you dont want to have to remember?
If I were your boss and you had this attitude you would not have gotten any kind of good reference other than "Yes that person does work here." More likely you would have been fired long ago.
You would not last in any type of real world job.
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.
if so, expect to be helping the new guy for months. One day of training the new guy isn't going to be reality. Did you figure it out in a day? did all your projects take a day?
if you are moving to a different company, expect phone calls, that you can always refuse or ask for a fee..
But ya, if you were not documenting as part of normal practice, document it all now..
---- Booth was a patriot ----
Regardless of documentation, best-practice is to have *considerable* more overlap than one day. At a minimum, a month.
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)
...keep in mind that those you work for would cut you loose without a second though if it were convenient for them do so. You owe them no loyalty whatsoever: that's why it's called a "job", you're only obligated to do what you do as long as you're being paid for it, and that obligation ceases instantly when you're not. (If you think that their perceived obligation to you will last one nanosecond longer, then you are foolish and naive.)
So while you hold the job, you should do the best that you can to document and to explain. Of course, if you're being replaced by an idiot, no amount of documentation and explanation will suffice: stupid people are, well, stupid. But presuming that your replacement has at least minimally acceptable level intelligence, it shouldn't be all that difficult for them to transition into your role.
Despite all of this, however, you WILL be blamed when something goes wrong because that's a natural human tendency: people who do not think through cause-and-effect relationships leap to conclusions, and this particular one is especially tempting. It's really not worth going through the effort to refute it; doubly so if your replacement reinforces the idea. (I'm STILL being blamed for the failure of a subsequent admin to read a very-well documented shell script that was specifically and extensively covered during my last handoff, despite the fact that I handed this person a piece of paper with that script mentioned by name, in bold 18-point type, in the first 3 minutes of our first meeting. *shrug* There's nothing I can do when faced with such an alarmingly low level of comprehension.)
True story: I took over a 10,000 node network for an admin that had just killed himself, leaving no server or network documentation whatsoever. It took time to reflash all of the switches and find tricks to replace passwords on servers and figure out how everything was more or less organized. Leaving a few passwords for the next guy and a rough, top-down analysis of how things interact on paper will work wonders for the next guy. That being said, it's possible (not pleasant) to move forward with no prior knowledge; any explanation you can provide will go a long way. Doubly-so if you put it on paper. You have to realize that gaps will be filled with his way of doing things, not yours. In a few years the network as you knew it could be almost unrecognizable, but it's for the best, and the new guy will have complete control of what's there and how it interacts.
If you're half as beautiful naked, you'd be 4 times as beautiful with twice as many clothes on.
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.
If you haven't clearly documented your role, processes and responsibilities (and keep it up to date) then any perception of laziness will be upon you! Best Practice: you should never be the only resource for uncovering how your job is/was performed. Your management is at fault if you haven't done this, they are rolling the dice on the assumption that you will always be there to answer these questions. If you haven't taken the initiative on your own then you are left with only 2 options: 1) provide support when your replacement needs it, or 2) quit and find another job somewhere else.
I learned the hard way that just asking/telling my boss to change all the passwords was not enough. Type something up and have them sign it that 1. They will change the passwords with x days. 2. They will not question you and accuse you of 'hacking' or entering their systems.
I use to work for a large bedding company ( the big one). When I left I told them again and again to change the passwords after I left. After a year a found out that they were looking for a scape goat as the new people screwed things up. They were libeling me and saying that I was logging into their systems and deleting data. I was upset but there was little that I could do other than to keep telling them that they were idiots and that I told them to change the passwords, which they had not done and that they should bend over further to extract their heads.
This is from a company that I loved and I continued to answer support calls from plant managers for many months after I left. BTW, answering phone calls from a former worker is tricky, and I always reminded them that I didn't work there any longer and to check with xxxx to confirm my answer.
If you've been doing your job properly and documenting everything, you don't need to do anything but hand that documentation - and the passwords - over to your successor, and give him a tour (and map) of the physical environment. If not... except to get phone calls.
http://alternatives.rzero.com/
why locking myself out when just moving groups?
IT's not like you don't work there any more and I would think they would like you to help out with a change over / helping out the your old group with stuff that your new group does and or stuff that both groups need to do together.
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.
You need to have documented as a standard practice during every project. Don't just store it electronically either -- networks and computers fail at inopportune times -- but make sure that enough information stored on paper to figure out what is going on if everything breaks especially domain and local admin passwords for each machine. If the paper contains sensitive info, keep it secured (in a safe that he, you, and a trustworthy third party can get into) but still document it. It is hopeless to try to document all of your work at the end as you will lose a lot of the important details (that one missing simple step that it took you forever to figure out to get the thing working).
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.
I was in a similar situation. You'll never get out of helping out the new guy as long as you're under the same company, but you can make your life easier by throwing everything on an internal wiki. When you get asked a question, it's a lot easier and less annoying to send a link to a wiki article than to have to re-explain it from scratch.
I'm also finding, the longer you're out of the job, the easier you forget things. Document!
Make a new plan, Stan.
You don't need to be coy, Roy,
Just listen to me.
Hop on the bus, Gus.
You don't need to discuss much
Just drop off the key, Lee.
And get yourself free.
(But seriously, anything you would do, should have been done already. Anything you'd document, should be already documented. Any scripts you're stopping or removing, sounds like stuff that shouldn't have been running in the first place.
Any clean-up/CYA you feel you need to do now, just keep in mind for your next job. And don't do those things again! That way you won't feel the need to cover your tracks when you move on.)
I understand the desire to eject and focus on the new work, and certainly that there may have been more than one reason to want to make your move in the first place. I work at a university as well, and understand the challenges and difficulties in moving up inside them.
That said, recognize that if you've done what many sysadmins do and hacked together a bunch of tools to make everything hum without excellent documentation (I certainly have) then you owe your replacement (if not your former bosses) some assistance. You are part of institutional memory and even if you documented your solutions well, you likely didn't document the reasons behind them, or the politics that surrounded them. The new guy/gal will need that context.
Give your one-day hand-over, and in it, set a very clear protocol with boundaries that everyone can agree on (including your new bosses) for providing assistance to the new sysadmin. Make it clear that off-hours is out of bounds, or create a process that avoids you hiking across campus on no notice. Questions will arise over the next several years, though they should taper more or less exponentially. Expect it and be prepared. The value to you of not being a dick about it will be enormous, especially if you plan to stay there for a substantial period of your career (and as a fellow uni employee, why would you not?) will be substantial.
I was once in the opposite position: Having to take over. So maybe this is worth something to you:
Situation: dot-com company, the 3rd party that had been running the servers decided they wanted to do something else and gave us notice within the contracted time frame. So we had about 3 months in total.
What we did was make an agreement about a transition period. For 3 weeks, the two of us who had been selected (from an available pool of Unix admins of ... us 2, so it wasn't much of a selection) to take over went to work at the other company, sitting next to them, watching them, getting everything explained to us, making lots and lots of notes, and gradually taking over with them watching us.
This kind of smooth transition - after the first week we started to do a few simple things, by the end of the second week we were doing most of the day-to-day things, and during the third week we ran a few of the more arcane scenarios (server crash, etc.) still with the old admins watching us - was the best experience in that area that I've had.
This transition period was not at the very end of their contract, so even after we had taken over running things, they were available for questions and in case we ran into problems. Sure, the company was essentially paying them doing nothing for a few weeks, but the risk of not having them available in an emergency was bigger.
Assorted stuff I do sometimes: Lemuria.org
I am making an assumption here, so if it doesn't apply, forgive me. Going forward one thing I would suggest is to shift your mindset more towards engineering, from operations. A lot of places don't draw a fine line - luckily here they do. Operations involves keeping servers humming along happily, their care and feeding. Engineering involves designing, documenting, and determining their configurations, and maintenance that is needed. But the cool thing is, operations guys can benefit from an engineering approach. Before any project gets implemented, you should have a design document - even if its informal. It seems like its a pain in the butt (especially when you find yourself writing a 400 page Detailed Design), but it really helps when A) people complain that they didn't know something was going to be affected by your project - you can point them towards their sign off in the design document, B) people don't know how something works - they can consult the documentation, C) It gives you the opportunity for peer review, avoiding those 1am "Crap, I didn't think of that!" moments, D) it serves as a record for when you inevitably forget something, E) things can keep running if you get hit by a bus tomorrow. This is extremely important in networking too, so it would be a good skill to have. For your current situation, I'd recommend you comb through old emails and write down every single project that they clue you in on. Go through your files too. Then try and document out things that the new admin may have questions about. You're going to miss some things, and don't get upset when he comes calling. You can't blame a lack of documentation on him.
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.
Change all the generic admin passwords before you leave. That way you can't be accused of interfering once you've left, and you're also less likely to be asked to get involved.
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 simply cannot fathom why someone hasn't already posted the instruction manual for what a system admin is supposed to do when he's on his way out the door. I mean, like, this is well-known stuff from the 1990's that everyone in IT is supposed to be familiar with.
I really don't get it. I used to work IT. I am still on good terms with every one of my old employers. Heck, just this morning I spent 10 minutes answering the new IT guys questions about a script I wrote and the reasons for it (this was written 7 years ago!).
Now I am an admin at a school. We don't have a budget for IT, and it gets done mostly by volunteer parents working with me. With one exception, every volunteer that has ever worked IT still comes back regularly to help out, or at least for IT appreciation day (the last day of "no electronics" week, we have a lunch-in for our IT people, followed by a presentation on how kids did for a week without electronics, and a thank-you to our IT people)
I just don't get the animosity...
This is IT. Your replacement will look at your work, declare it was done by someone without knowledge of proper practice, and spend the next stage of their career reinventing the wheel. They will use this opportunity to make it clear to their supervisor and peers that your were incompotent. Why would they ask *you* for assistance?
Easy.. Delete the firmware on the routers so they are bricks once rebooted. Make all passowrds at least 15 to 20 characters long, encrypt everything and hide the passwords.
Disappearing off the face of the planet always works well. Don't worry about them keeping their systems up, I'm sure they'll find some other poor sucker who knows enough about computers to take over. They always do, somehow...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Don't take it personally. At my last job we had a similar policy, though it was somewhat less harsh in execution. The policy was there because of individuals who gave notice and then spent two weeks talking about how crappy the place was and how much better their new job was going to be.
This is why I always leave the company to stop this crap.
That why when they can't or won't read my documentation, I can charge them $!50/hr for after-hours support help. That forces the management to strongly consider whether they really want to bother me over any question or not.
1 hour min per call. My goal **is** to screw them into never bothering me again.
If you stay working for the same client or parent company (or college), then you are screwed.
I was forced to leave NASA work after trading up to a better job. I even switched contracting companies AND client organizations, but the old NASA org was powerful enough to discover where I'd been assigned and got be assigned 20% to their project. In layman terms, I worked for FORD, left to work for Chevy and because both had US-Military contracts, I was forced to work on FORD 20% of my time.
Since it wasn't working out for me, my only option was to completely leave - move 3 states away and switch industries.
I suspect you should do the same.
No matter what you tell the new person you will still be the answer guy for months especially since you are still at the university.
I gave my last employer almost two months notice and a handful of resumes of fully qualified people who were available to start immediately.
The HR idiots didn't get someone hired and able to show up until my last day. I took that day off as my spouse had a bad feeling about me commuting to work that day.
So the new guy got nothing, no logins, no script explanations, no documentation overview, nothing.
I started getting calls at my new employer from "friends" that still worked there asking me to help the new guy before they strung him up in the server room. I helped for a bit then cut them all off. No money no answers.
Accept that people will come to you for help graciously.
It is a small world and probably a bit smaller due to the economy. You are also staying within the same organization.
You never know when someone you worked for in the past will be asked to give an opinion of you.
Due your best to prepare for your departure. Be available after your departure as well.
If people get excessive about asking you questions after you leave, respond slower and slower. They will get the message and they will not be sore about it.
Just do eet quietly.
Life takes interesting turns, but the most interest is when you're off the beaten path.
I went through the same process about 2 years ago---and I recommend leaving as much documentation behind as possible. It's time consuming and can get big, but if you have an indexed document or documents explaining the steps needed to resolve common situations or handle regular tasks, then they'll be able to solve their problems without calling you every time. If they call you and the answer is in the documentation, you can then tell them to RTFM. If vendor documentation is good enough, then you can leave that behind as well for them. Either way, this puts much of the training on them, and not on you, since you only have a single day to explain everything that you've learned over the course of 5 years!
Why, down and not across, of course.
We don't see the world as it is, we see it as we are.
-- Anais Nin
Pray tell... why would you be doing this? Sounds like sabatoge to me.
I am very small, utmostly microscopic.
Miller Time !
Since you are employed by the same people, just a different department, you are obligated to assist when called.
IF you were leaving the company, you would also leave the obligation behind and have voluntary participation on support calls.
Since they still pay you; you are still a "TEAM" member even though now you play on Defense insted of Offense. :)
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.
Scorched earth :)
putting the 'B' in LGBTQ+
Use the Buckets method:
Day 0 : Review the Bucket of information you're handing over like you described. Training/PW Changes/etc
Day 5 : 1/2 HR meeting to review any open questions
Day 10 : 15 Minute meeting to review any open questions
Day 20 : 5 Minute meeting to review any open questions
Time box it , and set the expectation that "Look, I have another job; I can't do both of our jobs... unless it's an emergency (Define emergency as something that will affect the safety of others or impact stock prices), put it on the list and we'll review it at our next transition meeting.
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.
Best way to transfer servers ist to have at least 2 weeks of working together. By this you will manage to transfer about 80-90% of duties. What's left is just specialities and these you can write down while he takes care of server for these 2 weeks.
"Recently, I was given the chance to move from servers to networking .. 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"
You have got to be kidding me, a single `day of training' to bring him up-to-speed on server maintenance, either him or both of you must be in the genius class. From what I've seen, there isn't any practical difference between server admin and networking, as the IT techies are required to fix it, whatever the problem.
AccountKiller
I'm surprised your employer and boss allowed this to happen.
Have you ever gone on vacation for 2 weeks? How did they cope? Just stop everything?
Many large institutions adopt practices to ensure they don't run into bad situations like one person who knows everything in his head and then leaves. Just having a second person trained (often cross over training) along with some notes helps cover the basis. Ideally, one would document everything, but you should be able to assume some knowledge of anyone taking over a sysadmin position, or at least rely on generic information common to all usage guiding them along.
It should be part of your tasks to document the practices you keep, and methods used to keep things going, or update apps and services. If you are not somehow sharing this information and only keeping it to yourself, then you are not doing the job properly. Any job in IT should be done with some bare minimum of docs on how things are set up. Even for your own use in the case someone asks for something you have not had to touch in 2 years.
You are asking a question you should have asked on day 1 of your Admin job. It should carry over to your Network Admin job or your employer will face the same issue there when you leave, which will certainly happen some day, one way or another.
And listen to the lamentations of their women!
Give nothing but the basics to your successor. That way you can charge contracting fees.
When I left my last job, I shredded a book of passwords people might have needed in the future and took a copy of all the Microsoft enterprise and Adobe keys we had.
Fortunately almost every business I have ever worked for went bankrupt shortly after my departure. Is that something I should put on my resume'
and accidentally unplug everything from its wires
Today I left a network manager position that required many other tasks that were well beyond what my scope of work was supposed to be. I think most of it was because they tried to squeeze every ounce of productivity out of me. I want to think that they really appreciated me for what I did for them in the almost 6 years I spent there.
The thing today that reminded me why I was leaving the company was, after all the hugs and goodbyes, was that they were opening up another branch office today. I was tasked to build out the workstation, server, and network for it. Granted I was mostly supervising a bunch of green backs from a company they decided to outsource too (in order to replace me and another 2 guys under myself) tasked to take notes and gather as much info from me as possible before I left. Eh, if you can imagine the weirdness I felt knowing they were attempting to squeeze the life out of me until I finally left...
Granted, the compensation and other things led me to leave, but I always documented everything I did/made/edited/etc. This made it easy to transition to the outsource company. I merely gave them access to my documentation of systems, configs, inventory databases, etc. Basically, gave them the keys to the kingdom, told them to change the lock, and left. ...and now, right now, I feel like I left on a good note while getting ultimate revenge simultaneously. They are in knowingly inferior hands and will suffer for many years to come. If they would have simply just heeded our salary demands, it would have saved them a ton of money and time in the long run. Oh well, because now I can pursue my interests as a systems engineer :)
When I read the line you quoted I thought of notification scripts of disk usage etc and a spaghetti of "backup" scripts to ensure that important data is on a couple of different physical servers at once so that minor problems don't require loading from a real backup. Such things can grow over time and can typically be replaced by a few less simple scripts to make it simpler for somebody else. Then there's completely unimportant stuff (eg. I've got one that downloads a sattelite weather photo and sets that as my desktop). So yes, it it was me then when I go I'll be stopping scripts and removing scripts.
I'm interested as to why you immediately jumped to the conclusion that something nasty is going on and that the above poster is stupid enough to let us know about it. Are you projecting somebody else or yourself onto the submitter?
i usually give 30 days notice
then hire a replacement quickly.
i typically end up doing 1 week of pair-sysadminning and running through all the undocumented processes
on to the next gig..
... what would _you_ like to know?
Or if you are just worried about completely covering your ass ... can't be done. If you've done nothing illegal, move on with a clear conscience. If you have done something illegal, well sooner or later it will catch up with you. In the mean time, move on with a less than clear conscience.
Or is the truth that you've just been tasked with producing a 'Company Sys Admin Turnover Process' ? In which case, ask /. if someone has one they'd be willing to share.
"Consensus" in science is _always_ a political construct.
When I left my last It job where I was overworked and under paid I took all my vacation. Then on the day I was supposed to come back I sent an email to everyone in the company with the subject line "I quit" and a list of all accounts I had access to recommending they change the password right away.
Very quickly... they should have better training, cross-training and communication at the organization.
The strawman "lie" you've fabricated yourself from quotes out of context is amusing but entirely pointless since nobody else is reading this shit and such petty bullying that relies on somebody forgetting what they've said or written isn't going to work even on the weak willed when their previous words are on the page.
Don't you think it's time to stop whining about how you have a right to pick on others but not be mildly criticised yourself? Shouldn't you be apologising to the article submitter and everyone who may have read your words that works with computer networks right about now?