Why does automation so often make things worse?
Because it is usually added, not designed. A zap here, a script there, a bot someone set up during a quiet week. Each piece works; the collection becomes an unmapped machine nobody fully understands. When something misfires — a double-sent invoice, a task created in the wrong project — diagnosing it means archaeology.
Automation chaos is not a tooling problem. It is what happens when automation grows without a map, an owner, or a boundary between what machines decide and what humans decide.
What should you automate first?
The boring, frequent, low-judgment work. The weekly report assembled by copy-paste. The intake details retyped from email into the CRM. The document generated from the same template every time. The follow-up that everyone means to send and half of everyone forgets.
A useful test for any candidate task: if a competent new hire could do it correctly on day one with a checklist, it is probably automatable. If it requires knowing the customer, reading a situation, or making a trade-off — it stays human, and the automation’s job is to deliver everything that human needs in one place.
How do you keep humans in the loop without losing the speed?
The pattern that works is draft-and-approve. The system prepares the document, the reply, the task list, the report — a human glances, adjusts, and approves. The human cost drops from thirty minutes of assembly to thirty seconds of judgment, and nothing external leaves the building unreviewed until the system has earned that trust on evidence.
Approval gates are not a temporary training-wheels phase to be removed as fast as possible. For anything touching money, promises, or reputation, they are a permanent design feature.
What does a disciplined automation sprint look like?
- Map — document the recurring tasks and handoffs honestly, including the exceptions everyone works around.
- Pick one — the single most painful, most frequent slice. Not five things. One.
- Design the fallback first — what happens when the automation is unsure, fails, or meets an edge case.
- Build on your actual tools — the stack you have, not a new platform to migrate onto.
- Document and hand over — an automation without an owner and a one-page runbook is a future outage.
When is automation the wrong answer?
When the process itself is broken. Automating a confused workflow produces confusion at machine speed. If two people currently do the same task differently and argue about whose way is right, that argument has to be settled by design before any tool touches it. Sometimes the diagnostic’s most valuable output is "fix the process; skip the software."