The hidden cost of half-automations
Half-automations create more problems than they solve. Ask: reversible? Automate fast. Not reversible? Map every outcome first. Read: "Everything Starts Out Looking Like a Toy" #268
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: Digital Darwin helps you evolve musical melodies through a fun game where you pick winning sounds. Edition 268 of this newsletter is here - it’s September 15, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ The hidden cost of half-automations
Automations are amazing when they work. They let us respond to a query, route a ticket instantly, or fill in the blanks to make it easier to complete a manual process. These scripts or Zaps save so many clicks, most data instantly, and respond when we're sleeping. A task that formerly took 10 minutes might now only take 25-30 seconds. Add an LLM step to your automation and you're now only limited in what you can imagine.
That sounds like a win (and it often is). But it's also a misdirection. Automations don't only change the way that we do the work we're doing, but also accelerate it. That means they accomplish the twin goals of getting more work done and finding the next bottleneck. When you speed up the process, you finish tasks (yay) and find new problems.
Since we're rushing toward task completion, the most important question isn't "should we automate this?" but "is this decision reversible?" Jeff Bezos has famously called these decisions "Door 1" and "Door 2" decisions. If you know you're making a reversible decision, delaying makes no sense. Even if you're wrong, you'll learn a lot more by upping your decision reps.
Here’s one way to think about this question.
Door 1: decisions are reversible
Let's talk about the key differences between "get it done" and "we need to think about it" decisions. If decisions are reversible, you need to be relentless. Automate the handoff, the alert, the data entry. Ship quickly, see what breaks, and fix it. Each shortcut you add makes the next bottleneck visible.
Take something as simple as routing an ops request. You can set up an automation that creates a JIRA ticket when someone fills out a form. That's reversible — if the ticket goes to the wrong queue, you can move it later.
On the surface, this seems like a great solution. Ops requests are automatically sent to the right team. Whether you classify these requests based on a simple method or something more complicated, the end result is an ops ticket created for the request.
But once you run this automation, you'll discover the real bottleneck. You didn't collect enough information up front to triage effectively. Now you're back to humans chasing context. The solution is the next automation: a smarter form that does discovery before the ticket ever lands. The first automation didn't get everything done, and it revealed the next weak point.
If you stop at the first automation, you create a new problem, and one that's potentially harder to diagnose. Don't be lulled to sleep when your initial automation solves the problem by routing questions to the right person but stacks up the questions for a resource not staffed to triage those questions.
When the stakes are higher with each decision, you need to handle things differently.
Door 2: non-reversible decisions need extra checks
Non-reversible automations are different. These are the cases where you can't undo the action once it's completed, or there is a specific counter-procedure that needs to be completed. When you move money, process payroll, submit compliance filings, or send messages, "ship it and see" can be reckless. You need to know all of the possible states in your journey before you automate the outcomes.
Imagine automating a process like payroll disbursement.
Some of the possible states include:
Payment Success: funds transfer correctly.
Request Timeout: the API call never returns.
Payroll Error: the bank rejects the transfer.
Unknown Result: the system responds with an indeterminate status.
Payroll Blocked: insufficient funds or regulatory hold.
What does this mean for automation? It means you need to consider the individual states of "non-reversible decisions" as separate automations that you also have to build and handle to call your automation suite well formed.
Understanding the state machine
What are all of the possible outcomes and how do you handle them?
Perhaps you need a step or a tool to retry your payroll if you get a timeout or an error. Maybe you need the method to escalate in certain situations. Or a way to summarize information for a human (or bot) review. Or an alert when the source account has insufficient funds. Only after you've covered the exception paths do you have something resilient enough to run safely.
This is the hidden cost of half-automations: the false sense of completion. Teams automate one step, stop iterating, and lock themselves into a treadmill of shadow work. Instead of reducing effort, they shift it to babysitting brittle systems.
The real power comes when you treat automations as stepping stones. Each one buys you speed. Each one points to the next bottleneck. Each one pushes the system toward resilience. Used this way, half-automations compound. Used carelessly, they multiply your problems.
The test is simple:
Reversible? Automate and keep going.
Not reversible? Enumerate the states, handle the exceptions, and only then automate.
Half-automations don't eliminate bottlenecks. They accelerate them. The question is whether you're turning that acceleration into progress, or just running faster into walls.
What's the takeaway? Before automating, ask: 'Is this reversible?' If yes, automate fast and iterate. If no, map every possible outcome first. Half-automations create more problems than they solve.
Links for Reading and Sharing
These are links that caught my 👀
1/ Do you believe this link? - ChatGPT is the biggest culprit of “makes up URLs that don’t exist”
2/ Making code easier to read - the secret value of “vibe coding” for most people might be “explain this code to me.”
3/ Animal Crossing LLM - Here’s an interesting cottage industry in retrofitting LLMs to existing games and applications. This “integration” adds an LLM to GameCube Animal Crossing, and the results are … interesting.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon