In a startup, we often end up doing things manually that are automatable. Engineers sometimes find such tasks distasteful.
Such tasks may indeed be automated in bigger companies like Amazon. But our startup is not Amazon. We need to do what’s right for us.
Beyond that, why should we embrace manual tasks?
First, in Futurecam, a task needed to be done weekly that took an hour. One of my engineers insisted on automating it. His logic was that the automation will eventually pay for itself. He didn’t even estimate how long it will take to automate. I did, and it may have taken a few person-weeks. This means that this investment takes a couple of years to repay. The startup may be dead by then, if we don’t focus on achieving the goals we need to achieve, even if doing things unoptimally from a long-term perspective. For the long-term to matter, we need to be in the game, which first taking care of the short-term.
Second, an attempt to automate something is effectively a software project, and if there’s one thing common between all software projects, it’s that they can burn up a lot of time and then fail. Or may work technically but turn out to not be valuable to users. As a project manager, such projects are hard to justify, because startups can’t write off such investments the way a Google can.
Third, when you do things manually, you have a complete product today. It can still look to customers as if it’s automated. For example, if your customers should receive a weekly summary email, you can send that email manually, but phrase it as if it were coming from an automated system. This is called the Wizard of Oz technique — it looks magical, but if you look behind the curtain, you’ll find that it’s being done by humans. Your users don’t care how something is being done manually behind the scenes; they’ll be happy that the product is working for them. That’s faster progress.
The alternative is to automate it, taking quarters or years to do it, which means your progress is delayed by years.
If doing it manually takes too much of your time each week, congratulations — you have enough people using your product! That’s a better situation to be in than building wonderful code that no one uses, which is a mistake that too many techies make, including me [1].
Fourth, doing it manually develops empathy for the user, while code is an abstraction. When coding, it’s easy to lose touch with the user and what their pain points are.
Fifth, doing it manually can be much more cost-effective than hiring a team of top-quality engineers, which most founders can’t afford out of their savings. You get funding only after you demonstrate traction, which is a catch-22. Doing things manually is a way to break that cycle.
Sixth, when you do things manually, you can try different variations easily to see what works, either a slight variation or a significantly different approach. An A/B test, except that you can try a dozen rather than just two variants. Manual processes are the most flexible to modify.
Your initial ideas and assumptions will invariably be wrong, so you need to iterate fast and explore a lot of territory. In the initial days, a startup’s goal should be to acquire validated learning.
As a founder, I initially believed that my plan and ideas are right, and focused on execution, but that resulted in executing the wrong plan well, leading to failure. It’s like building a hotel when what you need is an airport. Such hotel will fail no matter how well built. The takeaway isn’t “Well, let’s build an airport.” The problem is that you don’t know ahead of time what you need — an airport? a hotel? a resort? a nightclub? When you don’t know what users want, the only solution is to iterate multiple times. The real takeaway is to not use concrete, because concrete is not malleable. Pour concrete only after you’re sure. Till then, what you need is something quick, like pitching a tent, which can be one in a hundredth the time, cost and manpower as pouring concrete. In startup terms, the equivalent of a tent is a manual process, while the equivalent of concrete is automating it. So don’t automate till you’ve validated what you should be building, in detail.
Seventh, looking down on manual processes is an immature reaction, like looking down on a bicycle. A bicyle is a means to an end — without knowing the end, you can’t determine whether a bicycle is the right tool. Similarly, start from the end, and then figure out whether a manual or an automated process is the right tool for this job.
Eighth, don’t fall into the trap of thinking, “I’m an engineer, so code should be the solution.” Everyone is biased, depending on the lens through which they look at the world, like engineer, designer or marketer. Be aware of this and guard for it.
As Paul Graham said, do things that don’t scale.
[1] Obviously, not all products are amenable to substituting people for code — if you’re building a spreadsheet, you can’t do calculations manually for users!