The problem with knowledge work is how much of it is alive at once

I have been looking at my work list this week and realised that the problem is not really that any one task is unreasonable. It is that too many reasonable things can remain alive at once.

At the moment I have four articles in final production, an advisory board session that should generate new practitioner evidence, a web project moving from copy and wireframes into assets and build, and a customer story that needs one more editorial pass before it goes back into stakeholder review. Behind those are transcripts, GEO questions, video selections and event follow-ups that are useful, but not urgent.

None of those things is absurd on its own. Put them together and the experience changes. Every open piece of work carries its own context, dependencies, files, people and unfinished decisions, so even when I am not actively working on something, some part of my attention is still holding it.

That has made me think that one of the problems with modern knowledge work is not simply workload. It is concurrency.

The work can be reasonable and the system can still be overloaded

When we talk about being busy, the usual instinct is to count tasks or hours. But two weeks containing the same amount of work can feel completely different depending on how much of that work is simultaneously active.

One project can be waiting for feedback. Another is waiting for an asset. A third has evidence that still needs to be checked. A fourth has reached the point where somebody else needs a clean handoff. None of these may require action this minute, but each remains mentally open.

That is different from simply having a long to-do list. A future task can sit harmlessly in a queue. Work in progress has a carrying cost because it still contains unresolved context.

The more projects remain active, the more frequently you have to reconstruct that context: what did we decide, what was still missing, who owns the next step, what can be published, what needs checking, and what looked important three days ago but no longer is.

That reconstruction work is easy to underestimate because it rarely appears as a deliverable. It is just the tax you pay for having too much work alive at once.

AI makes starting much easier

AI has made this more visible to me because it has removed a lot of the friction that used to slow the beginning of knowledge work.

I can get a first draft quickly. I can interrogate a transcript, compare several documents, generate possible angles, surface evidence gaps, turn notes into a structure and create a credible next-step plan without spending hours on the mechanical parts.

That is genuinely useful. It also creates a new temptation: because starting is cheaper, I can start more.

A new idea no longer has to wait for a spare afternoon. I can test it now. A transcript does not have to sit untouched. I can analyse it now. A possible framework can become a draft immediately. A stakeholder question can become three possible routes before the meeting has even ended.

The cost of exploration has collapsed. The cost of carrying unfinished work has not.

That is the part I think we may be underestimating. AI can increase the rate at which work enters the system faster than it increases the rate at which decisions, approvals and handoffs leave it.

Starting faster is not finishing faster

There is a subtle productivity trap here. If I can create more drafts, analyses and possible actions in the same amount of time, it can look as though my capacity has increased by the same amount.

It has not.

Some bottlenecks remain stubbornly human. Somebody still has to decide which argument is worth making. Evidence still has to be verified. A stakeholder still has to respond. A web producer still needs a usable package. A customer story still needs approval. A piece of work still has to become sufficiently finished that it can leave my desk.

So the productivity question changes. It becomes less about how do I produce more? and more about what should be allowed to remain active?

That is a judgement problem rather than a generation problem.

This week is a delivery week

I can see that fairly clearly in my own workload now. The useful move is not to open another promising research thread. It is to reduce the amount of work in progress.

The advisory board should not become another project. Its evidence should strengthen work that is already underway. The articles need to leave my desk. The web project needs to reach build. The customer story needs to return to stakeholder review.

Then I can look again at what is waiting behind them.

That sounds obvious when written down, but knowledge work has a habit of rewarding expansion. Every interview suggests another angle. Every useful source reveals another question. Every project creates evidence that could support another project. AI makes those connections easier to see, which is valuable, but seeing a connection does not mean acting on it immediately.

Sometimes the best use of intelligence is to leave the connection alone for a week.

Delivery is a form of prioritisation

I used to think of prioritisation mainly as choosing what to start. I am increasingly interested in the other side of it: choosing what to finish.

Finishing creates capacity in a way that merely rearranging a task list does not. A clean handoff removes context from your head. A draft sent for review becomes somebody else’s next action. A build-ready package no longer needs to be mentally maintained as a half-finished production problem.

This does not mean rushing work out of the door. A bad handoff simply pushes the problem downstream. The useful goal is to get something to the point where the next person can actually use it without reconstructing your thinking.

That is also why I am wary of treating AI productivity purely as output volume. A system that generates twice as much intermediate work without improving completion, handoff or decision quality may make everybody busier while appearing more efficient.

The reset matters as much as the sprint

The other part I am trying to protect is what happens after delivery.

A busy period naturally creates follow-up work. Once these pieces move, there will be comments, revisions, new evidence, performance questions and things I deliberately parked. The mistake would be to fill every newly empty space immediately.

There needs to be a revisit point: what actually moved, what came back, what still matters, what can be dropped, and what deserves the next block of attention?

Without that reset, a delivery week just becomes the front end of another delivery week. The queue shrinks briefly and then expands again.

That is probably the operating principle I am testing at the moment:

finish, hand off, revisit.

Not because the work stops. It does not. But because continuous knowledge work still needs boundaries between active work and available work.

AI makes it easier to keep discovering things worth doing. That does not make doing all of them at once a good idea.

The scarce capability may not be productivity in the traditional sense. It may be knowing how much unfinished work the system should be allowed to carry.

That is a different question from how much we can produce. I suspect it is becoming the more important one.