Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
IT Linux

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Best Practices For Leaving an IT Admin Position?

Comments Filter:
  • Wiki (Score:5, Informative)

    by cyrano.mac ( 916276 ) on Wednesday February 29, 2012 @07:33AM (#39195603)
    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.
    • Re:Wiki (Score:5, Funny)

      by Cryacin ( 657549 ) on Wednesday February 29, 2012 @07:41AM (#39195637)
      Don't forget the "in case of emergency" glass case equipped with a suicide pill.
      • Re:Wiki (Score:5, Funny)

        by laejoh ( 648921 ) on Wednesday February 29, 2012 @07:55AM (#39195719)

        Na, use two letters.

        You know, when they forced Khruschev out, he sat down and wrote two letters to his successor. He said - "When you get yourself into a situation you can't get out of, open the first letter, and you'll be safe. When you get yourself into another situation you can't get out of, open the second letter". Well, soon enough, this guy found himself into a tight place, so he opened the first letter. Which said - "Blame everything on me". So he blames the old man, it worked like a charm. He got himself into a second situation he couldn't get out of, he opened the second letter. It said - "Sit down, and write two letters".

        • Re:Wiki (Score:5, Funny)

          by fuzzyfuzzyfungus ( 1223518 ) on Wednesday February 29, 2012 @09:16AM (#39196241) Journal
          Thankfully, unlike in politics(where we call them "culture" or "institutions" or "traditions") everybody in IT fucking hates legacy systems.

          Do your successor the favor-he-won't-immediately-recognize-as-such by employing a fire-axe to allow him the room to build the systems according to his own vision from day one.

          Sure, the first week or two will be rather stressful; but he'll thank you in the end.
          • Re:Wiki (Score:5, Insightful)

            by Ash Vince ( 602485 ) * on Wednesday February 29, 2012 @09:34AM (#39196357) Journal

            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.

            • It is the only way to avoid punching a hole in something unintentionally...

              Most systems are so interconnected that doing much of anything without an understanding of what it will affect will break things in obscure and hard to detect ways.. until shit lights on fire :p

      • Re:Wiki (Score:5, Interesting)

        by BrokenHalo ( 565198 ) on Wednesday February 29, 2012 @09:19AM (#39196253)
        If you are in a position to leave without being escorted hastily out of the door within a few minutes of handing in your notice, you might consider yourself to be in luck.

        I can understand the rationale behind such a practice in a toxic workplace where such suspicious attitudes are rife, but it doesn't feel good being on the receiving end of it.

        This happened to me once, back in 1990. I thought I was doing the right thing by giving plenty of notice so that a replacement could be found and given an orderly handover, but my desk was immediately cleared by the HR manager, who then personally escorted me out and drove me to my house to pick up the terminals and modem hardware I used to drive the systems outside hours from home. It felt like I was being sacked.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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

      • Re:Wiki (Score:5, Insightful)

        by DrgnDancer ( 137700 ) on Wednesday February 29, 2012 @09:39AM (#39196395) Homepage

        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.

        • Re:Wiki (Score:4, Insightful)

          by Anonymous Coward on Wednesday February 29, 2012 @12:51PM (#39198667)
          I agree with DrgnDancer. Since you are switching positions but not switching employers you will likely be expected to help through the transition period and beyond. So just get used to it and don't be difficult about it. When the new guy has questions answer them as clearly and concisely as possible so as not to warrant a follow up conversation and move on with your day.

          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, Informative)

      by Mysticalfruit ( 533341 ) on Wednesday February 29, 2012 @08:14AM (#39195825) Homepage Journal
      I agree with the wiki idea. You should also diagram your whole environment. Both the physical machines and also the applications and how they fit together. Then, unless you're going to let the guy follow you around for two weeks, you're going to have to provide support.
      • by hardie ( 716254 )

        I like the Wiki idea, but it could be expanded. You can really learn something when you teach it. As you provide bits of support to the new person, make them add the info to the Wiki. Then the question shouldn't come up again.

        I ended up in test engineering at a small manufacturer due to the former person getting seriously ill. When I finally moved back to design, I kept getting calls from the new test engineer and from test operators (who knew which person had the answer). One day I was out. I came back to

    • Re:Wiki (Score:5, Insightful)

      by Richard_at_work ( 517087 ) <richardprice@gm a i l . com> on Wednesday February 29, 2012 @08:23AM (#39195869)

      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).

    • Re:Wiki (Score:5, Informative)

      by K. S. Kyosuke ( 729550 ) on Wednesday February 29, 2012 @08:30AM (#39195915)
      I thought you are supposed to keep documentation of your setup since day 1, in case of a bus error.
      • Re:Wiki (Score:5, Informative)

        by dimeglio ( 456244 ) on Wednesday February 29, 2012 @08:33AM (#39195941)

        Mod this up... As a manager, I would be a total failure if I didn't ensure all systems were adequately documented. Yes, it's probably the most challenging task next to HR.

        • Re:Wiki (Score:5, Insightful)

          by Lumpy ( 12016 ) on Wednesday February 29, 2012 @08:49AM (#39196053) Homepage

          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?

          • Documentation is part of the job. Are you saying that managers do not give you time to do your job?
            • Re:Wiki (Score:5, Interesting)

              by omglolbah ( 731566 ) on Wednesday February 29, 2012 @10:01AM (#39196615)

              Yes. That is what most IT people will say.

              It hurts but that is how it is.

              When I left my previous job I left 12000 lines of badly commented and worse documented code behind.. The code runs the turnstiles and ticketing systems for an exhibition center... The nutters put me in charge of developing it from scratch with a hard deadline of 2 months in addition to an already 100% job...
              Soooo there is virtually no docs on the code... the code is littered with test logic.. There are STILL 4 years later pieces of error code that will print messages to the screen to call me on my cell... a number I still use *shudder*

              Why was it left like that? I begged to go back and fix all the shit for a year after it was put in 'production'.. My boss wouldnt let me. Too expensive to document things. My time was better spent doing other things. I hate that my name is on the system... but that is how it goes.

              Worst detail: The whole mess is not a compiled exe.. it all runs in debug mode from visual studio on a machine in a small cabinet..

              That kind of mess is one of the major reasons to leave a job. It will just end up biting you in the ass if you keep working like that, even if it is not your fault it ends up that way. Get out as soon as possible..

              • Worst detail: The whole mess is not a compiled exe.. it all runs in debug mode from visual studio on a machine in a small cabinet.

                down in the cellar, in the display department, you need to take a torch, the lights are out, so are the stairs. The code is there, in a locked filing cabinet in a disused lavatory behind a door that said "Beware of the tiger".

            • Re:Wiki (Score:5, Informative)

              by nahdude812 ( 88157 ) * on Wednesday February 29, 2012 @10:15AM (#39196753) Homepage

              Documentation is part of the job. Are you saying that managers do not give you time to do your job?

              Lack of documentation is a form of technical debt. Many managers are happy to accept technical debt if it means they can meet customer demands in the short term. I bumped into a good analogy on technical debt a few days back. It's short, and highly recommended. On Technical Debt - Now With Chickens! []

              • by tnk1 ( 899206 )

                Unless it is an actual emergency, the more fools they. Documentation debt accrues interest just like the money kind. It also causes problems with goodwill internally, if other people rely on your docs to do things. I hate developers less for their bugs and more because they don't tell me how to monitor it and operate it. I accept that there are bugs. I don't accept that they won't even tell me how to tell if it is working properly or not.

                Make documentation part of every process, or it will never get do

          • Re:Wiki (Score:5, Insightful)

            by Striikerr ( 798526 ) on Wednesday February 29, 2012 @09:57AM (#39196577)

            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.

          • As an IT worker I have always documented. As a manager, an internal wiki was always set up by me during week one where one did not already exist. As a CTO that is one of the questions I ask of prospective managers. 15% of any project is given to documenting it. I have left positions where I left on the best of terms and gave tem my cell number with instructions to call if there is anything they need to know. Usually I get 1-2 calls just to clear up something that seemed obvious to me but to an outsider
          • Re:Wiki (Score:4, Insightful)

            by timeOday ( 582209 ) on Wednesday February 29, 2012 @10:39AM (#39197031)
            I hate to say this, but my experience with writing documentation has been very unrewarding. Nobody reads it; you still get the same questions. Inevitably it goes out of date. And almost invariably, whoever comes next has their own way of doing things they want to impose anyways. I wonder if it isn't better to just document the high points (high-level structure, where to find stuff).

            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.

          • I've gotten a lot of technical support emails on my job. Since I'm going to respond to their emails anyways, I take the extra 5 minutes to find a good place for it on our wiki, copy the email text, delete the names and do the little extra wiki markup. I mean, my emails are basically a form of documentation and since it takes very little extra time, I get both jobs done at once. Better yet, it means that if someone asks me the same question later, I can just show them the link and don't have to rewrite the e

        • I used to work for an OEM about a decade ago but I still could basically reproduce the manufacturing process thanks to the fact that us in IT had to document and certify every step.
      • Re:Wiki (Score:5, Interesting)

        by Kjella ( 173770 ) on Wednesday February 29, 2012 @08:58AM (#39196117) Homepage

        You're supposed to, but if nobody asks for it then it likely doesn't happen since lack of work documentation would be somewhere around #43542 on my list of worries should I end up in a traffic accident. And if your manager is ridden hard to always do new system and new projects, well he too might let it slip until the shit hits the fan. It's the same way documentation and testing have a mysterious way of disappearing from development plans. Sometimes it seems companies are happy to find a scapegoat, but do nothing about the system that leads to it being that way.

    • Re:Wiki (Score:5, Insightful)

      by Lumpy ( 12016 ) on Wednesday February 29, 2012 @08:47AM (#39196045) Homepage

      "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)

        by Anrego ( 830717 ) * on Wednesday February 29, 2012 @09:15AM (#39196235)

        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.

        • Re:Wiki (Score:4, Insightful)

          by omglolbah ( 731566 ) on Wednesday February 29, 2012 @10:04AM (#39196647)

          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: (Score:3, Insightful)

            I agree completely. I can't tell you how well little favors have helped me rub elbows with important people that remember me later on.
            • Re:Wiki (Score:4, Insightful)

              by Anonymous Coward on Wednesday February 29, 2012 @12:55PM (#39198735)


              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!

      • by karnal ( 22275 )

        +1 funny if that was actually an Adventure Time reference.

    • When I left my last job as the sole network/server/helpdesk guy, my old boss asked me to come in 5 evenings over the course of 6 weeks to train the new guy. The first two or three times were within a week to give him the overview and the rest were later on when he ran into things he wasn't experienced with. I still get a quick email every few weeks with a question about something or other. Of couse, I made sure I got paid for every minute I was training the new guy.

    • 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.

      To be honest, you should have done this 5 years ago. Everything should be documented at the time you build it, so if you leave / die someone can pick up supporting what you put in place. I know many people might come back saying this is a waste of time, but it is the only way to be sure that everything that needs to be gets documented. Trying to figure out what bits of the last 5 years need documenting now is a nightmare and you are guaranteed to miss stuff. Doing 5 years of systadmin stuff with no document

    • Yes, a wiki are great, but in this case it needs to contain useful information. The wiki forces you to organize what you know about the network and how everything is related, but it's a lot of work and it takes time and effort to do it properly. The bigger and/or more complicated the network in question, the longer it will take to complete an adequate set of documents.

      Documentation is not something you start on a day or a week before you leave: it's something that should be created as soon as possible an

  • Just Leave (Score:3, Insightful)

    by Anonymous Coward on Wednesday February 29, 2012 @07:37AM (#39195613)

    You are not as important as you think you are. Just leave. They will figure it out. Worked for me.

    • by Cryacin ( 657549 ) on Wednesday February 29, 2012 @07:39AM (#39195619)
      Ah, the old "Screw you morons, I quit" tactic.
      • by Anonymous Coward on Wednesday February 29, 2012 @07:49AM (#39195669)

        Basically the same as "screw your mortgage and family moron, you are fired".

        • Yes, but not every employer will do that, and (in my experience) most will only do that if you give them a good reason, or they have no viable alternative.

          • by Lumpy ( 12016 ) on Wednesday February 29, 2012 @08:51AM (#39196077) Homepage

            I'm sorry dave, but the CEO really wants another Yacht and we cant afford to keep you. Yes we know that you do 12 jobs and are critical to our operation, but we are going to hire some kid right out of college for $28,900 and save a shitload of money and abuse the snot nosed brat by making him work 120 hours a week with only 40 hours of pay. You are just too old for us to screw like that anymore.

      • Re:Just Leave (Score:5, Insightful)

        by Antique Geekmeister ( 740220 ) on Wednesday February 29, 2012 @07:58AM (#39195735)

        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)

          by curious.corn ( 167387 ) on Wednesday February 29, 2012 @08:06AM (#39195765)
          Hats off. These days it's rather difficult to find reasonable, competent and professional people in the field; therefore I won't pass this occasion for a well deserved praise.
          Definitely good advice, there would be so much more unnecessary stress and emotion if this attitude was more widespread.
    • Re:Just Leave (Score:5, Insightful)

      by Splab ( 574204 ) on Wednesday February 29, 2012 @07:52AM (#39195701)


      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.

      • yes, but prior to being off the clock, you can work to make it easier on them, once you are off the clock. Not everyone will dump you when you are redundant, especially if they make a point of keeping backups in positions, as another user mentioned. Even in the places where you are still too redundant, many employers will try to reshuffle you to other positions you can fill. Not all employers are cold, heartless bastards.

  • by Anonymous Coward on Wednesday February 29, 2012 @07:39AM (#39195615)

    Here [], here [] and here []. :-)

  • by KnightMB ( 823876 ) on Wednesday February 29, 2012 @07:40AM (#39195621)
    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.
    • by Kjella ( 173770 ) on Wednesday February 29, 2012 @08:13AM (#39195809) Homepage

      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.

  • One Day? (Score:5, Insightful)

    by Anonymous Coward on Wednesday February 29, 2012 @07:41AM (#39195633)

    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.

    • I was thinking the same thing. Way to be a good co-worker! You are giving a new person a whole day to learn what you worked on for 5 years? How very kind of you. I can only hope the person you are taking over for (or working with) shows you the same courtesy.
  • You should (Score:2, Insightful)

    by skovnymfe ( 1671822 )
    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?
  • Seriously? (Score:3, Insightful)

    by Anonymous Coward on Wednesday February 29, 2012 @07:41AM (#39195643)

    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 (Score:4, Insightful)

    by Anonymous Coward on Wednesday February 29, 2012 @07:46AM (#39195659)

    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?

    • You really need to work on your reading comprehension, buddy. The submitter said what he was already planning to do, but also said he wants to do more. It's not like he isn't open to the possibility of more hands-on training days, or whatever else it takes for a smooth handoff.
    • > I'll be the first to agree if you end up with some incompetent boob,
      > you want that on him

      Yes ALWAYS want such boobs on the other guy! :-P

  • by Anonymous Coward

    Make sure they know where everything's been documented.

    Everything is documented, right?... If not, expect many, many "please help" calls.

  • 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.

  • by IANAAC ( 692242 ) on Wednesday February 29, 2012 @07:49AM (#39195677)
    and don't look back.

    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.

  • 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 fi

  • Last minute changes? (Score:5, Interesting)

    by rednip ( 186217 ) on Wednesday February 29, 2012 @07:55AM (#39195723) Journal

    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'.

  • 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 k

  • by jholyhead ( 2505574 ) on Wednesday February 29, 2012 @08:06AM (#39195769)
    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.
  • by sociocapitalist ( 2471722 ) on Wednesday February 29, 2012 @08:08AM (#39195785)

    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.

  • Relax (Score:5, Insightful)

    by coldfarnorth ( 799174 ) on Wednesday February 29, 2012 @08:18AM (#39195849)

    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.

  • by porsche911 ( 64841 ) on Wednesday February 29, 2012 @08:23AM (#39195871)

    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,

  • Flash gun (Score:5, Funny)

    by 6Yankee ( 597075 ) on Wednesday February 29, 2012 @08:23AM (#39195873)

    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."

  • 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.
  • 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.

  • Lemme try this on (Score:5, Insightful)

    by Stargoat ( 658863 ) * <> on Wednesday February 29, 2012 @08:44AM (#39196021) Journal

    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.

    • by ledow ( 319597 )

      At which point did the OP mention Linux at all?

      • Re: (Score:3, Funny)

        by Anonymous Coward

        GP is projecting so hard he should be pointed at a wall in the board room.

        • by Kjella ( 173770 )

          GP is projecting so hard he should be pointed at a wall in the board room.

          LOL wish I had mod points, made me chuckle.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Let me clarify,
      The guy coming in has no server experience and I have a rep for just doing other peoples work because it's easier than fighting for it. I don't want to be stuck in the position where i'm doing 2 jobs.
      I had no say in his hiring, hes a friend of the boss.
      The servers are linux and there is nothing that is not documented, i'm meticulous he does not know how to use vi, doesn't know of nano I have my work cut out here and i'm looking to avoid sitting there 2 months to bring him up to speed.

      So in y

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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.

  • by pev ( 2186 )

    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...

  • by bradley13 ( 1118935 ) on Wednesday February 29, 2012 @09:18AM (#39196249) Homepage

    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.

  • 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..

  • by SpaghettiPattern ( 609814 ) on Wednesday February 29, 2012 @09:42AM (#39196429)
    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.
    • And I was surprised to notice that nobody had referred OP to alt.syadmin.recovery, which makes abundantly clear what the only real way to stop being a sysadmin is.

  • ...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 do
  • 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 prio
  • You should grow up (Score:5, Insightful)

    by dirtyhippie ( 259852 ) on Wednesday February 29, 2012 @09:49AM (#39196497) Homepage

    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'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.

  • 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.

  • by Anonymous Coward

    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

  • by DaveV1.0 ( 203135 ) on Wednesday February 29, 2012 @10:31AM (#39196917) Journal

    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.

    • by mcmonkey ( 96054 )

      I surprised more folks haven't picked on that aspect of the OP.

      The quick work-around you didn't document because it was meant to be a short-term fix, but you never resolved that issue so short-term turned in to SOP, yes, document that bit for your successor.

      But scripts you feel you need to stop or remove? Sounds like you'll get away with whatever you were up to this time. Stop looking back and concern yourself with your new position. Take this as a lesson learned. Work in a manner such that you could le

  • by nine-times ( 778537 ) <> on Wednesday February 29, 2012 @11:19AM (#39197541) Homepage

    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.

  • by LordThyGod ( 1465887 ) on Wednesday February 29, 2012 @11:32AM (#39197685)
    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.
  • by BenEnglishAtHome ( 449670 ) on Wednesday February 29, 2012 @02:36PM (#39200187)

    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.

Experience varies directly with equipment ruined.