I build automation for a living, so people are sometimes surprised by how much my team does by hand on purpose. We deploy with a human pressing the button. We review certain data changes manually. We answer some support tickets one at a time.
None of this is because we can't automate it. We ran the math, and manual won.
Automation has a fixed cost you pay forever
An automated process isn't free once it's written. It's a thing you now own. It breaks when the API it calls changes. It does the wrong thing confidently when an assumption shifts under it. It needs monitoring, and the monitoring needs maintaining too.
For a task you run a hundred times a day, that ongoing cost is obviously worth it. For a task you do twice a month, you can easily spend more engineering time maintaining the automation than you'd ever spend just doing the task. The break-even point is real, and a lot of automation sits on the wrong side of it.
I got this wrong early on. I automated our monthly report generation, a job that took maybe twenty minutes by hand. The script worked for four months, then a data source changed its format and it quietly produced a wrong number that went into a client deck. Fixing it, and rebuilding trust in that report, cost far more than years of doing it by hand would have.
The line I watch for: judgment
The clearest signal that something shouldn't be fully automated is when it needs judgment that changes case by case.
Deploying to production is a good example. The mechanical steps are easy to script, and we do script them. But deciding whether to deploy right now, with these changes, given whatever else is going on, is judgment. So the pipeline is automated and the trigger is a person. That person isn't doing toil. They're doing the one part that's actually hard.
There's a softer version of this in support. Canned responses and routing, fine, automate all of it. But the ticket where a customer is upset and the situation is ambiguous is exactly where a templated reply does the most damage. We send that to a human on purpose, because the cost of getting it wrong dwarfs the minutes saved.
At Shanti Infosoft we draw the line at exactly that spot. Automate the mechanical steps, keep a human on the decision. The failures I've seen from over-automation almost always trace back to scripting away a judgment call that quietly needed a brain.
Manual first, automate what hurts
Our default for a new process is to do it by hand a few times before writing a single line of automation. This feels slow, and it is, but it buys two things.
It shows you what the process actually is, including the messy parts you'd never predict from a whiteboard. And it tells you whether the task is even stable enough to automate, or whether it's still changing every time you touch it. Automating a moving target just bakes today's version of the mess into code.
If a manual task starts to hurt, if it's frequent and repetitive and the steps have stopped changing, that's when automation earns its place. Pain plus stability, not novelty, is the trigger. We automate the things that have proven they deserve it.
We put actual numbers on that trade-off in the automation bill nobody quotes you on.
What's something your team automated that you'd honestly be better off doing by hand?
Top comments (0)