There’s an elephant in the startup room, it’s that one of the defining aspects of work-life balance at an early-stage startup is that it doesn’t exist. There is more work to do in a startup than there is time to complete it, which means every second you’re not working increases your chance of failure. This is a daily reality for founders, but the first employees experience it too.
Every hour spent on the startup propels it forward, and since the company is so small, you can actually watch it move infinitesimally forward. This connection between time and progress creates such a tight feedback loop that it’s not uncommon for founders to clock in at multiples above 40-hour work weeks. The environment is wildly productive, and that productivity is addictive.
The results of every hour not spent working are weighed against mountains of progress. This makes it extremely hard to take a day off (let alone a week or more!), even if doing so would be healthy and reenergizing.
Luckily, with success comes revenue, and with revenue comes expanding the team. This gains you the benefit of resource redundancy. Finally, there are colleagues besides you to keep the startup alive when shit hits the fan.
This scenario is not uncommon: a vital team member is absent and everyone scrambles to cover the increased workload. If you’re lucky, the remaining team will have the skills required to complete the missing person’s tasks. This is the often referred to “hit by a bus” factor. It comes in many flavors – someone leaves to start or join another startup; someone hits burnout and jumps ship; someone is involved in an accident.
We’ve experienced this multiple times already at Zapier and the timing is never preferable. Wade, our CEO, had to leave attend his father’s funeral just as a prospective employee arrived from out of town to meet the team. I had to leave without notice to be present at my father-in-law’s funeral during our very first full-team retreat at PyCon 2013. Life happens. Our only path forward during these events was to keep calm, carry on and, yes, work even harder to pick up as much slack as possible.
What steps could we take to minimize the risk of failing to cover all responsibilities during these events? At a certain point, minimizing the risk would introduce diminishing returns. For example, hiring pairs of employees with matched skill sets to have a backup for each role. However, a few basics couldn’t hurt. Some low-hanging fruit:
- Non-simultaneous, planned vacations (someone gets to recharge and the failover gets tested.)
- Familiarity overlap (hire developers conversant in the full-stack and ensure everyone is familiar with support roles.)
- Silo teardown (make vital information available to everyone on the team via documentation.)
I am particularly fascinated by the concept of requiring planned vacations right from the early days. Even just a few days off can help someone recharge, and as long as they truly disconnect (no company Twitter, blog posts, company code commits…), it can test the team’s ability to handle the failover. In fact, this technique reminds me of the Netflix “Chaos Monkey” technique of ensuring robustness in their cloud infrastructure (although a true port would would have someone randomly sent on vacation without notice, but that seems needlessly stressful.)
Everyone Does X
We find that using peer-reviewed pull-requests in GitHub and having on-call “support duty” encourages full-stack familiarity. This goes a long way toward ensuring that code in some corner of the app isn’t left broken because no one remaining knows how to fix it.
It doesn’t stop at code either, it counts doubly so for customer support and bizdev: those relationships can’t be dropped.
Good Silos Make Bad Teams
A frustrating side effect of a division of labor can be artificial lockout. If only one person on the team has ever accessed Stripe or PayPal, it can be tedious trying to track down the proper credentials to login, let alone make sense of it. The same is true for things like credit card information, server credentials, customer information, etc…
We minimize lockout by using project management software and, for less-sensitive data, our private chat room. Being able to search for information you need is a comfort in times of uncertainty.
A Little Slack in the System
With just a little care, its possible to engineer your startup to be more resilient. Then you’ll see, it is a truly great feeling to finally have a little slack in the system.