Speaking as a lone wolf, (developer, dba, etc.) there's the likelihood that if I'm hit by the proverbial bus every bit of the IT "staff" knowledge goes instantly *poof*.
Therefore it is essential (from a professional, disaster-recovery, and moral) standpoint that my sudden departure from this mortal coil not leave the company high and dry. Many small IT departments manage with one or possibly two IT staff, so the danger is a lot wider-spread than people think.
To give my cold-turkey successor a fighting chance I've done everything in my power to leave copious organized documentation "just in case". There's a wiki for developers, covering every aspect that I can think of. What tools are used, what settings were changed, naming conventions, coding style, the logic behind the module breakdown in the application front ends and database back ends, theory on things like how the security works, and on and on.
The code itself is extremely comment heavy--70% comments to code by line count, with reasons why the code is the way it is, any gotchas, and not just "add 1 to I" type comments. 🙂 Another thing, I religiously keep comments in sync with the code, and try to review code before I change it, just to make sure it's understandable two years after writing it.
Steve's offhand comment about not being sure it's worth allowing someone to pick up if no staff is around should be a red flag. What happens if the IT staff was on a weekend retreat and there's an avalanche that wipes out the resort?
Unlikely, yes. But it's the disasters you don't plan for that wipe you out...