Stop Automating Your Organizational Dysfunction

I like automating things. If I have to repeat the same task enough times, I will eventually get annoyed and build something to do it for me. That instinct has saved me plenty of time. It has also made me suspicious of how quickly we reach for automation before understanding why the work exists.

Someone describes a process with fourteen steps, three handoffs, and an approval from a person who usually asks somebody else whether it is safe. An engineer hears this and starts thinking about APIs. Which system has a webhook? Can we get a service account? Could an agent fill out the ticket?

Those are useful questions. I have a few others first. Why does the task need fourteen steps? What decision is the approval making? Why are three teams involved in something nobody seems willing to own?

If we skip those questions, we can spend a lot of time making a bad process run more efficiently.

The ticket got faster. The work didn't.

Take a routine request to restart a failed job. Someone opens a ticket. Another team checks the logs. A third team approves the restart. Operations runs it, waits for the result, and closes the request.

It is easy to imagine automating most of that. Create the ticket from an alert, collect the logs, send the approval notification, run the restart, and update the status. Now the process looks impressive in a demo.

But suppose nobody has answered the basic operational questions. Is the job safe to rerun? Did it partially process anything? Will a second attempt create duplicates? Who decides when a failure needs investigation instead of another restart?

We have connected the systems without making the decision any clearer. The person clicking Approve still has to ask around. The engineer still gets pulled into a conversation. The job still waits.

Congratulations. Your confusion now has an SLA.

Automate a decision you can explain

There is nothing wrong with an approval that protects something real. A change to a production database deserves different treatment from restarting a disposable test environment. Permissions, audit trails, and escalation paths matter.

What bothers me is an approval nobody can explain beyond “that's the process.” If the approver always accepts the recommendation of the engineer requesting it, what additional judgment is being applied? If the answer depends entirely on one person's memory, how does wrapping it in a workflow make it repeatable?

Before automating the restart, define when a restart is allowed. Establish whether the job is idempotent. Decide what evidence is needed, what conditions require escalation, and who owns that decision. Then build the automation around those boundaries.

That might produce a very small workflow. Known failure, safe recovery, limited permissions, recorded outcome. Anything outside those conditions goes to a person with enough context and authority to act.

The workflow becomes easier to build because the operational thinking has already happened.

Sometimes the best improvement is deleting a step

Engineers can be strangely reluctant to consider this. We will spend a week integrating two systems before asking whether information needs to move between them at all.

Maybe the second ticket exists because two departments wanted separate reports. Maybe a spreadsheet is tracking something the deployment system already knows. Maybe the weekly handoff exists because nobody agreed which team owns the service after it goes live.

Some of those requirements will survive a closer look. Others will turn out to be habits with infrastructure attached.

If the same information gets copied into three places, find out who uses each copy and for what decision. If nobody uses one, stop producing it. If two teams are checking the same thing, agree on the responsibility before building two automated checks and a reconciliation job between them.

An agent can make that reconciliation job cheaper to write. I would still rather avoid needing it.

Watch where the saved time goes

I want automation to give people time back. That means looking beyond how quickly a script finishes or how many clicks disappeared.

Did the request actually get completed sooner? Are fewer people being interrupted? Can someone other than the original author operate it? When it fails, does the next person know what happened and what to do?

Those questions can expose a disappointing result. We removed ten minutes of manual work from a process that still spends three days waiting for a decision. The script works perfectly. The experience barely changed.

It can also expose a good one. A small change in ownership removes two handoffs. A clear recovery procedure lets the operator act without starting another group chat. Automating that procedure then removes the repetitive work as well.

That is the version I want to build. Understand the work, remove the unnecessary parts, make the decisions explicit, and automate what remains. There will still be plenty of engineering to do. We just won't have to build a platform around a process nobody wanted to question.