“Let’s Just Do It Manually”: A Love Letter to Technical Debt
There’s a special place in my heart for those five words. Right next to “the build works on my machine” and “we’ll document it later.”
I’ve heard “let’s just do it manually” in every company I’ve worked at. Start-ups, enterprises, agencies managing infrastructure for 70,000 users. The words are always the same. The reasoning is always wrong.
The Seductive Lie
Manual processes feel productive. You’re doing something. You’re making progress. You can see immediate results. There’s even a certain satisfaction in executing a complex series of steps perfectly.
This is a trap.
What feels like productivity is actually you being the automation. You’re the script. You’re the orchestration layer. You’re the error handling. Except you’re an expensive, unreliable, non-scalable version that needs sleep and gets distracted and occasionally fat-fingers commands in production.
Every time you execute a manual process, you’re burning money and building fragility into your systems. You’re just doing it slowly enough that nobody notices until it’s too late.
The Meeting That Haunts Me
I once sat in a meeting where we discussed deploying configuration changes across our Kubernetes clusters. The proposal was straightforward: build a GitOps workflow with automated validation and rollback. Investment: maybe a week of work.
The pushback was immediate. “That’s overengineering. We only update configs a few times a quarter. Let’s just do it manually.”
Six months later, a manual configuration change took down production for three hours. The person making the change missed a single line in a YAML file. No validation, no testing, no easy rollback. Just a frantic scramble to figure out what changed and how to revert it.
The post-mortem was enlightening. The “few times a quarter” was actually 47 manual changes over six months. Each one took between 20 minutes and two hours. Each one carried risk. Each one required coordination and scheduling because we needed the right person available.
We’d spent roughly 60 hours on manual config changes, created dozens of potential failure points, and eventually paid for it with a production outage. That week of automation investment was looking pretty good in hindsight.
The Toil Tax
Google’s SRE book talks about toil: work that’s manual, repetitive, automatable, tactical, lacking enduring value, and scales linearly with service growth.
Every manual process is toil. And toil is a tax on your team.
Think about what happens when you have too much toil. Your best engineers leave because they’re bored. Your team can’t take on new projects because they’re too busy with maintenance. Your on-call rotation becomes miserable because there’s always something that needs manual intervention. Your hiring conversations are awkward because you’re selling smart people on doing repetitive work.
I’ve watched talented platform engineers quit because they spent more time running through runbooks than building platforms. These were people who could have been designing resilient architectures, implementing zero trust networks, or building self-service tools. Instead, they were human cron jobs.
The worst part? Management often sees these people as productive. They’re always busy! They’re always fixing things! They’re clearly valuable!
They’re clearly burning out.
The Illusion of Control
Here’s what people tell me: “Manual processes give us control. Automation can go wrong.”
This is backwards.
Manual processes give you the illusion of control. You feel in charge because you’re making decisions in real-time. But you’re actually introducing variables: human fatigue, human error, human judgment under pressure, human availability.
Automation gives you actual control. You define the process once. You test it thoroughly. You handle edge cases explicitly. You version it. You review it. You audit it. Then it runs the same way every single time.
Yes, automation can go wrong. Know what goes wrong more often? Humans executing complex procedures at 2am after being paged out of bed.
The Kubernetes Incident
I’ll tell you about one of my favourites. We had a process for scaling our EKS node groups. It involved updating Terraform, applying the changes, waiting for nodes to come up, and then cordoning and draining old nodes in a specific sequence to avoid disrupting workloads.
The runbook was eight pages long.
Someone suggested automating it. The response: “It’s too complex to automate safely. Let’s just do it manually.”
So we did it manually. For months. Different people each time because we didn’t want to create a single point of failure. Which meant everyone needed to understand that eight-page runbook.
Then one day someone missed step 6b. They drained nodes before the new ones were fully ready. Half our production workloads went down. Not completely down, but degraded enough that customers noticed.
The fix? We automated the entire process. Took three days to build properly. Now it runs in minutes, validates every step, and has never caused an outage.
That eight-page runbook? We deleted it. Good riddance.
The Compliance Horror Show
If you work in regulated industries, manual processes are terrifying.
SOC 2 Type II compliance requires audit trails. Manual processes require people to remember to log what they did. How’d you like to bet your compliance certification on people remembering to update a spreadsheet?
GDPR requires you to know what data you have and where it is. Manual database operations make this nearly impossible to track accurately.
Every compliance framework I’ve worked with assumes automated, auditable processes. They’re designed around the idea that systems enforce policies, not humans trying to remember policies.
When auditors ask “how do you ensure least privilege access?” and your answer is “we train people to be careful,” you’re going to have a bad time.
The Startup Delusion
Start-ups are the worst offenders. I get it. You’re moving fast. You’re trying to find product-market fit. You don’t have time to build proper automation.
Except this is exactly when you need automation most.
Start-ups have tiny teams. Every hour someone spends on manual deployments is an hour they’re not spending on features. Every production issue caused by manual errors is time you’re not spending talking to customers.
I’ve seen start-ups where the founders spent 10 hours a week on manual infrastructure tasks. These people were trying to build a company while simultaneously being their own operations team. It was madness.
The fastest-moving start-ups I’ve worked with had automation from day one. Not perfect automation. Not comprehensive automation. But enough that deployments were one command, environments were reproducible, and nobody was SSH-ing into servers to debug issues.
They moved faster because they weren’t constantly firefighting their own infrastructure.
The Breaking Point
Here’s how the manual process death spiral works:
First, you do something manually once. It’s fine. It’s quick. No problem.
Then you do it manually a few more times. Still fine. You’ve got the hang of it.
Then someone else needs to do it. Now you need to document it. But you’re busy, so you give them a quick verbal explanation. They miss some details. Something breaks. You fix it and write a quick runbook.
Then someone else needs to do it. They follow the runbook, but it’s slightly out of date because the process evolved. Something breaks differently. You update the runbook.
Then you need to do it at 3am. You’re tired. You miss a step. Production breaks. You fix it, update the runbook again, and add a checklist.
Then someone new joins the team. They need to learn the process. Training takes three hours. They’re nervous about running it themselves. They ask you to pair with them the first few times.
Then you realize you’re spending two days a month on this one manual process, there are seven other manual processes just like it, and you’ve spent so much time on runbooks and training that automation would have paid for itself ten times over.
That’s when you finally automate it.
The Real Question
When someone says “let’s just do it manually,” the question isn’t “is automation worth it?”
The question is: “why are we even discussing this?”
Automation should be the default assumption. The question should be “is there a compelling reason NOT to automate this?” And the bar for “compelling reason” should be high.
Because here’s the truth: in 20 years of doing this work, I’ve almost never seen a team regret automating something. But I’ve seen countless teams regret not automating sooner.
What Automation Actually Means
When I say “automate,” I don’t mean write a brittle bash script that only you understand. I don’t mean create a complex system that requires a PhD to maintain.
I mean build reliable, maintainable systems that encode your operational knowledge. Use infrastructure as code. Implement GitOps workflows. Build self-service platforms. Create clear abstractions that make the right thing easy and the wrong thing hard.
Good automation doesn’t just eliminate manual work. It makes systems better. It forces you to think clearly about processes. It creates audit trails. It enables self-service. It distributes knowledge across the team.
Manual processes keep knowledge in people’s heads. Automation puts knowledge in systems where everyone can access it.
The Path Forward
Stop saying “let’s just do it manually.”
Start saying “how do we automate this?”
Track your toil. Measure it. Make it visible. You’ll be horrified at how much time you’re wasting.
Automate aggressively. Every manual process is a liability. Every automation is an investment that compounds.
Build platforms that make manual work impossible. Don’t just automate tasks; design systems where manual intervention isn’t needed.
And for the love of everything holy, stop treating automation as a luxury that you’ll get to “when you have time.”
You don’t have time precisely because you haven’t automated.
Fix that.