The “Get Hit by a Bus Protocol”: How to Protect Your Company From Sudden Staffing Changes and Build a More Flexible Team

When I first started commuting to work by bike, I never wore a helmet. After a few weeks of nagging from my boss, though, I capitulated and bought a helmet.

This is what my boss said to convince me: "If you get hit by a bus, then the company's gone!” He was exaggerating, but the point was spot-on nonetheless.

If you work at a small company (say, around 10 people), you can easily become too integral to your team. It’s fantastic to take ownership of projects and responsibilities, but you want to make sure that the business can proceed smoothly even without your personal intervention.

Some may argue that making yourself essential to a company is great for job security, but I think that removing oneself from the equation is better for the company as a whole — and makes you a better employee. People are expensive. The less the business relies anyone's direct intervention, the better it can scale and the more sustainable it will be in the long run.

Having day-to-day operations directly dependent on any one individual is also just dangerous. Everyone needs a vacation, and everyone gets sick. There are also unplanned absences — maybe a relative gets sick, or maybe, ahem, you get hit by a bus.

At a start-up, staffing changes are inevitable. Someone may leave for a different job elsewhere and/or a new team member may come on board. You want your company to be able to roll with these punches without too much difficulty.

Below is my "Get Hit by a Bus Protocol” — the steps everyone should follow in order to make the team more flexible (for its own good).

1. Document everything

Document all regular processes and procedures: how to set up the office printer; how to handle your biggest clients; how to respond to customers on common problems; how to make widgets; how you make your day-to-day decisions. Document, document, document.

As production coordinator at Vook, I keep a 7-page Google Doc which has step-by-step instructions for how to keep our production pipeline moving even in my absence. It covers nearly every scenario: how to manage a cover design job; how to produce a fixed layout ebook; how to scan a print book. I try to detail the processes as clearly as possible — almost as if I were writing a program for a computer to follow. Algorithms (if X is the case, then do Y and Z) tend to be easy for people to follow and also give a good grounding for later automation, if possible.

When your documentation is strong, you can onboard new team members easily. It’s much faster to point a new team member to a wiki or knowledge database than to spend time on individual, in-person training. In-person training costs the time of both the trainee and the one doing the training. Documentation can provide the basics and also give new team member materials to reference later.

This advice applies regardless of the role you’re in, but developers also have an extra responsibility to be commenting their code for later human readability. Any developer worth hiring, though, should be doing this already.

2. Store materials in a centralized location

I have been too often frustrated by not being able to get the files I need to finish a project because they’re stored on a coworker’s computer. Agh! This wastes the time of both me and my time.

Project files and any supporting materials should always be stored in a location where other team members can easily access them. Download project files to work on them locally, but remember to archive everything at the end of the day.

There are a variety of tools for this: Dropbox, Google Drive, Box — the list goes on. At Vook, we actually use a custom-built dashboard which supports file sharing between both team member and our clients.

Just think about storing files to the cloud. This isn't the same as backing up — which you should be doing anyway — because it’s more about sharing and decentralization. Digital files are more permanent print than physical goods simply because it's so easy to make copies. So make copies! Nothing should ever, ever, EVER be stored locally only.

3. Take frequent vacations

Vacations force you to see how things go in your absence. Vacations are safe ways to test your team's flexibility — i.e., without anyone actually getting hit by a bus — and have the bonus of recharging your team and preventing burn out. If you've already put in place processes to make yourself inessential, then vacations will furthermore test how good of a job you've done.

I like to take psuedo-vacations: for 2-3 days before I'm actually away, I'll have another team member cover my role while I work on projects I've had on the back burner. This gives the person covering my position the opportunity to ask questions while I'm still there — the answers to which I will then document — and it makes me more confident that things will run smoothly in my absence.

4. Automate

All routine processes should be handled automatically. Automation is probably best practiced by backend developers. If you’re not a developer, though, think strategically about your work: what can be automated, and how could it be automated? Typically, the more specifically you can explain a project, the easier it will be for a developer to build. Then try to get the project into your team’s queue. Or, consider a low-tech workaround. Many applications have automation functionality built in. With a little digging, you can set up email auto-responders, IFTTT recipes, Mac Automator programs, Photoshop scripts, etc.