The work should leave something behind

For years, one of the simplest models I have used to understand the health of a technology team has four states: falling behind, treading water, repaying debt and innovating. Will Larson articulated it particularly well.

A team falling behind sees its backlog grow every week. A team treading water gets the important work done but has no room to improve the system. A team repaying debt has finally created enough space to fix the things slowing it down. And an innovating team spends most of its energy on new problems rather than recovering from old ones.

I still think it is a very useful model. But AI has made me question one assumption underneath it.

Capacity was mostly linear.

More work ultimately required more human time. If ten engineers could handle a certain amount of demand, materially more demand generally meant more engineers, fewer priorities or longer queues.

That logic has not disappeared, but it is beginning to change.

Because teams can increasingly turn what they learn into additional capacity. In simple terms, solving something once can make solving the next version of it cheaper.

That changes more than productivity, it changes the economics of the team.

Falling behind is not always a headcount problem

When a team is falling behind, the obvious response is usually some combination of harder prioritisation and more people.

Sometimes that is exactly right.

If the work arriving is genuinely new, ambiguous and full of judgement, excellent people remain the constraint. AI does not remove the need to understand a difficult problem.

But many teams are not drowning entirely in new problems. They are drowning in repetition.

I see this in our own organisation too.

Every new product launch brings familiar work. Product copy needs translating. Another wholesaler needs onboarding. Another marketplace needs connecting. Another application needs integrating. We have plenty of capacity constraints. This is not a story where everything at On has somehow been solved. But increasingly, when I see a team struggling with volume, I try not to immediately accept the premise that the answer is simply more capacity.

Sometimes the workload is telling us something else.

We are repeatedly solving the same shape of problem in the old way.

• Another investigation that looks like the previous ten.
• Another configuration change.
• Another analysis assembled from the same systems.
• Another migration.
• Another implementation that differs in detail but follows a pattern the team already understands.

Once work starts repeating, adding people is no longer the only way to add capacity.

You can start turning what the team already knows into something reusable: instructions, workflows, tools, agents, checks and context that make the next instance cheaper to solve than the first. This is not an argument for skipping the craft. A junior engineer still needs to build the judgement that comes from doing the work, seeing systems fail and learning why apparently simple decisions have consequences. You cannot step back and see the whole if you have never gone deep enough to understand the parts.

That is where things get interesting.

Assisted capacity versus compounding capacity

I think the state AI changes most is treading water.

A team treading water is not failing. Usually it is working incredibly hard.

The important things get done. Incidents get resolved. Deadlines are met. But almost every available hour is consumed keeping things moving.

There is never quite enough space to improve the system creating all that work in the first place.

Historically, the answer was to reduce work in progress, make harder choices and create enough slack to start fixing the underlying problems.

That still matters. But there is now another source of slack.

Stop paying the full human cost for work the organisation already knows how to do.

• If a particular investigation happens every week, should a person still perform every step of it every week?
• If every new service requires the same twenty checks, why are those checks not part of the system?
• If a team repeatedly gathers the same information before making a decision, why does someone have to assemble it from scratch every time?
• If engineers solve the same category of problem again and again, surely the learning from the first ten should change the cost of the eleventh.

This is where I think a lot of organisations are still sprinkling AI rather than rethinking the work.

Give someone a copilot. Help them complete the existing task faster. Celebrate the productivity gain.

Useful….. but still mostly linear.

The person is faster. The organisation is still asking a person to perform essentially the same workflow every time.

There is an important distinction here.

• AI assisted capacity makes people faster.
• Compounding capacity makes repetition cheaper.

The second, I believe, is much more interesting.

Sometimes the right thing to do is stop

There is a difficult human problem here.

When a team is treading water, telling them to rethink how they work can sound almost insulting.

They are already overwhelmed.

Asking them to redesign the system feels like giving them more work.

But sometimes the most valuable thing I can ask a team to do is stop for a day.

A day has rarely killed a project.

