Automate what your attention can't change

Some work doesn't care whether you're watching.

The certificate is valid until it isn't. The service is up or down on its own terms, and refreshing the dashboard at 7 a.m. casts no vote in which. You watch anyway, the tab open in your head. The question underneath the watching is the one that matters: whether this is being taken care of without you having to think about it. While you're the one watching, it isn't.

Attention is the one resource you spend without tracking. Compute has a bill. On-call hours show up on a calendar. The hours you lose watching outcomes your attention can't move never land on a bill or a calendar, and that's the budget you run out of first.

Only one kind of work pays attention back

Work splits by what it responds to. A cheap task can demand judgment, and an expensive one can run on a rule you wrote once.

Some work responds to judgment. A failure you've never triaged, a tradeoff with no clean answer, the design call where what you notice changes what you ship. Here attention is the lever: spend more and the outcome improves. This is the work your attention earns a return on.

The rest responds to persistence, or to a rule you can write down. A cert renews before it lapses. A failed batch job re-runs after a transient blip, if it's safe to replay (a half-finished non-idempotent job is judgment work, not a retry). A load balancer drops a backend that stops answering its health check. The result is set by something other than how closely you watch it: a condition you already specified, or another system's behavior. What moves these is a rule firing or another system reacting, not your watching, and a machine never tires of either.

One test tells you whether a thing can run without you: does your attention change the outcome?

If yes, keep it. That's judgment work. If no, you're holding an open loop, and attention spent there is negative ROI.

The claim is easy to state and easy to get wrong, because the whole difficulty lives in the sort. You usually can't classify a task the first time you meet it. You learn whether your watching matters by watching it fail a few times. So the trigger is repetition: the second or third time you catch yourself watching the same loop resolve the same way without you.

The boundary moves: work that needed judgment last quarter becomes a written-down rule once you've root-caused it, and a rule that fit last quarter's traffic can quietly stop fitting. Writing the rule is real judgment work, but you pay it once. The watching is the bill you'd pay forever.

Watching feels like working

That's the trap: staying on top of things reads as responsible. Keep an eye on the deploy. Watch the replica lag. Refresh the dashboard one more time before standup. Each loop is easy to justify on its own, so they pile up and none gets questioned, because the attention cost was never counted.

The cost compounds in one direction. Attention bled on outcome-independent loops is attention missing from the judgment work that needed it. That's the operational shape of alert fatigue: pages that never needed a human hand wearing down the attention left for the page that does. The expensive part shows up later, in the judgment missing when something genuinely ambiguous arrives, because the attention was already spent on things that resolve themselves.

Closing the loop moves the watch to the machine

The effort was never the expensive part. A lagging replica takes a minute to chase; a dashboard takes seconds to refresh. If automation only bought those back, it would barely be worth the build. What it buys back is the open loop, the standing withdrawal you forgot you were paying.

When you automate, the watch moves to the machine, and then something has to watch the machine. Get this half wrong and you come out worse than before. A renewal quietly stops firing while the endpoint keeps serving a cert days from expiry, and all you've done is hide the loop where you can't see it.

A closed loop proves itself on the thing that matters, checked from outside: the cert at the endpoint still has weeks of life, the backends still serving real responses. And the check has to prove its own pulse, because a check that died reads exactly like a system that's fine. Silence proves nothing.

A working loop is one you stop hearing from

A ping that says it worked steals attention even when nothing needs you. You start watching for it, or wondering when it's late. That's what a self-healing job does when it pages you to confirm it recovered: it relocated the withdrawal. An alarm is only half an automation. The work got automated; the watching didn't. You're left listening for the ping, so the loop stays open and the attention is still yours to spend.

The loop is only closed when there's nothing to hold in your head, when the automation stays silent through every case it can handle and draws your attention only on the one it can't. That page is the case the automation couldn't handle. Answering it is two jobs: fix what broke, and, when the case reduces to a rule once you root-cause it, fold it back so it stops reaching you. Skip that second job and the root-causable pages keep coming. The ones with no clean rule to write are the judgment work you keep, not a recurrence to engineer away.

At scale the same shape holds, with one addition. The individual task leaves your attention entirely, and that's the loop doing its job. The automation doesn't, because how often it fires is its own signal: a worker that auto-restarts forty times an hour is a closed loop hiding an unresolved failure. But you don't watch that rate any more than you watched the instances. You bound it too, a page when the restarts cross the line, and you move the line when the traffic moves under it.

The on-call version of all this is sleep. The condition you used to wake for resolves itself, and only two things still reach you: a loop that ran and couldn't recover, and a rate that crossed the line while every instance looked fine.

So start with last week. For every dashboard you opened and page you skimmed out of habit, write down the one condition that had to stay true: the cert valid, the nightly job finished, the dead backend out of rotation. Those are the loops. The ones where your watching never changed whether they held are attention spent casting no vote.

Hand each condition to something that keeps it true on its own and escalates only the case it can't fix. Every loop you close that way is one more thing handled without you, and the attention it returns is the budget that comes up empty at the exact moment the work that needs it walks in.

So before you automate the next thing, before you open that dashboard again, ask what you're really after.

"Is this being taken care of without me having to think about it?"