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?"
Wiki (Score:5, Informative)
Re:Wiki (Score:5, Funny)
Re:Wiki (Score:5, Funny)
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)
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)
Thankfully, unlike in politics(where we call them "culture" or "institutions" or "traditions") everybody in IT fucking hates legacy systems.
That is how you can tell a good IT person from a great IT person. The one who is truly brilliant will sit down and learn his way around everything, he might hate it but he will learn every last wire or line of code before making any improvements of his own.
The ones who come straight in and want to change how everything works from day one before they fully understand how it all interrelates are going to screw something up sooner or later.
Re: (Score:2)
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)
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)
Re:Wiki (Score:5, Insightful)
Bullshit they don't. You think the CEO gets escorted out by security?
Re: (Score:3)
Depends on if they need help lugging out their big bags of money I guess.
Re: (Score:2, Insightful)
You won't be free from questions since you can 't cover everything in a one day training session. I'd make that two half days with a month or so in between.
Indeed. It is not realistic to expect that you can cover everything in the documentation you are now creating and a single day of training. There's always things you forget. Things you find totally self-evident because you have grown so accustomed to them but that are not for your replacement.
Scheduling another training day somewhere down the line after the replacement has settled in a bit. If you agree to handle any remaining questions at that time there's no reason for the replacement to bother you in the
Re:Wiki (Score:5, Insightful)
The other consideration here in my opinion is that he's not even really "moving on". I've worked in universities, changing departments is certainly changing jobs, but you're not going to get out of being helpful that easily. I spent at least a few hours a weeks helping out other departments, and I wasn't even in the position OP is in of having moved internally. Barring some kind of university politics that make Old Boss and New Boss hate each other, universities tend to be friendly places with lots of resource sharing. All it will take is for the old department head to call down and be like "$newkid is having some issues can you spare Soulskill for an hour or so?" and new boss will not only probably agree, he'll likely be glad to help. Old department head is likely a friend, and at the very least having him owe a favor is worth a few minutes of the new hire's time. Much better to just accept ahead of time that another day, or at least half day, is likely to be needed a couple of weeks in, and plan accordingly.
Re:Wiki (Score:4, Insightful)
Now on the flip side if you are switching employers, I would (and am currently on) a contractual arrangement with "oldjob" while I am working for "newjob". This is actually the second time that I have done this sort of agreement while transitioning between jobs. The contract basically says.
1) My full-time "newjob" is my first priority, so while I might take calls during the day, if they need me to actually _do_ anything that might need to wait until the next day or after hours.
2) Option hours, my "oldjob" pays me option hours, currently I have 10 option hours per week, "oldjob" can choose to exercise them or not, regardless I get paid. As far as flexibility goes, I have to be able to provide them 10 hours a week, although I have no requirements as to when. So I plan on 2 hours a weekday, and if something comes up I can make it up on the weekend. Although I don't _have_ to work 10 hours for them every week, only if they need me.
3) Term, my term is 3 months + 3 month option to renew at the "oldjob" discretion. In my current situation I am about to be renewed for the second 3 months.
4) Notice, when originally setting this up "oldjob" wanted me to give 30 days notice if I was going to move on (or separate from the contract early), but wanted to be able to terminate me at any time. This is the type of slanted language you need to watch for. If they want to terminate at any time then you should get the same rights. We mutually agreed on 14 calendar days.
So bottom line if you are switching employers you should be willing to help out your replacement and prior company, but you are under no obligation to perform any work once you are no longer in their employ. They need to understand this, as do you. But since technically you are still in there employment with a "transfer" I think you should just get used to being a happy helper...
Re:Wiki (Score:4, Informative)
Re: (Score:2)
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)
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)
Re:Wiki (Score:5, Informative)
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)
Sounds great, most managers refuse to allot time for IT to do this. do you give them 4-8 hours a week to get documentation proper?
Re: (Score:2)
Re:Wiki (Score:5, Interesting)
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..
Re: (Score:3)
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, Insightful)
stuff gets missed because we NEVER get administrative time scheduled to do documentation.
/* Note: This is an article to demonstrate in practical terms, how to improve lack of documentation */
The way you "fix" this problem, is to make documentation part of the work. Dont write code, before you have first written the spec for it. Even if it's "inline" documentation, it sure beats zero documentation.
Re:Wiki (Score:5, Informative)
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! [wordpress.com]
Re: (Score:3)
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)
Sounds great, most managers refuse to allot time for IT to do this. do you give them 4-8 hours a week to get documentation proper?
I'm sorry but documentation must always be accounted for when working and planning projects. Much of the documentation should have been drawn up even before the project starts with the rest of it being completed once the project is completed. I have a hard time finding pity for those who build a server and don't document it or add on a service or recurring task through a scheduled script without writing it all out on paper. I have on several occasions had to sort out the resulting mess when moving into a new job. (in fact, I am working through such a situation now).
Any manager who does not allow time for documentation is either incompetent or lacks experience. When I leave a position with a company, I always leave a wealth of documentation behind. Don't forget how much time is saved trying to troubleshoot a problem because you have some documentation available. It sucks being in a position of trying to figure out how something is configured and is supposed to work when it is down and you have people crowding around you waiting for it to be fixed.
To the original poster, the reality is that you failed to properly document the environment. Now you have to suffer by being available to constantly answer questions as your replacement tries to sort out the mess he has inherited from you. The organization suffers because it is exposed to risk as the administrator does't know how everything works and has no resource (documentation) to refer to. Your replacement has to suffer as he tries to sort out what you've left behind. If I left a mess like that behind me, I would be embarrassed and take steps to ensure that it does not happen again. Since you'll still be working there (in a different position) you'll have the pleasure of walking around knowing that your co-workers know what a mess you left behind. If you want a solution, spend a lot of time going through each system and write up detailed documentation and prepare an overview or summary of the entire environment which shows how it all interconnects etc. From now on, take some pride in what you do by doing it properly.
Re: (Score:3)
Re:Wiki (Score:4, Insightful)
I suppose I will just be told that my documentation must be crap. Ok, I'm here to learn, IF you've got relevant long-term experience and aren't just spouting off.
Re: (Score:3)
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
Re: (Score:2)
Re:Wiki (Score:5, Interesting)
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)
"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)
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)
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)
Re:Wiki (Score:4, Insightful)
Yup.
It's amazing how often something comes up and you think "hey, I used to work with a guy who practically wrote the book on that.. and I think he owes me a favor".
At the very minimum, everyone you keep in touch with/on good terms with is someone who might someday let you know about an upcoming job / recommend you to someone else. I'll admit this has only happened to me personally once but several people I've worked with were recommended by other people who knew them from a previous job. In my case I didn't take the job (was happy in my position at the time) but it's still a really awesome feeling for someone to call _you_ asking if you'd be interested in working for them where a huge chunk of more experienced people out there are struggling to even get an interview. Reputation still means something!
Re: (Score:2)
+1 funny if that was actually an Adventure Time reference.
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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)
You are not as important as you think you are. Just leave. They will figure it out. Worked for me.
Re:Just Leave (Score:4, Funny)
Re:Just Leave (Score:4, Funny)
Basically the same as "screw your mortgage and family moron, you are fired".
Re: (Score:2)
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.
Re:Just Leave (Score:5, Funny)
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)
That tactic is too common, and leaves people thinking you're an idiot because they get no chance to find out _why_ you did things certain ways. This role is in the same university: you do _not_ want to leave enemies behind in your old workgroup. Unless some other political issue is driving you out, plan a much longer hand-off period. Unless there's other staff that can fill him in on common practices after beginning, you should schedule time every day, then every week, then occasional emails to touch base. Have lunch with him and a notebook occasionally in the first month. Just be careful not to become a crutch.
The server admins and the networking group should remain on friendly terms: you're going to need favors from each other in the future, and keeping things helpful will help the server team grant those favors gracefully. It'll also let them know that when you say yes, it's as a colleague who wants everything to work, and when you say no, it's not personal.
Re:Just Leave (Score:5, Insightful)
Definitely good advice, there would be so much more unnecessary stress and emotion if this attitude was more widespread.
Re:Just Leave (Score:5, Insightful)
Yep.
If you really are that important, have them contract the work to you.
And to siblings, it's not about saying screw you guys - it's a job, it's not your life, they will dump you the second you are redundant.
Stay in touch with your workmates if you liked them enough, but the second you are off the clock, it's someone elses problem.
Re: (Score:3)
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.
Re: (Score:3)
Also known in the computer industry as the hit by Bus factor. Never let someone leave the office
without having at least one person being able to take over his responsibilities.
Re:Just Leave (Score:5, Insightful)
Re:Just Leave (Score:4, Informative)
I, inadvertently, experienced this "job security" once. It wasn't an experience I want to relive. It's much better to earn job security by being an outstanding contributor rather than by being the keeper of keys.
Already covered at length on Slashdot (Score:3, Informative)
Here [slashdot.org], here [slashdot.org] and here [slashdot.org]. :-)
Have him/her sign off after your training (Score:5, Interesting)
Re:Have him/her sign off after your training (Score:5, Insightful)
Don't know about you, but if I was the new worker and at the end of the day you came to me with a paper for me to sign saying I now know everything my first reaction would be "WTF?" and the second "No way." I have no idea how much you forgot to tell me, even if it says "managing the $foo server" you may have forgotten to tell me about some job or routine or process related to that. In fact, it'd probably be the start of a drama scene with the new boss as I go to him to talk about it.
If you get called, you'll quickly figure out if it's (1) help me do my job, (2) I couldn't be arsed to read the documentation or (3) something genuinely non-obvious. Dismiss (1)s, even if you do remember (2)s point them to the docs instead and answer (3)s. At least so far I'd say 100% of my past employers have asked for a few minutes of my time and 0% have abused the privilege. Just stick to answering how it was but you can't say what direction to take going forwards anymore and it'll be over quickly and friendly.
One Day? (Score:5, Insightful)
That seems like an awfully small window to brain-dump all the info the new guy will need. I think you'll find yourself doing an "oh, yeah, I forgot to tell you about this" thing for awhile. Trying to make the guy look lazy or incompetent for not knowing everything after 1 whole day of info-sharing sounds mean-spirited.
Re: (Score:2)
You should (Score:2, Insightful)
Seriously? (Score:3, Insightful)
You seriously expect he'll be able to take in everything in a single day? Better make sure he records the session, isn't love-sick, in perfect physical and mental health, and not nervous. If those servers are important at all, chances are he's competent (unless there's nepotism, which could be even more dangerous to you).
Wow (Score:4, Insightful)
Wow -- seriously? I'VE been doing IT for FAR longer than 5 years, and the attitude you're displaying right now I'd notice and either not hire you or fire your ass.
I'll be the first to agree if you end up with some incompetent boob, you want that on him and not you ending up doing two jobs, but if you had any maturity or experience, you'd recognize it _might_ take longer than 1 day to do a full knowledge transfer (in fact, if it only takes 1 day, frankly, you shouldn't have had a full time job.. you must have had a lot of downtime to post on Facebook). I'd do my best to document everything in a wiki, show him the ropes his first day, and provide him with my contact information. If a month later he was still bothering me for minutiae, we'd have words -- if three months later he was calling me for an emergency, I'd handle it and then handle him. But 1 day and gone? Either your 'sysadmin' position was 'sit on ass all day' or you need to realign your expectations. What would you want to happen if it was you coming in blind?
Re: (Score:2)
Re: (Score:3)
This guy understood my vague post (which was my fault for making it vague) I have well documented work, ...
The first statement makes me a bit skeptical about the last one. IT people ALWAYS think they are great at sharing knowledge - we aren't.
Expect a lot of calls.
Re: (Score:3)
> I'll be the first to agree if you end up with some incompetent boob,
> you want that on him
Yes folks...you ALWAYS want such boobs on the other guy! :-P
Give them the knowledgebase (Score:2, Informative)
Make sure they know where everything's been documented.
Everything is documented, right?... If not, expect many, many "please help" calls.
perfection is not the key (Score:2)
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.
Leave the keys on the kitchen counter... (Score:5, Insightful)
Let the bank deal with all the trash you left behind and how to clean it up before they try and resell the place.
Oh, you weren't talking about being foreclosure. On second thought, my first thought stands.
Honestly, what's wrong with the new admin coming to you with questions, as long as s/he doesn't abuse the relationship? You'll find that in moving to networking, you're probably going to be doing some work with he new admin anyway, just not directly. Might as well maintain a healthy relationship.
Take the stapler (Score:2)
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)
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'.
Make a support contract (Score:2)
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
Don't be a dick, dick (Score:5, Insightful)
If you've failed to adequately document your role in the time you've been there, you're the one who is lazy and incompetent - it is in your best interests to convince your replacement not to point this out to your old boss, who might point it out to your new boss.
Re:Don't be a dick, dick (Score:5, Interesting)
This, and... if the replacement has a legit problem that will require a significant chunk of your time to help address and correct, make sure you tell him "Look, I'm happy to help, but you gotta get your boss to talk to mine. This is a 10hr/week x 8 week commitment you're asking of me, and there needs to be mgmt support of me spending this much time in this fashion."
This situation happened to me where I was reorg'ed to a new department. I was the last person at the company who had working knowledge of a system which was decommissioned shortly before I was reorg'ed, and then some legal snafu happened and my replacement was faced with the need to dig into offsite backups, pull data out of the archived system, and provide that data to some other team. The guy who took over my other projects was competent, but it still would have taken him months to understand & get everything working again. I was familiar with the system, but I told him that it would still take me a couple weeks to get everything operational and extract the data, and asked him & his manager to talk to my new boss to make sure I was cleared to spend my time doing that much work for them.
This way, I:
1) Was the "nice guy" who helped out a coworker in a bind;
2) Didn't get slagged by my own boss for suddenly wasting a ton of time doing something unrelated to my new role that he hadn't assigned me;
3) Didn't have to spend hours and hours working "free overtime" for the company;
4) Got extra credit on my next review for not being a prima donna who refuses to pitch in when his expertise needed;
I also received (and receive still) occasional calls from the person who inherited my projects when I was reorg'ed. When he has a question, he'll usually call me and say, "Hey, let me buy you a cup of coffee." I get a free cup of coffee, he gets pointed in the right direction, and then we spend 15 minutes chatting about life and work and family.
One Day is Insufficient (Score:5, Insightful)
Get your management to buy into you sharing your time between networking and systems for perhaps two or three weeks (you decide based on volume and complexity of what needs to be handed over) and spend as much time as needed to (a) evaluate the skills of the new 'guy' and (b) get them up to speed on whatever they need to know. If you don't do it in the beginning you'll be doing it for months.
During this 'handover' period, track questions, answers, issues and concerns in one document that you and the new admin review at least once a week (again I don't know the scale of your environment). If any questions come up later and you've documented the entire handover period this way you're covered.
Relax (Score:5, Insightful)
It sounds like you are taking most of the right steps already. Writing up projects, one last round of cleaning. . .
The rest really depends on how big of a job you are handing over. If you were a full time admin, then a single day of training is probably not going to be sufficient. If it was a part time position, then perhaps one day is sufficient. That said, I still wouldn't assume that the new guy is incompetent if he has questions after the first day.
I'd suggest that you tell the guy up front: You are moving to a new job and you won't have a lot of time to answer questions, but you don't want him to feel like you screwed him over. Do your day of training, offer to field emails for a week or two (you'll reply within 24 hours) then schedule an additional session for two weeks later. You should scale this to the size of the job you are handing over: perhaps an hour phone conference for small stuff, up to another day of training if you are handing over a full time position. At that point, he or she can ask any further questions and you can call it quits.
This buys you a bit of goodwill from both the new guy and your old boss. (Going to be wanting a reference from him someday? Show that you care and want things to go well, even after you leave.) Besides, odds are that the new guy is even moderately competent, he won't email you after the 3rd day, and will cancel your 2 week phone call. Plus, if he really is incompetent and starts seriously leaning on your expertise, you should call your old boss and tell him that the new guy has issues - that's probably more valuable than a slip of paper with a (now-known) incompetent's signature.
Best of luck.
Checklist (Score:3)
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
Flash gun (Score:5, Funny)
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.
Every support request/answer in writing / email (Score:2)
It should already be documented. (Score:3)
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)
OK. Lemme try on:
You installed a bunch of open source software all over the place, removing Windows, Unix, and or Novell. (Probably Windows.) Your documentation is, admittedly, less than complete. You, admittedly, have scripts running here and there, which are also likely less than documented. You also are doing a job that should take a month, bringing a new admin up to speed on your (literally) custom built network, in a day.
And your primary concern is (and I quote):
I'm trying to cover all my bases so any excuse my replacement has to call me is seen as nothing but laziness or incompetence.
If I was your boss, I'd fire you and might consider bringing you up on charges of interfering with government property. What, is your name Terry Childers? Probably not. He at least was trying to do a good job. You're just the sort of tool that gives Linux users and computer guys in general a bad name.
The best practice for leaving an IT position? You should start by improving your attitude.
Re: (Score:2)
At which point did the OP mention Linux at all?
Re: (Score:3, Funny)
GP is projecting so hard he should be pointed at a wall in the board room.
Re: (Score:2)
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)
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)
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.
Handover? (Score:2)
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...
One day? X hours over a year is better (Score:4, Insightful)
One day is not realistic. Even if you are super-organized, and actually managed to touch on every single topic in that day, there's no way the new person will understand it all.
It's a slightly different context, but when I turned over a software system, I agreed to this: 40 hours consulting included, anytime over the next year. The first few hours were obviously used immediately. After that, questions came in less-and-less frequently. For me: I knew there was an end. For the people taking over the system: when unexpected issues came up, they knew they could count on help. In fact, they were so restrained about questions that I didn't mind answering a couple of questions after the year was up.
Long story, but I think the same idea would work for you. To keep things clear, write up an agreement and get the right people to sign it. However, as others have pointed out: wanting to be able to prove the other person to be lazy or incompetent is worrisome. You are all on the same team. Check your attitude - it's better to be colleagues than enemies.
Same company? (Score:2)
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..
Standard industrial practices (Score:3)
Indeed I am so pleased to know your valiant endeavours are not within the organisation I am currently engaged with.
Re: (Score:2)
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.
Your concern is admirable, but... (Score:2)
So while you hold the job, you should do the best that you can to do
You are dead to them (Score:2)
You should grow up (Score:5, Insightful)
It's unrealistic to expect everything to just work smoothly under a new person after 5 years working (I presume) mostly by yourself. It's not laziness or incompetence for the FNG to consult the person who architected the system when the documentation inevitably falls short. Grow up, be a professional, and help the new guy out.
Just do your job (Score:2)
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? (Score:2)
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.
Been there...done that (Score:2, Informative)
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
And, what have you been up to? (Score:3)
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.
Re: (Score:3)
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
Too late (Score:3)
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.
Clean House (Score:3)
Similar problem, different circumstances (Score:3)
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.
Re: (Score:2)
... I find it's best to leave a turd on a keyboard. In other words, literally move on it.
It's actually more phun to leave shrimps under the false floor.