Read a lot of good posts and ideas so far here. From my perspective, the most cost effective solution for you and the business is, you need a backup engineer for in case you do get hit by that bus. Having a person knowledgeable enough about your network to keep it running in the event you are incapacitated for a length of time is by far the most beneficial, if for no other reason, because of the quick turnaround time they can come in and take over vs. company looking for another engineer, and the time it takes to learn the network and scrounge threw docs you created.
Very few documents are actually that meaningful if the engineer is halfway competent so as others have mentioned, no need to go documentation crazy. There are key docs I feel though that should be created and maintained and have been mentioned above.
1) Passwords, I cannot stress this enough, get all accounts privileged accounts and service accounts documented with passwords and secured somewhere (preferably off the network, such as a USB key with the data on it in a safe) as without this, it can be a very ugly scene.
2) Next, overall, logical and physical network diagrams are paramount. If done correctly can make troubleshooting a breeze, and a nightmare if not done correctly. One link that I like is a reference to a best practice guide about the Cisco 4000, 5000, and 6000 series equipment found here ( http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml#management_cfg ). Go to the network diagrams section and review the overall, physical, and logical section. Create your docs with this as a guide and any engineer who may have to troubleshoot the network will love you for it.
3) The answer to what 'other' documents should I create? Comes from you. Knowing what you know about your network, pretend you are coming into the network for the first time, and ask yourself, what I would wish I knew about this network? Make a list of your business critical functions where people would be screaming if the service was inaccessible. Document what would be useful info in a DR scenario of recovering the service. This leads me to the last doc I would recommend as useful only as an insurance policy for the business.
4) A procedural document of how to recover various business critical services. Again, key focus is on business critical, business users or clients will care less about non business critical services or be a lot more forgiving. This can assist greatly an engineer if good recovery procedures are documented, especially in area where customizations have been done (i.e. scripts and what not)
The other biggest important thing you should do is manage the businesses expectations. Talk with the business to get feedback as to What are the business critical services and document them. Next, get your Service Level Agreements ( SLAs ) agreed upon between you and them. And make sure you can meet them. If not, get a projects/tasks list together of what needs to be done so that either A) the business will fork over cash to meet agreed upon SLAs or B) they will accept the current SLAs.
The SLAs are important because it will force you to take a hard look at the network to see if you meeting their expectations. That is really what it all comes down to. When I.T. does not meet expectations is when the business gets all bent outta shape. Manage the expectations and get your SLAs agreed upon for restoration of services and you will be ok.
One more link that can help in ensuring you can meet SLAs is getting your RTO and RPO defined for you business critical services. Here is a nice easy link that talks about this that should help you.
( http://findarticles.com/p/articles/mi_m0BRZ/is_3_24/ai_n6017376/ )
All Finagle Laws may be bypassed by learning the simple art of doing without thinking.