What if the IT guy dies?

[b][i]"So what happens if he dies one day, are we screwed?"[/i][/b]

Yes.

[b][i]"How can I tactfully request this information?"[/i][/b]

Just do it. You simply explain what you have explained here. You're the executive. You're concerned about continuity. A function as vital as your IT infrastructure must not be hanging on the thread of a single individual successfully crossing the street every single day.

This is not a problem with this staff member. It is a management problem. If I were the owner of your company, and anything ever happened to this person, or if he quit, I would hold the appropriate person in management responsible for it.

Someone in management is not doing their job. If that person is you, I apologize for being rude (but I would say the same thing).

All the best to you.

Okay. I agree with all of the other posters so far. On the other hand when I was working as a contract employee I often came into situations where the previous system administrator hadn't documented anything and nobody knew the system passwords. These things can be handled. It could cause down time but you aren't completely dead.

Documentation is a tough issue. I try to keep good records so that another system administrator could pick up where I left off just by reading what I have written. It is unbelievably difficult to keep the documentation up to date. Written records become inaccurate quickly in a dynamic environment. Sometimes it is really really difficult to keep good documentation up to date.

On the other hand if business data is being encrypted with a system that only has one password and uses the password to encrypt the data then that data might be lost forever. Few businesses employ these types of measures even though they should be used for all confidential data. In this case you need to know the password for the encryption algorithm. You also need to know what encryption method is being used, how it is implemented, and how to restart your computers without the help of the system administrator.

It's not a good thing, but it is pretty prevalent. I don't know if it's intentional or not, or if it's the result of improper training, poorly understand needs by management, or what. But, yes, something must be done. There should be a single document that identifies EVERYTHING, and secured control for accessing things like passwords.

A problem I've encountered frequently is one that isn't intentional--people set up files or objects, and by default the creator is the owner. That person leaves, their account is deleted, and the file or object is suddenly locked out. It's IT's responsibility to make sure that PUBLIC resources are created and maintained in a fashion to prevent this!

I do think that too many people want to be considered critical, can't be replaced.

When I first started at my current employer, there was not one spec of documentation about the network, passwords, or any other technical matters. No one even knew who the preferred vendor was for telephone system support or purchasing toners.

While keeping complete documentation is difficult to establish and maintain, I have found that setting up and keeping my records has been a huge tool in ensuring everything runs smoothly. How can this person even trouble shoot simple network issues? I find my records invaluable.

I don't think job security is the motivation here. This may be a cover up for a lack of skills.

to force documentation on things like this. I currently am in a position where I need to document things/procedures, etc. I was told this
In case the whole team wins the lottery tomorrow and never comes back, the documentation needs to be up to date, accurate, and legible for the most incompetent computer user.

often screenshots are used, with good documentation. To answer many questions, all I need to do is email the .doc file and ask if they need help or have problems to let me know.
I may get 1 response out of 30 that they couldnt understand it (usually they didnt even open it).

And he is so busy doing everything, that his down time for documentation is very short? And , please do not take this the wrong way. It does need documented.

But, as you said. 1 person to support 50 people can take up a lot of time. Normal desk top support, network outages, client/server software upgrades, future purchase research, ....

Just saying, this person must have a boat load on his plate at any given time. Maybe offer this individual some support personnel for documentation purpose's. He does a review with his support personnel twice a week, and that person goes off to perform the documentation.

Dan

to track down and document all the information. I made sure I had high level coverage before doing this, as to find some of the info, we had to cause problems to make the guy fix them, and show us some of the more obscure details in the process.

he'd been given two years to properly document the system, required for accreditation. he didn't do it, so I got shipped in from another area to document it. much I could find out by just examining the system, logs etc. Took some time.

Once we got it documented, all the core root passwords were changed, so he couldn't lock us out. And he was given secondary access passwords, so her could do his work. All systems were imaged, and the images stored where he couldn't get at them.

