The Best Automation Is Sometimes the One You Don’t Build

I like building things. That makes one question especially useful: what would happen if we solved this without another integration?

Sometimes the answer is a better form, a clearer decision rule, a shared template, or an agreement about who owns the next step. Those changes can remove enough friction that the proposed automation loses its reason to exist. I consider that a successful design outcome.

Automating an unclear process gives it momentum. It can also preserve confusion very efficiently. If two teams disagree about what “complete” means, an event trigger won’t settle the argument. It will carry the disagreement into the next application.

Before building, I want to understand the volume, variability, consequence, and stability of the work. How often does it occur? How much of it follows a repeatable rule? What happens when it goes wrong? How often does the underlying process change?

A hypothetical weekly task illustrates the economics. If it takes twenty minutes, the annual routine effort is about seventeen hours. A custom integration that takes thirty hours to build and another hour each month to maintain has a difficult first-year case on labor savings alone. Those figures are illustrative, but the comparison is worth making before writing code.

There may be other benefits. Automation could prevent costly omissions, improve traceability, shorten a critical delay, or allow work to happen when nobody is available. Those are real possibilities. Put them into the case explicitly rather than hiding them behind an inflated estimate of time saved.

I’d compare at least three paths: simplify the existing process, use a modest assisted workflow, or automate the repeatable portion end to end. An assisted approach might prepare a draft, validate required fields, and gather evidence while leaving a judgment call with the person who owns it.

That middle path is useful when the work has both routine preparation and meaningful exceptions. The machine can do the repetitive part. The person gets a better starting point and remains able to decide. The result should be less total effort, including review and recovery.

My independent projects connect publishing, research, and operational tools. They give me plenty of reasons to appreciate automation—and plenty of reasons to ask whether each connection has earned its maintenance burden. A dependency becomes part of the operation the moment someone relies on it.

I want an exit condition as well as a launch condition. If usage stays low, intervention costs rise, or the process changes beyond the original design, we should reconsider the workflow. Retirement can be a responsible operating decision.

The strongest technology leadership often involves choosing where to spend the team’s attention. Every integration competes for that attention with other work. A small, understandable solution can leave more capacity for the problems that genuinely need engineering.

I’m interested in automation that makes an operation clearer and more capable. When a simpler change achieves the outcome, I’m happy to take the win and leave the extra machinery unbuilt.