Programming Humans | Customers, Etc.
Between fully automated and fully manual is manual-but-easily-repeatable.
I’m actively looking for work. Do you know someone I should talk to or a company I should consider?
Say you work at a small startup and each month you have to cobble together a report about the health of customers. “This should be automated” is your first thought. And it should be, except that your company has cobbled together a handful of legacy systems in its short life and hasn’t quite gotten around to paying off the technical debt of yesteryear. The customer database is clean-ish but doesn’t handle the edge case when a large customer needs multiple product accounts; the product usage data is in some web analytics tool that the developers haven’t yet integrated into the data pipeline1; and the billing system looks like it was written by an intern who has long since left.
Sticking with the “this should be automated” theme, you sit down with one of the engineers to map out a solution. She’s excited to get started and also agrees: “this should be automated.” But as you get deep into mapping out the problem, you both realize that while the connections between the systems are relatively simple, real effort will in fact be required and it’s going to be more than a few hours worth of work. Maybe this could be prioritized next quarter? Hrmph.
What do you do when an important process can’t be fully automated?
Fully manual
One option is to give the task to Bob. Bob’s relatively new and is eager to take on more responsibility. You tell Bob to make a report each month of customer health and he does it. You don’t really care how he does it, as long as it’s a good report and he has it done by the 10th of the month.
One month Bob goes on vacation at the beginning of the month. He’s not sure he’ll be able to get the report done in time when he gets back so he asks if it can be a few days late. You wonder if someone else might be able to run the report while Bob is out. “There are a lot of manual steps”, Bob says. “That’s Bob’s job—isn’t a manual process?”, other people say. You wonder if Bob likes being the only person who can run the customer health report.
I suspect there are a lot of Bobs out in the world with systematic tasks just embedded in their brain. Nothing is written down, but each day/week/month, the task gets done and nobody asks questions. It’s only a problem if they leave and you’re not really worried about that right now.
Programming myself
I’ve never considered myself to be particularly “good” at tasks that need to be repeated on a periodic basis. I’ll go deep on a problem, produce work I’m proud of, and then if I’m asked to do it again, I’ll try to remember how to work through the motions again and curse myself for having to figure it out all over again. I don’t know how the Bobs of the world keep it all in their head. Trying to keep it all in my head would drive me insane.
If I have a somewhat complex process that needs to be repeated, I have to write it down. I’ll start with a doc in whatever system my workplace is using and just start making a numbered list. “Open this table in the database.” “Run this query.” “Add this column to Google Sheets”2. I try to write down every single step and leave nothing to memory. The next time I do this process, I want to follow the script without having to think about it. I can anticipate the frustration I’ll feel if I skip an important step, so I work really hard to make sure there’s a really tight flow from beginning to end. When it works well, the manual steps start to feel a little less manual.
Documenting processes extensively, even if I’m the only one doing them, has the wonderful side benefit of making processes able to be handed off. One of the last projects I worked on at Saltbox was a monthly customer pulse check email. It was one of those not-quite-ready-to-be-fully-automated processes that needed to be run every month. I had a lot of fun working on the project. Although one of the deliverables was sending the first pulse email to customers, the real deliverable was the documentation.
To automate or not to automate
Startups are naturally going to try to automate as much as they possibly can. They don’t have enough people to do everything that needs to be done. They have to automate. Tools like Zapier can help a lot with automation, but there are always processes that are going to require some manual work.
One thing that’s going to be quickly obvious is that it doesn’t always make sense to spend precious developer time automating business processes. Almost always you want your developers working on tasks that are meaningful and visible to customers, not just internally at the business. There are of course times where these tasks are meaningful to both customers and the business and thus rise in importance, but a lot of business processes aren’t at that level, even if they are important.
This is where “programming humans” with documentation comes in. You’re not going to be able to automate everything. But by being diligent and rigorous with your manual processes, you set yourself up to be able to repeat processes in the future, maybe even hand them off. For a startup that counts among its goals “growth” and “scale”, being able to program humans is a critical skill.
As I was coming up with this example, I realized I was describing FullStory, where I worked for five years. Exporting data out of FullStory was historically always a challenge but has gotten much better in recent years.
The Google Sheets example brings up another important point, namely, that if you have the technical capability to embed a step into the process, you’ll always prefer to do that rather than make it an actual step. So instead of having a step to “add a column to the spreadsheet”, you might figure out a way to paste the data into a spreadsheet that automatically gets referenced in a different sheet that already has all the columns you would have needed to have added manually.