BTW he was lucky to not lose his job. His refusal to document, nearly cost the company one of their most profitable contract - couldn't keep the contract without the certification, and that required full documentation.

Another way to handle something like this, that I've seen done. The network needed a major upgrade, so the approach was taken to design and install the upgrade as a whole new network, full documentation was needed to purchase the hardware and software. The new system was put in place some months later, and turned on. The old turned off.

As to getting the info off the individual, you can only ask him, and point out that he's placing the company in jeopardy by not documenting the stuff. His continued refusal means that they have absolutely nothing to lose by sacking him, they'll be no worse off. And can then afford to hire someone to do the job properly.

goes on 'stress disability'?

This happened to a school system I know of. The gal in charged was the only person who know the root / admin password for a unix system. She wouldn't give it to anyone else. They ended up reformatting the system and re-installing!

I had a simmilar problem at an electronics company. One of the engineers was in charge of a system and wouldn't give the admin password to anyone. He went on vacation to Korea and we couldn't maintain the system.

You might want to consider contunuity books for your entire organization, if not at least your key folks.

See my TechRepublic article at: http://articles.techrepublic.com.com/5100-10878-6119262.html

You are right to pursue this - I was on a recent project where users had been using VB scripts dished out by someone who had since died suddenly. There were no controls on these scripts, and, of course, there was no documentation.

We did a major install, not realizing that these scripts existed. All hell broke loose.
This was the first time in over 20 years that I had been on a major project that was pulled back out! This easily cost the client six figures several times over.

We rewrote the scripts and reinstalled them, only to find out the emulators on the PC's were disparate. IT had to buy all of these users new PC's and/or emulators as part of the political price. (I mention this to show the ripple effect.)

Absolutely, you need to pursue this.

Kudo's to you for realizing this in the first place. I'd have to say most executive mgmt officers are clueless to this matter.
At my previous place of employment, the Net Admin came to me and asked me if i wanted to shadow him since he didnt have a 'backup'.
I would go to work 4hrs early, trained with him for 1.5yrs while doing my regular job there as a NOC Tech, but wanted to get into pc/network support. the time came when i found another job closer to home, and paid much more money. I informed the manager of this, and said i really didnt want to leave, and really wasnt about the money, just wanted a position performing pc/network,
requested a position as his backup,
and his coworker who was the email and web administrator and the pc and mac support departments.
and asked what he'd do if anything happened to the Net Admin., his response was,
'we'll just hire someone more qualified'
Considering their type of business, they jump thru the roof when there was any type of outage, they were willing to take their chances of not having a Net Admin.
I left, and wouldnt you know it, the mgr hired a friend of his to be the 'everyone' backup for which i was looking for..for alot more money than i would've done it for.

I am in a similar position to the IT Guy you mention.

I agree with what was said above. Everything should be documented.

I took over the IT Dept. in March 06 for a small company of about 45 users.
I was told all the passwords but none were written down.

The only documentation was a Shorthand Note Book with a load of scribbles and IP address?s in it.

It has taken me till now (8 Months) to actually document everything.
All passwords are kept by the PA to the Chairman, so in my absence people will still be able to get onto the system.

I am the only person in the company with Admin Rights and access to the Servers. However we also have a Contractor that comes in sometimes that can cover Hardware issues who also has Admin access and access to the Servers.

Unless Your IT Guy has is seriously worried about his job then he should have no problem providing you with the information you need.

I have been making a living off this very circumstance.
Non-documentation is potential suicide.
If this individual is part ofthe executiv staff, he should know better. (Maybe you are not in the awkwardly unreasonable "need to know" group.)
If this is a true issue, indicate that any and all disaster recovery/business continutiy plan REQUIRES this information is some form.
Unless he is the ultimate decision maker. Suggestions about BC/DR usually attract the desired attention

