This was a test of our emergency business operations
Five weeks ago, I had a major surgery. I was physically down for the count for about a week, and mentally fuzzy for at least a week after that. Honestly, I wasn't mentally focused or engaged for several weeks before the surgery either. This is blog-worthy because we run a small business! While Ed and I both "know" everything needed to run the business, we still have a general division of who does what. But after the recent "This is not a Test" of our emergency business operations, Ed knows a little more than he used to. A little more, but not much, and that's a good thing!
Let me back up. As a small business, a common concern among prospective clients is how can a small number of people do all of the work? Said in other ways: who runs the business when we go on vacation or someone gets sick, how can you manage the ongoing workload, how well will the product/service scale, will there be continuous technology updates; you get the picture. There are a lot answers to this, including the fact that we have a large number of consultants with whom we've worked in the past, and can hire at will as needed. But more important than that is the effort we've put into automation, documentation, and disaster planning.
So what is Disaster Planning? Well, when Ed started this as a side business, disaster planning meant grabbing the desktop computer when we evacuated our home for a forest fire. Literally, that happened. And now you know how we became a cloud-based company! So when our house does burn down, we'll have to order more corporate swag, but the business itself all lives online. That was especially convenient when I may or may not have spilled a bottle of water on my work laptop. This also allows us to connect and work from anywhere. Conferences, airplanes, vacations, all those places we don't actually go to right now. But we can, and that's the important part. We also have recovery plans for all of our online services, like what happens if our AWS server crashes? It won't, but we're prepared to restore or rebuild quickly if it ever did.
Automation is something I've talked about before, but it's a great thing to review frequently. Automation saves time in the long term and allows scalability. In the "side business" days, it took Ed 2 days every month to build stats for one client. At that rate, he could only manage 2.5 clients a week, and that would be the only thing he could do. Certainly not a sustainable business model. When we decided to do this full time, the ability to automate was a huge part of that decision, and figuring out to what automate was the real key. We started, not surprisingly, by reviewing what consumed the most amount of time. After that came the "what do I really hate doing" discussion. The final piece of our automation puzzle is one that doesn't get a lot of attention but really does have an impact - finding the tasks where you don't add additional value. One example for me was manually sending invoices each month. Not hard, not time consuming, but easily automated. We'd much rather spend our time building new product features.
Documentation is the last (or first) step of the work we do. When Ed works, he opens a blank document and takes notes on everything he's doing. Those notes eventually become the documentation of what he did, how he did it, how to replicate it, and any issues he solved along the way. When I work, I like to figure things out first and then write up what I did afterwards. We'll often give our documents to each other and say "go do this thing using my document as your instructions".
So how does all this relate to me having surgery? First, all of the automating of our business processes meant there were only a handful of things that Ed even needed to think about or manage. He didn't need to frantically learn a whole bunch of stuff for which I was generally responsible. He had access to all of the documentation I had written explaining those things on our online server. He had access to all the technical systems, project tasks and statuses, and more. He could even monitor my corporate email for issues that couldn't wait for my return. Yes, it helped that this all happened over the holidays when work slows down anyway, but there was still work that had to be done. Like monitoring the data loads, cause data is kind of important to our business. And he did it. Not a single client or prospective client was even aware that there was a problem because, from a business standpoint, there wasn't. And that was a big success.
This concludes our test of the emergency business operations system.