Ask Slashdot: IT Staff Handovers -- How To Take Over From an Outgoing Sys Admin? 195
Solar1ze writes "I've just started a role in an IT services firm. I'm required to take over from an incumbent who has been in the position for three years. What are some of the best practices for knowledge transfer you have used when you've taken over from another IT staff member? How do you digest the thousands of hosts, networks and associated software systems in a week, especially when some documentation exists, but much of it is still in the mind of the former worker?"
There is only one way... (Score:2, Funny)
Hope to Christ he took good notes.
Re:There is only one way... (Score:5, Insightful)
Hope he is leaving on a good note, and not holding grudges.
Then systematically go through each machine for which he has a password and have him record these in some secure password vault application of your choice. And also any root passwords he has. Passwords to routers, print-servers, off site corporate backups, corporate accounts (supplier's web sites etc), certificates owned, domain names, email accounts, etc. (You'd be surprised how many small to mid sized businesses wake up two years hence to find their website unreachable because the renewal went to some gone-guy's inbox and/or bounced).
Go over the system layout (map of the network, interconnects, lans, NAS's, servers, etc), and for EACH NODE, ask if anything has been changed since it was created. If you ask if the document is up to date, he'll just say "pretty much" but if you go over it one router at a time, he will remember things that don't appear in the notes for one reason or another.
But mostly pray he's leaving happy, and not pissed.
Re:There is only one way... (Score:5, Insightful)
If he is leaving happy, get his contact info and ask if you can check in with him in the future if you have more questions.
Most of the issues I've run into over the years did not center around HOW something was done but WHY that particular design was chosen. Usually there's one or two weird items at every site that the rest of the system has be designed to accommodate.
Re:There is only one way... (Score:4, Insightful)
Re: (Score:3)
You might get a couple of freebies with his contact info but I suspect it'd be better policy for an installation this size to set up a paid arrangement with the outgoing sysadmin. I'm not in IT so I don't know what precedents there are around this, but relying on him to reply for free just seems against human nature.
This is great advice. A two-week after-hours contract with the admin for after he leaves is a great investment.
Re:There is only one way... (Score:4, Interesting)
Hopefully, they are leaving as an advancement not out of recourse. As someone in the incumbent situation right now with evenly mixed feelings, a small olive branch saying "we know we will be at a disadvantage without you and would like to buy 8-24 hours of your time when you have it available over the next 6 months, keep it anyway if we don't," would go an awful long way to helping me answer a phone call or any other question that isn't oh yea the password is 'RumSkittles3242#$@%_god'. That said, without that, if anyone besides my supervisor calls when (not if) the project they are working on fails, I'm going to say "HAHA, told you so!" and hang up.
Re: There is only one way... (Score:2, Insightful)
While I take pride in my work, all my efforts have to be compensated. I am just like any other business.
Re: (Score:3)
There IS only ONE WAY
FOIA Request to the NSA.
Re: (Score:3)
Then you good sir: are an asshole.
As a poorly paid IT admin that manages thousands of devices across every province in Canada, I'm happy to answer questions about anything I've worked on YEARS later.
I agree... to a point. If its more than a quick 10-15 minute call they can expect to be billed for my time. Well, that is unless I was terminated, then the consulting clock starts ticking the minute the phone rings.
There is a fine line between an ongoing piece-meal brain dump, and raping you by asking you to come in for an hour or more to consult. Dont want to pay me for my time? Figure it out for yourself. *shrug*
I've been in both situations... happily answered the phone several times a day several times
Re: (Score:2)
When the time rolled around to do the recurring programming tweak/task/report, they asked him to come in and he did... FOR FREE! *SMH*
Oh, and to make matters worse, I believe the task was part of a billable event to a customer. They made money coming and going off of him.
Re: (Score:2)
Sorry indeed, some people are so into computers and tech they don't realize that they're being abused by their employer as a result. It's something I've had to learn to deal with too, I get asked to do minor stuff in hats other than the code realm because I know them and they're on my resume, but if its something major like come be our DBA til we hire a new one, that requires a pay raise or a bonus (I try to be easy to work with).
Also, I'm happy answering questions, like where is this located, where does t
Re: (Score:2)
As a poorly paid IT admin that manages thousands of devices across every province in Canada
purhaps your willingness to do so is causation for your poor pay....
Re: (Score:2)
I suspect your willingness to place pride above your pay may have something to do with being poorly paid. The technical name for folks like you is 'sucker'.
I used to be the same way. Couldn't let a problem go unfixed, whether it was in my job description or not. And employers noticed to, realizing 'this kid is good, smart, and cheap, we should use him as much as possible!'.
Nowadays, I'll still offer the occasional hand out of the goodness of my heart, but the second the trend starts developing, there's a si
Re: (Score:2)
I think anybody that doesn't suck at IT has been burned or attempted burned at some point in their career, usually early on, then we all learn, then employers wonder why nobody stays over 3 years at their company in IT. Maybe we need to make skills marketing a part of the CIS curriculum. Still, there's some stuff worth working hard for, just none of it is located at any type of for profit business, well maybe r&d.
Re:There is only one way... (Score:5, Insightful)
If he's leaving happy, ask him (and your boss) to work out an hourly consulting rate so you can reach out to him for the next few months and he'll be properly compensated for it.
Re:There is only one way... (Score:5, Interesting)
I was a programmer for a small firm when I gave my two weeks. I offered them to come by now and again on on Saturdays or answer questions they may have had. Although they didn't call me often and I gladly went over there a few times, I did have to put my foot down and ask them to stop calling me after 6 months. I thought that was enough time for a transition and I only offered my services to be nice... not as a permanent solution to their inability to hire enough people to read and parse my code. The company didn't really want to look at my code or study it or become familiar with it until they needed a change and then they called me up so I could explain things to them. After reflection, I think most companies would either abuse my kind of offer or never call. Would I do it all over again? Yes. I'm a nice guy at heart and I'd make the same offer to the same people. They were a good bunch to work with.
I put this out here as a tidbit of info for others thinking about doing this.
Re: (Score:2)
The smartest thing anyone can do when presented with the threat of legal action is to immediately cease all contact with the threatening party and inform his own lawyer. I've seen situations similar to the one you described work out okay for the people being threatened, but I've also seen another case where things got nasty and the accused party would have been better off getting a lawyer immediately, even though he did nothing wrong.
Comment removed (Score:5, Insightful)
Re:There is only one way... (Score:5, Insightful)
The big difference here is that some filing clerk or HR drone, or Sales exec leaving, pissed or not, does not put your entire infrastructure at risk.
A pissed sales exec might try and take his customers with him. The HR drone won't be missed, they are a dime a dozen.
But the Sys Admin, leaving pissed, can put you in a world of hurt by just changing his phone number, not doing any skulduggery.
A vindictive ex-sysadmin can put your company down for the count months or years in the future, when you least expect it, from a cafe in Puerto Viarta.
Re: (Score:2)
"And remember : Graveyards are full of irreplaceable people."
Man, I wish I had mod points to give today, because that's a pretty awesome quote :-)
Re: (Score:2)
Re: (Score:2)
Everything here with the addition of asking why something was done the way it was if you're unfamiliar with it.
Re:There is only one way... (Score:4, Insightful)
Some other bits:
First, oddball configs - that is, take notes on any custom settings and processes.
Nothing is more irritating than to troubleshoot something, only to find that the configs are some goofball way-out-of-the-ordinary rigging that somehow works in spite of itself. Or worse, discovering that what looks like a straightforward deal becomes a messy multi-day-outage when you try to fix it according to best practices.
Sure, you can build-up a replacement that has far better/standard configs, or put together better processes... But that doesn't help you out when $system is down and your users want it back *right now*. It's better to at least get some insight into why it was set up the way it was, and you can then plan of rectifying that before it goes down (and as a bonus, knowing how and why it's rigged like it is, making t-shooting a lot easier to do.)
Also, I'd get some insight into what projects he had planned and in process - those will give you some insight into what you yourself will really want to pay attention to. For instance, if there's a backup improvement project planned, it may well be because the existing backup solution either sucks balls, fails any integrity checks you may have, or is about to collapse any day.
Finally, sit the admin down and go over all vendor-supplied services and service contracts (service, certificates, etc), and find out what's about to expire. It would kinda suck if you have your SAN (or worse, core switch, Oracle DB product, etc) crap out, then discover that the platinum 4-hour service contract attached to it expired a week after that guy left... per-hour charges are brutal, parts are moreso, and if your company does the whole PO thing? It's gonna suck.
Overall though - wring that guy's brain out, and record it to audio if you can. It'll save you a lot of headaches down the road.
Re:There is only one way... (Score:4, Interesting)
Re: (Score:3)
Assuming you both can find or figure out or guess each device's existence.
Without a current inventory, you are probably doomed. Something will be missed.
I've left a couple of positions on bad terms, but never, never refused any information. I've inherited several positions, and at least half of them were give to me with the incumbent angry as hell. Anyone remember the Emergency Boot CD? I used EBCDs during the NT era lots of times to hijack the Administrator's account on PDCs and BDCs after hostile dism
Re: (Score:2)
In other words, you're doomed. If he's working for a mid to large company, and they're giving you only a week to get up to speed...run. Something is terribly wrong.
Normally, a junior network admin is taken on for several months to years before a network admin moves on. That's to ensure that the entire amount of knowledge is successfully transferred from one individual to the other...and there is a lot to learn in many cases. Some places have multiple network admins, from senior, to mid-level, to junior, wit
Re: (Score:2)
It depends on the time available. Redoing every thing in a software package, even one you are very familiar with might, be too time consuming. It tends to be fiddly work, taking time that might be better spent.
Take a look at what exists, and carry that documentation around with you on your walkabouts, and adorn it with a huge pile of postit notes (with circles and arrows and color glossy photos) and add to the existing documentation that way, as you tour the facility.
Make notes on every item, making speci
Re: (Score:2)
I'd suggest giving GraphViz a shot. Make sure to check the source files into Git or SVN and pick out a good wiki package. Put URLs in your GraphViz input and have it generate SVG. Then you'll be able to click through your diagrams to the wiki for details.
Just getting the raw connection info into GraphViz source files will be much faster than putting it all into Visio and with them version controlled you can futz around later with layout. You can even pull the generated SVG into Visio or other graphics progr
Re: (Score:2)
Hope to Christ he took good notes.
Trust but verify a list of things.
Change and verify each password
How To Know Coming In (Score:2)
Only one week? (Score:3, Funny)
Run like hell....
Re: (Score:2)
Only three years on the job? Pop a champagne bottle and rejoice...
Start with Foundational Systems: Network, DNS, (Score:2, Informative)
Did this recently. Started with core network topology documentation, moved on to DNS. Foundational stuff. Documenting subnets, figuring out what documentation and systems should be deprecated. Made lots of diagrams. Reviewed monitoring tools. Prioritized systems by importance to review for best practices. Got a network security audit to find holes. Bam.
Re:Start with Foundational Systems: Network, DNS, (Score:5, Interesting)
Yep, whenever you change core IT people, you have them do a sloppy braindump if possible before they leave, and you clear the new guy from almost every task save updating the documentation and diagrams, with a few mundane tasks thrown in to get procedures down. This means you postpone your big projects if you have a staff change instead of expecting the new guy to shoulder that. Skillsets are not the same as in-situ knowlege.
Re: (Score:2)
Ideas (Score:5, Insightful)
Primarily, you'll want to build an honest rapport with the other person. Get inside their head a little and allow them to brag A LOT. Ask how they found the place and what they did to change it. You'll want to breeze through all of the high level and important documentation first so you'll have a baseline. Take as much notes as you can. Ask what websites/resources they use to make it easier to follow in their tracks. Explain your situation to them. It will humanize yourself in their mind and you might be able to engage their compassion for you. Perhaps they would be available to answer questions after they leave! Is there budget money for them to be used as a compensated resource? Hopefully they like the idea of helping others and putting some scratch in their pocket.
Bon chance!
Steve
Re: (Score:3)
Good approach. Making a mortal enemy of the outgoing sysop, or simply his object of scorn, will screw you badly.
Other than to say "you're screwed", the big step is to also ramp up the professionalism and start building a better system governance policy and documentation process. The best way to explain that to management is to ask "Do you fail the Hit By a Bus Test? ".... If your key administrators are hit by a bus, will your systems go dark ?
Re: (Score:2)
In software development we have something called the "code mocking [dilbert.com]". There must be something similar for network admins. As well as gaining an understanding of how the network operates you will also acquire a stockpile of excuses for when things go wrong. Blaming the last guy is industry standard best practice.
A week? (Score:2)
Step 1: Get Off Of SlashDot... (Score:2)
>> How do you digest the thousands of XXXs in a week?
Dude, step away from SlashDot RIGHT NOW.
Create your own documentation (Score:4, Informative)
Re: (Score:2)
Questions (Score:2)
Take over right away. Don't let him do anything. Ask lots and lots of questions. Take notes.
1. Get da passwords. Verify them. :)
2. Support contracts.
3. "What are common problems"
4. "Can I get your email"
Things to do (Score:4, Funny)
Make sure you have thick gloves and sanitize everything. Check for booby traps. Never push any buttons till you've traced the wires back to their origins.
http://bofh.ntk.net/BOFH/
Although it might take an hour or more.. (Score:2, Insightful)
happend to me this year (Score:3, Informative)
2) Require exiting person to produce network diagram. Make it their last duty if one doesn't exist.
3) Now starts the pain... audit devices and systems for rogue accounts.
4) document as you go.
5) turn in passwords to supervisor.
Good Luck
Re: (Score:2)
ha ha ha ha....
2) Require exiting person to produce network diagram. Make it their last duty if one doesn't exist.
"What are you going to do? Fire me?"
Re: (Score:2)
Indeed. The theory is that they will hold some small change over his / her head, like their last paycheck...but it's a gamble, at best (do you really want to piss off the network admin who can, with a few keystrokes, just wipe out your company? or better yet, refuse to help you when a problem, not of his / her own making, does arise? you don't want them pissed off at you, not when they have nothing to lose). Think about it...the company tries to show its strength by asking for some laborious process during
Re: (Score:2)
Re: (Score:2)
1) Need passwords... immediatly change them.Exiting person should have no futher access except through you.
Insane. The last thing you need is to lose access to something and spend your entire week talking to support trying to crack a device. Besides, they are probably still finishing up some work. You need to trust them and treat them with respect. On their last day, change passwords to protect the outgoing admin. That way they cannot be blamed for anything after that time.
2) Require exiting person to produce network diagram. Make it their last duty if one doesn't exist.
Network? We're talking about a sysadmin. I can't tell you how many times a company has detailed networking doc and monitoring, not no
Let them teach you (Score:2)
The incumbent will know what to teach you if you only have a week. If they are leaving on good terms, they probably won't be adverse to having some questions asked by email after they leave, so it's not the end of the world after 7 days.
I've left jobs almost a decade ago and still get an occasional question once or twice a year. It's not that it wasn't documented or couldn't be solved through a few hours of investigation, it's just that a 2 minute email and a 2 minute response later you get your answer and
Keep them on consulting (Score:3)
Keep them on as a consultant, and *pay* that $$$ per hour when you need to.
(This assumes they are quality folk in the first place, of course.)
Secret Server (Score:2)
Secret Server (or something like it) is very cool. Get the outgoing person to put all the access passwords, locations, etc. for every bleeping system in it.
Then change the master password after he leaves.
Time for a little social engineering (Score:2)
If possible, build a relationship with the outgoing administrator. Accept that a lot of his head knowledge will dissipate soon after he leaves the company but it wouldn't hurt to have him as an information resource for the first few weeks, just don't abuse the privilege. If he's moving on to another job, his loyalties and focus will be to them not his old company.
Get his permission and comb through his corporate inbox and home directory -- dump it to an offline location. I know you don't need his permiss
Look out for outsoureing pit falls with this (Score:2)
Now if the old guy worked for the IT services firm then you should not have the outsoureing roundabout in the way.
But if they worked at the place that the firm took over then there may be paper work / other things that get in the way like some things that the old IT guy used to work on are now not part your IT firm systems or things that you control / are part of your pricing.
Or other stuff the like the non manged box that does not have uses log to in but runs say the phone switch or the one that runs the d
Get most important stuff first. (Score:4, Informative)
The first thing is to figure out what are the Most Mission Critical systems, and cover them in order of priority, really try to press the criticalcality of the system.
Top Priority: Systems where there is a Downtime has an immediate impact. There is NO Work Around, it needs to run
High Priority: Systems where there is downtime work around and they can tolerate it down for a few hours while you mess with it
Medium Priority: Systems that can be down for a Day
Low Priority: Systems that can be down longer then a day
Try to get the passwords, or make sure you have a passwords and rights to all the systems work in order of priorities.
Create a network map, inventory every system, switch and router... Make sure you have access to them.
Find the Power Users in the area, they may be able to help you out later on, they may not know everything the sysadmin does but they know their little section and sometimes has tips and tricks that don't get passed on. If there is an issue after he leaves you have contacts.
Get the vendor support numbers if available.
Working in order or priority find the custom stuff programs/scripts etc... Do an overview on what they do, what language affect what systems...
On the second to last day, shadow the old admin, on the Last day do everything, he should only mentor.
After he leaves. CHANGE ALL THE PASSWORDS he knows, and check for back doors in the network to prevent him from entering the system.
Due to short time of transition you will probably stumble a bit, but you should have enough to hit the ground running.
beer (Score:2)
Re: (Score:2)
Vulcan Mind Meld (Score:2)
It is the only way to be sure.
Re: (Score:2)
Making two different sci-fi quotes, from two different universes and while still keeping it on topic... Simply brilliant!
Bows down to your quote-fu
Record everything (Score:2)
It sucks from the other side, too. (Score:2)
When I quit my last job, I was there for 5 weeks after saying, "I'm gonna go ahead and leave." I said I could stay as long as they needed to have a smooth transition but that was clearly a mistake. 2 weeks in, absolutely nothing had been done to transfer my tasks so I set a firm date for 3 weeks later. Had all my tasks documented but no direction on who would take over. Another week goes by. "Who is taking over these tasks?" And another. "Who is taking over these tasks? I would really feel more comf
Re: (Score:2)
Uh...were you a network admin, or just someone from a department?
My straight answer... (Score:2)
Collaborate with outgoing on a runbook (Score:2)
Seriouly, there's no hope you'll actually be able to cram everything you need to know into your brain and make it stick. You need runbooks [wikipedia.org].
Here's a Technet Article [microsoft.com] on how to put together a Windows server run book. You'll also be able to google for Linux or Unix examples, although you'll find mostly snippets focused on how to write a runbook section for one specific product or another.
A high-level runbook should document overall systems architecture: network layering, external and important internal connecti
Reverse engineering (Score:2)
Overview the available documentation, talk with the guy if he is available. A lot of times I ended up reverse-engineering everything although so be ready for that possibility.
As the outgoing admin/developer ... (Score:2)
Most of the stuff was 'glued together' with Perl. So one of the jo
Short answer (Score:2)
The short answer is: you don't.
You fake it until you make it, or can corner the guy in a dark alley and beat it out of him.
In all seriousness, I've been there probably more than most. I've worked most of my career for managed service providers (of varying quality) where there is no environmental documentation to speak of, in most cases, and almost invariably things are a complete goddamn mess because they're going from in-house to outsourced for a reason. More often than not, you're expected to replace 3-5
I hope that... (Score:2)
Invite them to a trip to a branch of the company (Score:2)
which is under a suitable jurisdiction. The waterboard them until they have told you everything. If somebody asks: terrorists attacked your network.
Spend a year (Score:2)
Some networks too fragile for nmap (Score:2)
You don't (Score:2)
How do you digest the thousands of hosts, networks and associated software systems in a week, especially when some documentation exists, but much of it is still in the mind of the former worker?,
My recommendation is you demand that your boss get the old guy on retainder to be available by phone and e-mail for at least 30 days.
You really need 14 days worth of acclimation.
Get as much as you can out of him, bring a notepad and pencil, and a voice recording device.
I recommend you start with him get
There is no good way. (Score:2)
On the bright side, you'll improve your forensic skills.
Disaster recovery drill (Score:2)
SSH Relay Machine/Audit Log (Score:2)
Not an admin but this is what I would consider doing with management backing.
Install a pair of SSH relay servers with full logging of everything going in/out of it to a write only filesystem. Configure production boxes to only accept connections via this relay server.
There are good reasons to have a full audit of everything admins do; and suddenly you know absolutely everything the admins are doing today.
If a ticket is closed and the process isn't documented, give your technical writer the log snippet so th
Put the departing admin on a 2/hour/week contract (Score:2)
Pay the departing sysadmin for their time, by any legal means, to provide additional information. I've had to work with companies where a core admin had just departed, and had to help hide that we then hired one such admin as part of our company with a different title in another group, partly so we could tap them legally for information about their old company's environments. We got a good engineer, they got a good contract to help out while they looked for a permanent role, and were able to factor in undo
Replacing the systems... (Score:2)
...should be the ultimate goal. Understand the design, get it under basic control and then work with a team (largest you can muster) of diligent specialists to design replacement systems that are firewalled off from the original. The reasons for this are twofold:
1) No matter how well documented, well designed, etc. the system is, your knowledge of it will never be perfectly complete and you'll never be able to turn around changes with the same degree of confidence and alacrity as the original admin.
2) Your
Been there - done that document and reengineer it (Score:2)
Re: (Score:3)
Who the hell manages to become responsible for 1000s of systems and networks without being forced to document them as part of their job ?
Lots of people. Welcome to system administration! Here's your accordion.
(I spent three years documenting furiously. We finally got a third sysadmin. He found my notes incomprehensible. Sigh.)
Re: (Score:2)
Lots of people. Welcome to system administration! Here's your accordion.
(I spent three years documenting furiously. We finally got a third sysadmin. He found my notes incomprehensible. Sigh.)
How? Did you write them in Russian or doesn't he understand the systems he is paid to manage?
Re: (Score:2)
Ineffective companies don't ask for documentation. In my job I document because I believe it's the right thing to do. If I never documented anything management wouldn't notice the difference. I suspect no-one currently there even understands my documentation but if I quit the next guy should.
Re: (Score:2)
A sudden transition implies the previous administrator is either leaving unhappy, did something to get fired, or died without warning.
Re: (Score:2)
A week of transition indicates the present sysadmin...hasn't died
I think you're seriously underestimating how screwed up management expectations could be.
"Look. He hasn't actually started decomposing in earnest yet. I'm sure he'll tell you if you ask him nicely."
Re: (Score:2)
Employment contracts specify a minimum notice period. While one week is typical for shelf-stacker jobs, an administrator position usually specifies four weeks or 'a week, plus a week for each year in employment here' for exactly this reason.
Re: (Score:2)
The twist: He's already kidnapped yours, too.
Re: (Score:2)
Step 1. Kidnap his wife/girlfriend
Fail on Step 1. The guy works as a sysadmin, what are you going to do? Kidnap his ramen noodles?
Re: (Score:2)
hope they have documents
If they don't just ask your local NSA guy, I'm sure he'll be able to help out with some diagrams and backdoors to your systems.
Re: (Score:3)
Then document as if you might be killed in a car accident on the way home to work and your manager has to take over.
I've never understood why any admin would care about this. If the employer is too cheap to realise they need support in depth to actually be supported, why should I care about the operation going tits up if I get taken out by a bus? They gambled knowing the risks and lost. Suck it up.
Real support is more than one over-worked wizard who knows and controls everything (cf. San Francisco). I want to be training a PNG into the position who can learn, who I can bounce ideas off, who comes in with a different
Re: (Score:2)
Some companies can't afford 2 sysadmin people. It's not that they are deliberately gambling, they are doing the best they can with limited money.
Obviously this only applies to tiny or failing companies.
Re:shadow while you can and guesswork there after (Score:5, Insightful)
Some companies can't afford 2 sysadmin people. It's not that they are deliberately gambling, they are doing the best they can with limited money.
I don't agree. If admin is critical to the future of the business, either they're cheaping out or they shouldn't be in the business in the first place as they're incapable of estimating the real cost of doing that business.
If something fails when I'm home sick and the business suffers, they should be wearing a "Kick me!" sign on their back. They've no right to blame anyone but themselves. I'm human, not a perfect machine or a robot. Expecting otherwise is just wishful thinking on their part. They deserve the consequences.
Re: (Score:2)
'Incapable of estimating the real cost of their business.' pretty much sums up most small companies. They cheap out in a lot of areas but in a lot of cases that makes the difference between getting wiped out by a debt collector on a bill they can't afford to pay and making a small profit.
Of course the upper management types never cheap out when it comes to their new company iphones, macbook air's, company cars, or giving the fat secretary they are screwing a huge pay rise.
Re: (Score:2)
Re: (Score:2)
Having worked for a smaller company that could only afford a one person IT department, I agree that it doesn't make sense paying for a second full time person to sit around and stare at the primary sysadmin while they do their job.
I've worked for a few of those too, yet I've never seen that. There's always been a lineup of requested features, systems due to be replaced/enhanced/re-worked, unexpected fires to be fought, and things to be learned or re-learned. Sitting around staring at someone else who's doing the work is what managers and ditch diggers do, not IT people, and I wish those people confined themselves to Facebook instead of trying to muddy the waters on tech sites. Why aren't they ruining HR's day instead of mine? HR'
Re: (Score:2)
No organization has the budget to pay for full time "understudies" for every role in the company.
Nor did I suggest that. Some roles certainly do deserve to be thought of in this way. If your IT infrastructure is as important to your business as we around here think it generally is, companies ought to be putting a lot more thought into this. IT is not just an accounting cost centre when it's storing critical business records, serving as the business' marketing face on the Internet, and making day to day work for thousands of employees even possible.
What you're, in fact, saying is that you feel you have no particular professional responsibility to document your work ...
No, I'm not saying that. I take documentation dutie
Re: (Score:2)
No, I'm not saying that.
You did say that ...
No, I didn't. When your nuclear physicist or rocket scientist takes a day off, do you expect your receptionist to dig into their notes to fill in? I produce good documentation and well commented code that those with an average knowledge or skill in the area can use to enlighten themselves to carry on my work. I don't expect managers to understand it nor do I expect them to want to. Writing it so they could would bore to death those who actually could fill in.
Re: (Score:2)
Switch your hours so your working 1-2 hours yours users are not per day. During that time you will get more done then the other 6-7 hours of the day.
I do exactly that. It's the best productivity advise ever. I also try to work weekends instead of weekdays some of the time just to get a better thoughput of work.
Re: (Score:2)
You can learn a lot in a week, if you really want to.
Re: (Score:2)
It's not the number of hosts that's the problem, it's how different those hosts are. A thousand hosts fully configured by puppet scripts, running the same OS, and most of the same software will be perfectly manageable by just one good guy.
On the other hand 10 hosts all configured cowboy-style, installed from CDs with all manual configuration, on old erratic hardware, with no resilience built in, would be unmanageable by anyone.
Giving someone too much time (Score:2)
I did that once and it had the opposite effect since upper level management assumed they would have a lot of time for the changeover. My replacement arrived some time after I left the state and my assistant with almost no experience was left swimming in deep shit for a week or two. That was after giving a couple of months notice and then at the last minute agreeing to delay my departure for another month. There's a middle ground somewhere