Same size company, I am documenting. It's part of the job. What annoys me is when the documentation is controlled and evaluated by someone who does'nt know anything about IT. I assume that the document is for myself or someone with equal knowledge. I don't need to know where to click and I dont need screenshots of every step of a process. Also, many things are already documented out there, but that's not enough for some people, project managers especially. It is very time consuming and useless in most cases to rewrite and explain concisely all the documentation that is provided with a software or hardware product, and that you already paid for by the way. The IT systems are alive, what I like to do is to write sort of a story of the IT environment, split in different services if I have to. Then, throughout the story I add hyperlinks to tech doc for more precise references, or to web sites, even to the actual production system. This makes it interesting to write, and to read!!

Hope this helps.

Stefan

For IT, an absolute minimum would be to guarantee that at least one other person can run a backup AND a restore of your primary data services without ANY HELP. From knowing where the tapes are, to getting the server completely operational needs to be possible. If you have the hardware resources, run them through a disaster recovery drill.

Find the people who you would entrust with the data, and would be responsible to recover from any disaster. Have THEM create a document saying who is their "backup" for each other's specific roles. Then there is outside pressure as well to document, as two people's jobs will rely on protecting each other's work.

Make them painfully aware of the consequences - ask everyone to answer the question "What would happen to the company if your co-worker died and left no documentation whatsoever? What should we do to protect the company, and in turn, our own jobs?"

Please remember, losing the IT guy isn't the only personnel "disaster" that can happen.

Not knowing where your customer, vendor, contracts, contacts, media events and other data are can be just as traumatic.

Forgetting to rent a booth at the big annual convention where your company generates 30% of your sales for the year could be considered vital as well.