Step away from the queue long enough to look at the whole.

• If you are onboarding one integration after another, is there a capability missing that would enable the next ten?
• If you keep resolving the same category of issue, what are the people learning that the system is not?
• If every request appears different, what becomes common when you look one level higher?

A day spent seeing the system differently can sometimes create more capacity than another month spent working harder inside it.

Not everyone finds this easy.

Some of the people I value most have an unusual ability to go deeply into a messy problem, understand it properly, then step back and mentally redraw the whole thing. They see five marketplace integrations in a queue and ask not how to deliver the sixth faster, but what common capability would make the next ten almost routine.

They do not just see the queue. They have this ability to see the system producing the queue.

I increasingly think that kind of curiosity is one of the most valuable capabilities in an AI enabled organisation.

There is a threshold for teams too

I wrote recently about the threshold individuals cross with AI.

Before it, AI is an assistant. You ask it to draft something, analyse something, search something or write some code.

After it, AI becomes a system of execution. You start connecting tools, running work in parallel and keeping human judgement at the points where it actually matters.

I increasingly think teams cross a similar threshold.

Before the threshold, AI makes the people on the team faster.

After it, the team starts converting what it learns into capacity.

• A repeated request becomes a candidate for a reusable flow.
• An exception improves that flow.
• A review exposes another boundary that needs human judgement.
• A mistake strengthens the checks around the next attempt.

Something important has changed.

The team is no longer simply processing work faster. It is learning how not to pay the full human cost of the same class of work again.

What the migration taught me

One experience changed how I think about this quite materially.

We moved a large number of workloads from AWS to Google Cloud.

Migration programmes are traditionally labour intensive. Every application is different enough that someone needs to understand it, but similar enough that much of the work repeats.

We approached ours with a fleet of 15 specialised agents.

What interested me was not simply whether an agent could migrate a service faster than a person.

It was what happened to the learning.

The first services taught us what to look for. The next ones exposed exceptions. Checks became more complete. Patterns became clearer. Understanding accumulated.

Humans still held the important decision points. But the full human learning cost did not need to be paid again for every application.

The work left something behind.

That experience changed my mental model of capacity much more than any benchmark telling me an engineer can code 20 or 30 percent faster.

The same logic applies when a team is repaying debt.

Technical debt is simply the accumulated shortcuts and complexity that gradually make technology harder to change.

A lot of the work involved in removing it contains repetition: migrations, upgrades, standardisation, testing, documentation, finding the same architectural problem across dozens of systems.

Historically, deeply understanding the first instance did not necessarily make instance thirty seven dramatically cheaper.

Now it can.

The first one may still require deep human work.

But if the reasoning, rules, checks and exceptions are captured properly, the next one should require less.

Then less again.

This is where AI starts looking less like additional headcount and more like accumulated organisational knowledge.

Automating the old process is not enough

There is another trap here. We have been automating business processes for decades.

The traditional approach is usually straightforward: observe what a person does manually and reproduce those steps with software.

Someone opens one system, copies some information, checks something in another system and enters a value somewhere else.

So we automate those actions.

RPA took this quite far. It’s been useful, for sure.

But it preserves a dangerous assumption:

that the existing process deserves to survive.

AI gives us an opportunity to ask a more fundamental question.

• Why does this step exist at all?
• Why does this handoff exist?
• Why does somebody assemble this information before making the decision?
• Why are we making the decision at this point in the process?

We are already seeing processes where first principles thinking removes not merely minutes or hours of effort, but days or weeks of elapsed time.

That does not come from automating the existing process better. It comes from being willing to redesign it.

This is why I keep coming back to rethink, don’t sprinkle.

Putting AI on top of an old process may make the old process faster.

The bigger opportunity is discovering that parts of the old process no longer need to exist.

Repetition is a signal

This changes how I look at a backlog too.

A backlog is a queue of things people want. But it is also a record of where the organisation repeatedly spends human intelligence.

That is valuable information.

