Every scaling team develops the same reflex: if a human does it more than twice, write a script. It makes sense. Repetition is expensive. People make mistakes. Computers don't get bored.
But we've learned — sometimes painfully — that not every manual process is a problem waiting for a solution. Some of them are load-bearing walls. Remove them and the house looks the same for a while, right up until it doesn't.
This post describes how we decide what stays manual.
Before we automate anything, we ask one question: Does this task's friction produce information we'd lose?
Friction sounds like waste. Usually it is. But some friction is signal. A human reviewing a deployment checklist might catch config drift that an automated pipeline would sail past. A person reading a cancellation request might notice a pattern that a status code never captures.
When friction forces someone to look at reality — actually look at it — removing it doesn't save time. It hides problems.
We sort recurring tasks into three buckets. The buckets aren't permanent. Work migrates between them as the team and product change.
Automate now. The task is well-defined, the inputs are predictable, and no judgment is required. Data backups. Certificate renewals. Scheduled reports. Nobody gets smarter doing these by hand. Automate them and move on.
Automate later. The task is repetitive but still evolving. The rules aren't stable yet. Automate too early and you bake in assumptions you'll rip out in three months. Worse, you stop examining those assumptions because the script handles it. We leave these manual and revisit quarterly.
Keep manual. The task is the point of contact between your team and a real outcome. Automating it would sever a feedback loop. These stay human on purpose.
The third bucket surprises people. It's where the interesting decisions live.
A few patterns we've identified:
Quality gates where context matters. Some checks aren't pass/fail. They require someone to hold two pieces of context — what the customer asked for and what we actually shipped — and judge the gap. An automated test can verify that a feature works. It can't verify that it solves the right problem.
Context handoffs between teams. When work moves from one group to another, a manual handoff forces a conversation. That conversation surfaces assumptions. "Wait, I thought the customer wanted X, not Y" is a sentence that saves weeks of rework. A ticket moving through an automated workflow doesn't produce that sentence.
Anything that puts you in direct contact with customer pain. We still have a human read every cancellation reason. We could categorize them automatically. We've chosen not to. Reading raw feedback in someone's own words produces a different quality of understanding than scanning a pie chart of categories. The discomfort is the point.
There's a specific failure mode we watch for: comfortable blindness.
You automate a process. It runs without complaint. Months pass. Then something shifts — a customer segment changes, a dependency updates, a market condition moves — and the automated process keeps running its old logic. Nobody notices because nobody looks. The alert thresholds are stale. The dashboard is green. Everything is fine until it very much isn't.
Automation ROI turns negative when it prevents you from feeling problems at the speed you need to respond. Saving four hours a week means nothing if the thing you stopped watching costs you a customer or a quarter.
When someone proposes automating a task, we run it through three filters:
If a task passes all three — nobody needs to look, the rules are stable, and no learning comes from the work — automate it immediately. Don't hesitate.
If it fails even one, slow down.
Engineers are trained to eliminate toil. That instinct is mostly right. But "mostly right" and "always right" are different things, and the gap between them is where operational judgment lives.
The best-run teams we've seen share a trait: they're deliberate about what they automate and equally deliberate about what they don't. They treat some manual work not as a backlog item waiting for its turn, but as a practice — something that keeps them close to the system and close to the customer.
Not every repetitive task is waste. Some of it is the work itself.
Be the first to comment.
0 comments
Loading comments...