Automate the Gathering, Not the Judgment

I have a recurring task: every week, a pile of exported spreadsheets arrives and has to be turned into something actionable. The obvious move is “automate it.” The useful question is which part. After doing it enough times, I landed on a split I now reach for with any recurring analysis: automate the gathering — the parsing, correlating, formatting, diffing — completely and mercilessly, and deliberately keep the judgment call human. The machine is great at assembling the picture and bad at deciding what it means. Play to both.

Tedious-and-mechanical is exactly what to automate

The gathering half of this task is everything a human is bad at: read several spreadsheets in slightly different shapes, normalize them, cross-reference one view against another, compute how long each item has been around, diff this week against last week. It’s high-volume, error-prone, mind-numbing, and utterly deterministic. Done by hand it eats hours and you still make mistakes — miscount a column, miss that an item carried over, fat-finger a total.

That’s the sweet spot for automation: well-defined, repetitive, no judgment required, and more accurate done by machine than by a tired human at the end of the week. So that whole half got handed to a script that ingests the exports and emits the assembled views — per item, per category, historical carryover, what’s new, what dropped off. The boring, exacting work that humans do worst is precisely what the computer does best.

Automate the part that’s tedious and mechanical. Keep the part that’s consequential and contextual. The skill is telling them apart.

Judgment needs context the machine doesn’t have

The other half is deciding what to do about the assembled picture, and that’s where I stop automating on purpose. Prioritizing, deciding what’s genuinely urgent versus already-handled, judging an edge case, choosing how to respond — those decisions depend on context the data doesn’t carry: what’s actually exposed, what’s already been accepted as a known risk, what matters to the people involved this week.

Hand that judgment to automation and it goes wrong in confident, plausible ways — it doesn’t know what it doesn’t know, and a tired human at least feels the uncertainty. So the design keeps the human in the decision seat: the tool assembles the evidence and lays it out clearly; the person reads it and makes the call. The automation removes the toil so the human’s scarce attention is spent entirely on the part that actually needs a brain. That’s the trade — machine does the volume, human does the meaning.

Design the output around the decision

A report is only as good as the action it enables, so the assembled output should be shaped around the judgment it feeds, not just a data dump. Mine leads with the genuinely urgent category first, separates “new this week” from “carried over,” and surfaces what’s already dispositioned so the human isn’t re-deciding settled questions. The structure does the pre-chewing; the human does the deciding.

That ordering matters because attention is the scarce resource. If the output buried the three things that need a decision under three hundred that don’t, the automation would have saved typing and wasted the thing that actually costs money — the analyst’s focus. Gather everything, but present it in the order a human needs to act on it. The format is part of the automation’s job, not an afterthought.

Make it read-only and idempotent

Two properties make this kind of gathering tool safe to lean on. It’s read-only against the source data — it never mutates the inputs, only reads and emits — so running it can’t make anything worse and you can run it freely. And it’s idempotent: run it twice on the same inputs, get the same output. No “oops, ran it twice, now the numbers are doubled.”

Those two properties turn the tool from something you run nervously into something you run reflexively, which is exactly the relationship you want with a tool you depend on weekly. A gathering step that can’t damage anything and always produces the same result for the same input is one you stop thinking about — it just runs and the picture appears. (And keeping the history it diffs against is what makes “what changed since last week?” answer itself.)

Expect the inputs to drift, and absorb it

A practical reality of automating around data other people produce: the format will change out from under you — a renamed column, a reordered sheet, a new export tool. Brittle automation breaks on the first drift and erodes the trust that made it worth building. So the gathering tool detects fields by name rather than by fixed position, tolerates reordering, and is built so adapting to a new shape is a small, localized edit rather than a rewrite.

That resilience is what lets the automation survive contact with a messy, evolving real world. The human-judgment half, meanwhile, doesn’t care about column order at all — it just consumes the clean picture the gathering produced. Which is the whole elegant point of the split: insulate the human from the mess and from the toil, and reserve their scarce, valuable judgment for the decisions that genuinely need it. It’s the same human-in-the-loop philosophy that runs through the AI automation lab and automation needing a panic button — let the machine do the volume, keep the human on the call that matters. If you’ve drawn this line in your own workflows, I’d love to hear where you put it.