Case in point: Eagle Computers Inc.
To quote David Perry, the very last employee of Eagle Computer:
The Eagle was smaller, lighter, quieter and a cooler design than the IBM PC, but two things really put the company out of business.
First, the IBM bios case (eagle rewrote it's bios as part of the settlement, but the delay the case brought caused all of eagles components to age one year--and after 1986 every computer Eagle sold was at a whopping loss. And, second, the president of the company died in a car crash the day that Eagle went public.

And you don't even have to go to the extremes of the IT guy dying or getting fired.

What if he ever is sick or takes a vacation?

It is complete incompitence on the part of the boss to not make sure there is documentation, as well as at least one other person cross-trained as a backup to cover during vacations and sick time.

As for from the point of view of the Tech, documentation is a pain, not very fun, and no one EVER wants to "waste" their day with documentation. If the culture is such that he has never HAD to take the time to document, why would he? It is hard to come back later and change this, but it should be done.

So don't automatically assume that this is for a false sense of job security. How well have YOU documented everything you do on a daily basis?

This is a sticky situation. I would like to believe that after talking to the IT guy, he would agree to do the documentation (and actually do it) and things would only get better for both parties. The sell is, that he is basically stuck for vacations, advancement, etc because he has created a single point of failure (which the manager has allowed to happen).

If he fails to respond to your request, then possibly hiring someone else to "assist" him (a temp to perm position), might help. Once the new guy learns the system, you can let the IT guy go because of his failure to meet work expectations, and then get the new guy to do the documentation.

Bottom line: The IT guy isn't a team player, and the manager needs to find out why the IT guy feels threatened. Who knows, he might just have poor writing skills. If that fails, it is time to let him go.

0. At the moment, you're totally screwed.

1. Your business has no disaster recovery plan, and single point of failure for security.

2. If your business can't operate without the information system working, then this person has just become the most important, powerful person in the company.

3. If you suspect that this person will react badly to being ordered to produce documentation, then you probably should bring in someone during off hours to do a physical analysis and document that way. Physical wiring/wireless nodes, PC and server makes & models, OSes, application software & versions, backup media & methodology (if any), etc.

3. Copies of the license numbers and product ids should still be around the building/office somewhere, dig them out. Passwords may even be written down somewhere in his office/desk. I presume all office furniture and supplies are provided by the company, therefor you shouldn;t require a warrant to search at will. However, if the situation is really this bad, it's entirely possible that the default admin ID and passwords are still on the systems.

4. If you are willing to terminate his/her employment, then you can impose conditions that he/she turn over all the passwords to the systems. If he/she does not, then you can take that person to court for theft of both the entire value of the system, and the information on it, and for all business losses incurred until he/she provided the access codes.

5. By the way, the value of your information on your systems is usually way undervalued by several orders of magnitude. That information is worth, at a minimum, the average pay of the person(s) who entered it, times the amount of time it took to enter. Add the value of the contracts/sales/materials/etc produced, possible legal costs if it's not accessible (for instance, a suit from a patient for failure to produce a list of people who have accessed their medical record for the past 7 years), and you start looking at 6 figure numbers or greater really quickly.

I'm a volunteer officer for a police department and our IT guy did die... on his way to C.E.S. in Las Vegas on his motorcycle he was hit by a car and killed.

Everyone in the department liked him, BUT, as an IT guy he left a lot to be desired. He had his hands in so many things from the network and servers to desktop systems, telephones, you name it. He did have a backup but she handled primarily desktop issues and he didn't share much of his knowledge at all.

When he died, his knowledge went with him because it wasn't documented anywhere.

Fortunately, all was not lost... just chaotic for a while. A few IT techs from city hall came over and went through and hacked their way into each of the servers and documented everything including the network (some of which I knew because of my regular job). They also standardized all the desktops and install brand name machines
to replace the cheap (and very slow) locally built PC clones.

Currently we have a primary tech assigned to the department, but there are a few others at city hall, including the city's IT Manager, who now know the "lay of the land" at the PD and have documentation.

My recommendation would be to get your IT guy to document everything. Make sure he's got time set aside in his schedule for such activities.

I would list each area he is responsible for such as servers, network and desktops and software for example, then set deadlines for him to have full documentation for each of those areas. Then you review it to make sure it is both useful and complete.

Make this part of his performance review also. Ask him to begin working on this as a normal request and discuss with him exactly what you're after. If you see no progress, start getting tougher until you get results. And get a backup Tech in there too.

As it is now, if he were to die, everything would go to $#!+ and remain chaotic for a while... but it's not the end of the earth.

You need the documentation not only for normal operations, but for disaster recovery and business continuity as well.

In our business, we had almost the exact same situation. Except the single IT guy was me.

While I do write everything down, store all the paperwork, etc - it's all filed in my office/ desk. Last year, I got one of our programmers that I trusted and showed him where I kept everything. In this last year, anytime I had a project, installed new hardware, software, ANYTHING IT related, I made him aware of it, and also provided him paper copies of anything needed.

2 months ago, when I tried to blind myself with my contact lens (see a previous thread)- I was out from work for about a week. While there were some minor IT problems while I was gone, everything was handled by my "human backup".

When I returned to work, he updated me on all that occured . And then threatened to create bodily harm upon me himself if I ever did that again (something about he doesn't get paid enough to do my job (chuckles)).

I have no concerns about Job Security, in that now NO ONE here wants my job!

Fire him immediately for incompetence and escort him off the premises. If possible get some admin rights before you do that.

Then get a good contractor in and pay him well to bring the untidy mess into shape. Once that has been done either outsource the work of recruit a new permanent technician to run the show.

I am in a similar situation. I work for a company of about 60 people and we have one Network Admin. He documents nothing and I should know because I am the person they hired to train as a back up for him. Just in case he would get hit by a bus.

He has failed to teach me anything and the company is right where it started. I am actively teaching myself how to do his job. But he is unwilling to teach me anything. I have been here a year and I am current looking for other opportunities in my area.

So if you are going to hire a back up to this guy then you better make sure he is willing to train them.

I know I am young and fairly new to the IT world but I believe that you are only as good as your documentation. If you do not document anything then you are just keeping the company above water.

The next guy that takes your job will have to undo everything you have done to understand how everything works. Just seems silly to me when people don't document.

Do you think that implementing a Business Continuity (disaster recovery) plan/audit would engage this person enough to spit out the information? Wouldn't a DR recovery plan, by it's nature, be complete enough to be done by someone other than the administrator (in my opinion) in case of the key person not being available? Wouldn't it have to be tested by someone not totally familiar with the in house system?

Tell the IT guy that to prevent curious hands from getting in the works (might be part of his motivation), all the documentation is going to be locked in a fireproof company safe.

I would think that the admin passwords to a company network are indeed a valuable company asset, and NOT owned by the administrator. I would think he would be legally liable should he not give them to you.

I have this same experience (in the IT guys role! and I assure you its not job security.
It is a failing of management to acknowledge in the first instance the role this position plays and the time needed to perform this role. Its easy to create a position of IT guru and feed ALL your IT issues to him without any consideration of what the position actually does and what time they have to do it in.

In my experience, I was just simply flooded with work to do, requests for new equipment, software, setups, support, "do this, do that...and yesterday if you don't mind ...Please!".
So I just did the work...without bothering with the NECESSARY documentation, work trails, etc etc.. I always thought I would come back to it..yes well...
I did come back to it, after I resigned and negotiated with the company to do the documentation and assist the new PEOPLE (they employed 3 people do do my job!). I acted as a consultant IT Facilitator for approximately 3 months and then management decided that things were working so smoothly, that they employed me again fulltime...IT Manager!

Anyway the moral of the story is:-
Management needs to not only understand the role but appreciate the time needed to do the role.
The IT guy has to convey to management the issues they are encountering, ie lack of time etc... and make them understand the importance of procedures, documentation etc..
If they don't - resign and re-negociate!! it worked for me!

If you are in the senior management position, you are playing tippy toes with potential disaster! Use your management? skills and have a one on one with your IT guy and explain your concerns and ASK HIM what HE thinks can be done to resolve the issues!

my 2 bobs worth....have a good...no... GREAT day!
Jeff

There are lots of firms that will gladly manage pieces of your IT to alleviate this risk. If you have major concerns about that business model, then start with something mundane like patching.

If your IT guy is a good one, he'll be pleased to have the cycles freed up to focus on more interesting and strategic work. He'll be happy to work on something that really differentiates your firm and creates value. Seen it happen many times.

Even if he's got good documentation, if he leaves the firm, you're stuck until somebody who knows something can get hired and start working.

First, is he actually not willing to provide the documentation or is he just too busy to write it up? Different issues require different approaches.

Most of the posts have focused on legal or mangement tactics to get this documentation in place. Most of these seem to be relying on forcing the issue.

Try another tactic ... remind him that the person who is the only source of information on the system never gets a day off or vacation and may be expected to be effectively on-call 24 hours - 365 days a year. I did this for a while, it stinks.

I document everything so that when the trivial stuff happens, anyone who can read the docs can usually resolve their problem without calling me! This means that the on-call cellphone doesn't ring unless it is serious.

Having the documentation in place at each office and in the network room or server room means that anyone who calls me for something serious can be walked through the basics before I jump in the car and drive in. This saves time and phone calls on my time off.

Remind him that good documentation will simplify some of his support issues as the end user can often resolve their own problems.

As for passwords (any passwords) they should be documented and locked up somewhere so that if he steps in front of a bus you can get into your systems without having to hack them. This is a job requirement IMHO and I would make sure that this is the first thing he does.

You need the documentation. If the current FTE can handle the task bring in a body (800905GEEK, whatever) to take the load off so that he can get the documentation done. Going over the procedures with the consultant will help to gather the data needed to write the doco. If the current guy can't write, then have the rent-a-geek do the writing. If you are serious about business continuation, get it done.

Jack

As a techie who was recently downsized and demoted because I trained someone else to do my job as I was going on leave, I would say that the IT guy safeguards his knowledge by only sharing only the basics.

However, I think he should document his work as part of his job duties, as documentation is important for continuity of the business. Also, it will save the company money in the future when something happens to the system or if they have to upgrade.

Additionally, there should be another admin performing a similar role (maybe not as much as him, but being an administrator nonetheless), as heaven forbid it and one day, he actually dies. And the office would be forced to start over from scratch and spend huge amounts to reset passwords, etc.

After reading all the previous postings, I want to note the following points:
- I totally agree with the need for documentation.
- Any of the suggested reasons for the IT guy not doing documentation, lack of time, need for job security, etc. are possible.

I would like to add one additional possibility: in the 40 years that I have worked in the field, I have worked with several individuals who simply cannot write documentation.

My recommendation is to hire a good, emphasis GOOD, technical writer. There are some out there with the kind of experience you need. (I am NOT looking for a job.) For example, I programmed for 9 years, worked as an analyst for 12 years (both system and business analysis), was the project manager on several large systems and I have both formal and informal training as a technical writer. I have worked with several tech writers who have similar backgrounds. Technical writers like this are not cheap, but definately are cheaper than being caught in a disaster with no documentation!

If you are interested in finding a technical writer with this kind of knowlege, check with the Society of Technical Communicators, STC.

This may have all been said but I haven't read all the posts.

First of all this is nothing new in either large or small orgs. It is a combination of self preservation - if no-on else knows it they can't sack me, laziness - I know I should document key information but can't be bothered as it's not the fun part of my job, poor corporate culture - the org as a whole has little or no processes to control/govern (which as an exec you should be managing!), personality - techies in general like to play/fix/build not document.

If you articulate the impact IN BUSINESS TERMS not IT speak to your fellow Execs e.g. if he dies/leaves/forgets what he knows the impact to our business will be x, cost us y, this should get their buy in (most if not all of them) then task this person and others via their objectives/KPI's whatever you use to deliver. Track with interim reviews and if they don't do it don't give them a pay rise.

It's a cultural thing which is up to senior management to drive and usually takes quite a time to implement. However you have a specific area to target so it will be easier to address.

First off. NEVER WRITE DOWN PASSWORDS. That is the Golden Rule!!!!! The most vulnerable password is one that is written down. So I give him an ?A? for that.

As for the Network diagram. I must first ask how big is the Network? Is it a dinky little Network up to maybe very modest in size? If it is then bring your camera in and take a picture hang it on your wall and problem solved. Small Networks are not worth documenting and I'll bet he agrees. Network diagrams are over rated in general and really only apply to diverse, large or perhaps unique Networks.

Now on to documentation. You say that you have 50 people and he is the I.T. Department. A one man I.T. department probably doesn't have much time to change his mind let alone document.

Ask yourself what the documentation is for. He already knows what to do. You did not mention if he has a backup. So if you do not have a backup for him then just who would be reading the documentation? If you have a backup then have the backup write down what they know. If he dies then you will be hiring another I.T. Pro and you will quickly find that a real Pro just doesn?t have that much of a problem stepping up to the plate and getting it done.

The first thing that you mention is job security probably being the cause for not documenting. Being the CEO and mentioning that first tells me he has good reason to be concerned about his job security. Perhaps you should consider alleviating his concerns by giving him a bonus and a contract which guarantees his job security and with that require the desired documentation with the exception of writing down passwords of course. That will solve it all.

You can "tactfully" request the information by suggesting to him that such documentation would serve two purposes: one is to actually help him manage the network, and the other is to provide the documentation necessary should he become unavailable or incapacitated for any reason, either temporarily or permanently.

I'm also a "one-man" IT department in a similar sized company, and I can't imagine doing everything I do without documenting it. It actually helps me "remember" everything. My documentation isn't a training manual, per se, where just anybody could pick it up and run with it, and I suppose not absolutely everything is written down, but should I meet an early demise, any decent IT professional should be able to come in and look through the files and my notebooks (3-ring binders), and quickly figure out what's going on.

I might suggest that in his next review you bring it up and make it one of his "goals" for the next year. If he squawks, it would be a good time to talk about his objections and your reasoning. If he out-right refuses, you might drop the hint that the lack of job security is exponentially better than the lack of a job.

By the way, if he's that concerned about his job security, there's probably more going on than meets the eye.

I am on the board of a company that has a product/service that addresses this issue. They would agree that this represents a serious vulnerability. What is even more likely and equally as serious is that this person could quit and take this knowledge with them. This person can also hold your company hostage with his knowledge. How much would you pay to keep him from leaving?

The company I mentioned above provides a combination of a pre-configured IT infrastructure designed to MS best practices and provides the platform for remote management. They provide on-demand and proactive support both at the system and the desk top level. There is a lot more to it than I have described. If you would be interested in talking to the CEO of the company, I can put you in touch with him and he can better explain how it works. The concept is that IT is handled seamlessly at a lower cost than internal IT, is predictable and you never have to worry about the "Death of an IT Guy". Ben

EVERYTHING should be documented period! That said, don't expect the IT lead to document things that all admins should know. However, configurations, backup details, router/firewall configs, etc. should all be backed up.

We keep all SYSTEM configurations and Documentation in a share accessible to all IT staff. Our security needs within our department are minimal in terms of who can see this info. Our goal is to share everything and NOT keep things secret.

Remember, the network belongs to the company and not this one person no matter how important he thinks he/she is. He/She is not using due diligence as he should. His goal should be to make sure anyone could walk in there and take over if needed at least to a large degree. Every place has their company-specific applications and systems but if those are also documented there should not be that large of a learning curve. In reality, one would assume that more than one person is familiar with such systems. If not, the company is at fault.

Also, we keep a password file which is encrypted and password protected in this same IT share. Suffice it to say, we have many, many passowrds set on a wide variety of devices and server configurations. In other words, if one password was compromised it would not automatically mean EVERYTHING is compromised. That is a matter of preference. If you think one username/password is sufficient make sure you document this information and keep it in a safe and change this often. I would avoid this and services on systems should run using specific accounts and not administrator or domain admin accounts.

All router, firewall & switch configurations are saved as text files. We create 2 versions for each device so that when we make changes we always have a backup should our changes cause issues.

At one location, we created a sealed envelope with administrator RSA key fobs, passwords,and some network documentation and gave it to the Accounting chief to keep in his safe. That way, should anything happen to the IT staff for whatever reason you would not be stuck.

Another worthwhile effort which could greatly assist someone coming to your site is a Visio Network diagram showing your various VLANs, ISP circuits, server layout, switches, etc.. This takes a great deal of time to create but once created it makes working with the network that much easier. We use one here and update it as necessary. Even though we know our network pretty well we still refer to it especially when thinking about implementing new configurations. It helps to make sure our proposed solution will actually work and it is invaluable when working on Firewall and Router configs.

With some thought and keeping some of this simple it isn't that difficult to create a basic "document" detailing the various set ups at your site. Just give the guy time to do this as that was always the problem I had at other sites. Management wanted everything documented but never gave us the time to do it. Please be kind to IT...we have lives too :-)

Hope this helps...good luck!

Having just taken a new position at a similar sized company and in the same type of role heading the IT dept, I have been overwhelmed by the lack of documentation and passwords. I have to pretty much discover everything for myself. I am documenting everything as I go, so that if something does happen to me, or I go on vacation and need someone to cover the routine tasks while I'm gone, things will go smoothly.

IT people who don't document are showing their lack of experience, since documentation does not cause a lack of job security.

As presumably the IT persons boss you have every right to expect an employee who is a department onto him/herself to make sure that everything they are responsible for is documented, not just the IT guy. This documentation should be part of your business continuity plan.

I'm coming into this thread late and have not read all 77(!) posts. But I searched the thread for "wiki" and didn't find it.

We used a wiki, Confluence - http://www.atlassian.com/software/confluence/, which is commercially supported open source.

We maintain most all dept info in cross-linked pages and tables with all of our customers, projects, hardware, software, etc. Anyone can edit anything (though access controls are provided)

So, if anyway disappears - or is even out for a week or two, we have enough context to keep most anything running.

It took a little while to get everyone to contribute, but once we did it became somewhat addictive.

We even use it to track project status and in 1x1s with staff.

Firstly, IT guys NEVER die. If our physical body stops responding, we simply request for the Matrix to make us a new one.
Secondly, if you hire an experienced IT professional, he/she should be able to figure it out by reverse-engineering the situation. If that fails, there is trial and error, and then there is "Screw it, I'll make my own."
It is usually easier to have documentation, but getting it from your guy may take a little strong-arming. You can first ask nicely, then firmly. If no results, you can throw some geeky logic at him using an if-then statement like: If you do not start documenting procedures, then you will be replaced (this is assuming you have the authority to replace him).
If that does not seem like it will work for you, you can hire an "assistant." Just make sure he does documentation. Once your new-found assistant is acclimated and can run the network to your liking, get rid of the old IT guy.
You may not want to start this above procedure unless documenting is critical or you would like to be rid of your current IT person for other reasons.

What if the office burned down?
Make up a Disaster Recovery Commitee (for real). And commit to a plan; then burn it on a CD and store it off site. No DR plan - no holiday bonus and no vacation until it's done.

You can ask the guy to document, but you will fail. He is probably too busy, with only 1 person for a company of 40, and there is no incentive for him to do it.

To start with, if you can only afford to have one guy doing all the IT stuff, and that's all the IT stuff you need done, you should outsource it, and not have IT department at all. And, of course, put the documentation requirement in the agreement when you out source, and you should specify that there must be more than one person working on your company.

You can have two or three people doing this job part time instead of one person doing it full time. But that takes more money than out sourcing.

If you want to outsource now, talk to the out source company and see how they can help you to get things in shape.

If you choose to have more than one person working on IT in your company, ask your current IT guy what needs to be done to rectify the problem. With more help coming, he may be responsive to your request.

Why not turn it around on the IT guy and ask him if he won the lotto what would he do in respect to his job - if he says he would be out of there then you have an in to start documenting everything.
There is also an alternative to the problem and that is to get an external support company involved - especially if there is only one of him - to cover for all support when he is on holidays and sick leave or for level 2 and 3 when he is too busy. This will allow for someone else to document the system and report back to management with a complete network system.
As a pure disaster recovery and Business continuity problem it also means you have a single point of failure that you need to do something about sooner than later.

Others here have suggested the same thing, but I have always said that if I had a small business, I would not hire an "IT guy" until I had enough work to justify two positions, not just one. For all the reasons you and others have stated here, I just wouldn't want to have my IT resources dependent upon just one person.

So what to do until then? Outsource it. Get a good agreement with a good company. Don't want to get rid of your IT guy? Outsource IT, but then put your current IT guy in charge of the SLA or outsourcing contract. Let your IT guy be your VP of info services (kind of sounds like a promotion doesn't it?) then set him free making sure everything is being taken care of by the outsourcer, and have him doing some IT strategic planning for future growth. Also, make sure he is working with your vendor to have appropriate disaster recovery/business continuity plans and that they are being tested. AND, he should be auditing the compliance of your IT vendor.

Anyway, that is just a suggestion. But this might help your IT guy be more useful to your company in the long run and also help mitigate some of the risk that you have currently. You might need to train your IT guy in new areas, such as to be more of an IT manager/director/visionary, but the investment could pay off for both of you in the long run.