Where the time you save actually goes

Thanks for coming back for issue six. This fortnight the same shape turned up in two very different rooms: a proposal conversation with a large financial services board, and a live automation build. Different industries, different stakes, same underlying question: most organisations answer it by accident, not by decision.

The pattern: personal productivity gains get absorbed, not captured

Almost every organisation getting started with AI lands in the same place first. Someone finds a task that used to take two hours and now takes five minutes. It feels like proof the technology works. It usually isn’t proof of anything, because what happens next is where the outcome actually gets decided, and most businesses never make that decision on purpose.

Talking a large financial services board through their AI education day, one framing kept doing the work: there are really three buckets an organisation moves through. Personal productivity: individuals doing their own tasks faster. A use-case roadmap: specific workflows redesigned around the tool. And core-competence transformation: the business itself operating differently because of it. The uncomfortable number is how few organisations ever leave the first bucket. Somewhere around one in a hundred makes it to the third.

The gap between bucket one and bucket three isn’t a capability gap. The AI in both cases is the same AI. The gap is a business decision that either gets made or doesn’t: what happens to the time that just got freed up.

Option one: the time quietly disappears

The default, by far, is that it disappears. A task gets faster, the person doing it absorbs the saving into the rest of their day, and six months later nobody can point to what changed. No one reported it, no one built a business case around it, no one repointed it at anything. The AI project shows up in a slide about “efficiency initiatives” and stays there, forever a personal productivity story, never anything more.

Option two: the time gets pointed at a decision

The other version showed up clearly in a client automation build this fortnight. A freight and logistics distributor had a planner whose load-planning task dropped from roughly two hours to about five minutes once the process was rebuilt around AI. On its own, that’s the same bucket-one story as everyone else’s. What made it different is what the business did with the five minutes: it didn’t quietly get absorbed. It became the stated reason the company didn’t need to hire a third planner to support expansion into two new states. The freed time was explicitly named as the capacity that made the expansion affordable, and that decision was made by someone senior enough to point it somewhere, not left to the planner to notice on their own.

Same technology. Same order of magnitude of time saved. Genuinely different outcome, because one business treated the saving as an answer and the other treated it as a question waiting to be asked.

Why this is a leadership gap, not a technology one

Every organisation I’ve sat down with lately already has the bucket-one wins happening somewhere: a faster report here, a quicker draft there. What almost none of them have is a mechanism for someone above the individual task level to ask, on purpose, “now that this is faster, what does that let us do that we couldn’t before.” Without that question being asked deliberately, by someone with the authority to redirect resourcing, the default is always option one. Efficiency without a decision attached to it just makes the existing way of working slightly quieter. It doesn’t make the business different.

I’ll leave you with the smallest possible version of this same idea. My son had a swim meet a few weeks back, and the event schedule arrived as a few hundred pages of PDF. The easy move would have been to pull out just his heats and move on. Instead I handed Claude the whole thing and said this is unusable, help. Overnight it built an interactive site: his squad’s day laid out as a program, with a live view the coach could update as each race finished. Same principle, much smaller stakes: don’t ask the tool to do the old task faster, ask it what you’re actually trying to get done.