eople love process automation. But, done wrong, it can be disastrous.
Teaching a computer to do a person’s work is all upside, right? It wasn’t for me. I’ll walk you through my experience: why I stopped trying to save my team any time; and the best practices I somehow learned from my freezer.
Don’t Automate to Save Time
I know this feels intuitively wrong. Isn’t this the whole point? I thought it was. Imagine an everyday CRM task, like connecting an Opportunity to a Custom Object for Partner Management and copying over some fields. Say that process takes ~2 minutes to do. On the average day, say each person has to do it 10 times. This type of problem is brought to me frequently. Why wouldn’t it? At that rate, each team member is spending over an hour a week on that task alone. Times the number of team members. Agonizing, mindless busywork!
But doing the math, that agony, while painful, is really only taking ~4% of a 40 hour work week. Here’s what 4% looks like:
More, consider that automating it may only save some of the time spent. A sliver of our tiny green pie piece here. Is there any world where this is the most impactful way to supercharge your day?
Putting it in Context: at best, you’d need a team of at least 25 just to recoup a single headcount in time savings through automation.
One headcount in the context of your burn? Not gonna change the fate of your startup in any meaningful way. Why? Until you’ve seized a good chunk of your market, your company will live and die on the deep risk of bets made against product market fit.
Fear not. Improving operations still matters. And great reasons for automation exist, they just tend to be much more boring:
- preventing human error
- unburdening the team from mentally insulting work
- opportunity cost savings of freeing up headspace
- creating organized, structured data (when otherwise too onerous)
So while time savings shouldn’t be a top level goal, operational efficiency is still the key to repeating successes and preventing churns.
The problem is that Operations at startups is often hastily designed and more importantly, infrequently retired. ‘Standard’ processes are usually the preserved remains of a bunch of half-baked ideas and experiments that never had to fight to survive. Process leftovers.
The Shared Freezer Problem
‘Process leftovers’ remind me of a phenomenon I first observed as a young bachelor, living with 5 other guys, filling up our freezer. “Let’s make Pedialyte ice cubes for hangovers! What about these whiskey stones? Here’s an icepack for my leg. A frozen pizza I might heat up for halftime while watching football this weekend.” Like process, frozen items don’t automatically expire. Put another way, they don’t have to fight to survive. For example, what if:
- We forgot to make the pizza; months later it is covered with freezer burn
- The only roommate who used the whiskey stones moved out
- That leg got better
- Everyone starts wondering what are these yellow ice cubes (ew)
While no longer useful, the items remained. Inevitably, everyone forgot who put what in. In time, the freezer got VERY full. To throw something out, you’d battle concern somebody else wanted it.
We treat process the same way. You need just a 10 minute whiteboard session to put process in place. But a big, expensive, cross-functional, barn burner of a meeting to get rid of it. Know what exacerbates this problem?
Automation.
Process Automation locks in a methodology. Particularly when it takes institutional knowledge to understand it.
Fear of lock-in is the first reason that Process Automation Should Be Obvious. Lock-in is anathema to the modern Product Manager. Iterative design is a core strategy in doing anything new, and that includes operations.
What happens, instead, when we’re locked in? Even if a team leader has the cross-functional alignment to kill their automation, they now also have to ask the technologist who built the automation for them to throw out their work. And if further automation was built on top of the first piece of automation, the technologist can quickly find themselves with their own impossible battle. Which is essentially what was going on in that freezer. It wasn’t worth the effort to get rid of things.
So how did I solve the shared freezer problem? Easy. I got all six roommates together, took everything out of the freezer, and made 2 rules:
- Only put it back if YOU will use it SOON
- Everything else is going in the trash
Only the fit survive, anything without an advocate perishes.
A complete process overhaul is harder at a company, but the lesson remains. Process Automation Should Be Obvious. A bit like instructions or labels on the stuff in the freezer... Let’s toss out that analogy before it spoils.
Process Automation: When and How
So process automation is simultaneously valuable and dangerous. Which situations should you use it for?
Use it to Solve the Right Goals
Here are some good reasons to create Process Automation:
- reducing human error
- creating better data where otherwise not cost effective
- improving your team’s quality of life or bringing clarity to their tasks
Acknowledge that the purpose is one of the above and remember not to let anyone hang their hopes on man hour savings. In fact, you may often actually slow down your team with process automation. How?
“Why is this Opportunity Closed?”
“Why did this Lead get reassigned?”
“I thought you got an email whenever this happens.”
This is the sound of non-obvious Automation, actually slowing a team down. Tracking down the answer (~1 hour?) quickly wipes out many, many cycles of our 2 minute task time savings. When automation eludes or even confuses the user, it often takes huge amounts of time and attention, and a team of people, to resolve. This is now the third example I’ve given for the most important design principle you should be taking away:
Automation Should Be Obvious
Even if you’re solving the right problems (vs a goal of “saving time”), you still may be creating future problems. A good strategy is to mirror real world patterns instead of arbitrary, person-specific whiteboard inventions. The best strategy is to make sure your automation can be described as obvious. Meaning: any person (the work doer, their manager, some random stakeholder) can intuit and explain everything that happens behind the scenes. And as a test, ask them. Yet another Ops philosophy borrowed from the world of product. I’m reminded of the classic book Don’t Make Me Think.
This isn’t hard to do. It’s hard to remember to do, like applying your parking brake on a hill. Make it a habit. Make Process Automation Obvious.