• If the same request appears twenty times, something is being revealed.
• If the same approval happens every week, something is being revealed.

If people repeatedly gather the same context, copy the same information between systems, perform the same checks or answer the same question, the repetition is telling you where there may be a better way to work.

The question changes from:

How do we get through all of this?

to:

How much of this should we ever have to do this way again?

That is a very different management question.

Start with the flow, not the chatbot

This is why another principle matters to me: flows first, personas second.

The temptation with AI is to start with the interface.

• Give the planner an assistant.
• Give the engineer a copilot.
• Give the marketer an agent.

Then hope useful work emerges. I think that is backwards.

Start with the work.

What happens repeatedly? What information does it require? Where is judgement actually needed? What can safely happen automatically? When should the system stop and ask a person? Who owns the exception?

Only then decide what kind of assistant, agent or interface someone needs.

And it does not need to begin with full autonomy. Often a sensible starting point is an agent working quietly in the background.

• Let it observe.
• Let it assemble context.
• Let it recommend.

Compare its judgement with the team’s. As confidence grows, expand what it is allowed to do.

That is slower than declaring that an agent now owns the process.

But trust should follow evidence.

What becomes more valuable

None of this makes people less important. It changes where scarce human attention is most valuable.

As routine execution becomes cheaper, people can spend more time on what is difficult to encode.

• Judgement.
• Exceptions.
• Ambiguous decisions.
• Understanding what good looks like.
• The boundaries between systems and teams.
• Deciding what may happen automatically and what should remain accountable to a person.

AI makes execution cheaper. It does not make judgement cheaper. If anything, it raises the premium on it.

I wrote recently that leadership exists to own what has no natural owner.

This is another version of the same idea.

A flow can increasingly execute without someone performing every step. Someone still needs to own how that flow connects to everything around it.

The more we encode, the more important those seams become. AI changes technical capacity faster than it changes organisations.

That gap matters.

Not everything compounds

There is an important limit to this idea.

Compounding capacity depends on repetition.

If every problem is genuinely new, if it depends on unusual circumstances, new information, difficult trade offs, politics or judgement nobody has exercised before, there may be very little to encode.

You still need excellent people.

Possibly even more than before.

Because as routine work becomes cheaper, the work left for people becomes increasingly concentrated around the things that are hard.

So one of the simplest questions I now ask about demand is:

Is this recurring work or novel work?

Recurring work is potentially an asset. It is evidence of something the organisation may be able to learn once and reuse.

Novel work remains expensive.

That is exactly where I want great people spending more of their time.

In that sense, AI is not only a capacity strategy.

It is a talent strategy.

Every recurring flow you encode is a choice to spend less human intelligence on something you already understand and more of it on something you do not.

The four states look different now

So I would not throw away the original four states.

I would change how I think about moving through them.

• A team falling behind still needs more effective capacity. But before assuming that means more people, understand how much of the work is genuinely new and how much is recurring.
• A team treading water still needs focus. But it now has another lever: create enough space to step back, find the recurring work consuming its time and redesign it.
• A team repaying debt should not simply fix things faster. Each fix should leave behind rules, context and capability that make the next one easier.
• And a team innovating should not assume innovation is a permanent destination.

Good work creates more opportunities. The challenge is to make sure the organisation’s capacity to learn grows with them.

That is the part I think AI changes most.

The ambition should no longer be simply to move through the cycle faster. It should be to never run exactly the same cycle twice. Every recovery should leave behind more than a cleaner backlog.

It should leave behind better flows, encoded knowledge, stronger interfaces and more leverage than the organisation had before.

Because the interesting promise of AI is not that every person works faster.

It is that the organisation gets better at not paying the full price for what it already knows.

An organisation should not have to solve the same class of problem from scratch twice.

Capacity compounds when knowledge becomes reusable. But getting there requires three things: enough depth to recognise the pattern, enough curiosity to question the existing process, and enough organisational permission to redesign it.