There is a business management phenomenon called "Bus Theory"-- namely, the factor by which a project or business would be affected if team members suddenly disappeared from a project. It has even become a macabre joke -- someone might say "If I was hit by a bus tomorrow" this company would fail.
In 2008, my fledging startup team got a call you never want to receive: one of our server administrators had been killed in a motorcycle accident. At the time, the company was small, less than a handful of employees. Not only was the loss of life a tragedy in its own right, but every one of us had expertise that no one else had. The "bus factor" for each one of us was simply unacceptable.
It took us months to unravel the mess that his death left behind. Years later, there were still virtual machines and systems we didn't have access to -- mainly because we didn't know they existed. We had to recreate his daily tasks from scratch, and it caused us a lot of security headaches along the way.
So how can you make sure you are truly prepared for the unexpected?
Define Clear Roles and Responsibilities
Once the shock wore off, my company and I realized that this was not an isolated incident. As a small company, we didn't actually know what anyone else did day-to-day, we just assumed work got done somehow.
To combat this, we first polled each employee on what their day to day tasks were in a free-form survey. Once you have those results, you'll quickly be able to see what is being done -- or not -- and by whom.
Identify Your Bottlenecks
We created a RACI (Responsible, Accountable, Consulted or Informed) matrix chart with all the listed tasks, and some others that we felt should have been listed but may not have been thought of. We then sent that out to our team and had them complete it.
Based on their results, we were able to identify a few glaring issues -- namely, there were some roles that no one was completing at all, and many others that no one claimed accountability or responsibility for. Worse still, there were multiple items that only one person had chosen for any at all.
When you see these roles and responsibilities laid out on a RACI chart, it becomes immediately clear where you need to focus your training and hiring resources.
Once we had a fairly good overview of what everyone was working on, we now needed to have them write a basic procedure manual for their job. These started out basic-- more like checklists-- and over time started to gain a lot of detail. As the company grew, this "training manual" became a bible. It allowed us to onboard new employees quickly and ease the pressure for outgoing ones.
My rule of thumb for documentation is that anytime you create or learn something new that you feel is a valuable addition to your job, simply write down what you learned and what sparked the exercise. For example, if you were trying to create a PDF from a Google Form and found an awesome new tool, write down what the intention for the tool is, how to install that tool, how to use the tool.
And most importantly, make sure that no one person is solely responsible for anything in your company. As we were a new company with relatively young employees, it was fairly unthinkable to us that the "bus factor" would take effect. Once it did, however, we instituted cross-domain training for everyone in the company.
We created distributed backups for every role listed on our sheet, so no one person was solely responsible for anything.
With these simple precautions, you can ensure that even if the worst does happen, it will be full steam ahead.