The Delegation Ledger: What I Stopped Doing This Year

An honest inventory of work I handed off this year — to people, to automation, to AI agents. What each handoff cost up front, and which ones came back.

Abstract line diagram of a single thread splitting into branching paths, representing delegated work
Abstract line diagram of a single thread splitting into branching paths, representing delegated work

I keep a running list of things I no longer do. Not a to-do list in reverse, something closer to a ledger: what left my plate, where it went, what it cost to move it, and whether it stayed gone. I started it because I kept rediscovering the same painful fact. A task I was sure I had delegated in March was somehow back on my calendar by June, wearing a different name.

The ledger format is simple. Task, mechanism, verdict. Mechanism is whichever of three things absorbed the work: a person, a piece of automation, or an AI agent. Verdict is whether the handoff actually compounded, partially returned, or failed outright. Writing the verdict down months later, rather than at the moment of handoff, is the entire point. At the moment of handoff everything looks like a win.

Weekly status assembly

Mechanism: automation, then an agent on top of it. Verdict: compounded.

For years I assembled the weekly view of what shipped by hand. Not because it was hard, but because I was the only one who knew which signals mattered and which were noise. The up-front cost of getting rid of it was maybe two days, spread over a few weeks, spent writing down what I was actually doing when I read a commit log. Not the steps. The judgment. Which repos count as active work versus maintenance, what makes a week look busy but empty, when a spike in output is a good sign and when it means somebody is thrashing.

Once that was written down, most of the assembly became mechanical, and the part that wasn't mechanical became a prompt. This is the pattern I now look for first: the tasks worth delegating are the ones where the difficulty is tacit judgment, and the handoff only works if you extract the judgment instead of the steps.

First-pass review of routine work

Mechanism: AI agents. Verdict: compounded, with a hard ceiling.

A meaningful share of the review work in my day now gets a first pass from an agent before it reaches me. Not the decision, the pass. Catching the obvious, surfacing what's missing, flagging the thing that doesn't match the pattern of the last twenty. The gain isn't that the agent is better than I am at review. It's that I now arrive at the review already oriented, so my attention lands on the one paragraph that matters instead of being spent finding it.

The ceiling is real and I keep hitting it. Anything with a genuine tradeoff in it, where two defensible answers exist and the right one depends on context that lives in my head, does not survive the handoff. It comes back as a confident-sounding recommendation that is wrong in a way that takes longer to diagnose than doing the work myself would have. I've stopped treating that as a tooling problem to solve and started treating it as the boundary.

Scheduling and calendar defence

Mechanism: a person, then rules, then a person again. Verdict: partially returned.

This one embarrasses me. I handed off scheduling, then took back the parts that required saying no, which meant I had handed off the easy half and kept the half that actually cost me anything. Delegation that only moves the mechanical portion of a task and leaves you the judgment portion doesn't reduce load. It adds a coordination step to work you're still doing.

What eventually helped was writing down the decision rule rather than the preference. Not "I don't like meetings in the morning" but "protect the first block after training, and anything under thirty minutes that could be a message gets declined with a specific alternative." A rule can be executed by someone else. A preference can't.

Infrastructure babysitting

Mechanism: automation and monitoring. Verdict: compounded, and it's the cleanest one on the ledger.

Watching for things to break is the ideal candidate for handoff because the judgment is genuinely simple and the cost of a human doing it is disproportionate. The build failed, the process died, the endpoint stopped answering. The only reason this stays on anyone's plate is that setting up the detection feels less urgent than whatever broke last. It's the classic trade: a day of setup against an unbounded number of interruptions.

The pattern underneath

Reading the whole ledger back, the successes have almost nothing to do with who or what took the task. Person, script, or agent, the same thing predicts whether it sticks: did I write down the decision rule, or only the procedure?

Handoffs that included the rule compounded. They kept working when the situation shifted slightly, because whoever held it could reason from the rule instead of matching the example. Handoffs that were only a procedure survived exactly as long as conditions stayed identical, then failed silently and came back to me as an exception, and exceptions have a way of becoming the job again.

The other pattern is about cost. Every one of these handoffs cost more up front than doing the task would have that week, sometimes by a factor of ten. That's not an argument against them. It's the definition of compounding, and it's also why delegation loses to urgency in almost every calendar I've seen, including mine on a bad month. The only defence I've found is the ledger itself: a written record makes it obvious how much of my week is being spent on work I already decided wasn't mine.

If you want the operational side of this — what the week looks like when a large share of routine work runs on always-on agents — I wrote that up separately in An Executive's Week on an AI Agent Fleet. And the reason I think in terms of load rather than output at all comes from training, which I get into in Training Load as a Management System.

More on this pillar: Compounding CEO.

Only 3 slots available this month

Ready to Transform Your AI Strategy?

Get personalized guidance from someone who's led AI initiatives at Adidas, Sweetgreen, and 50+ Fortune 500 projects.

Trusted by leaders at
Google · Amazon · Nike · Adidas · McDonald's