The work that improves the work needs protecting

I came out of a year-end review conversation with a fairly practical conclusion: if I want to improve how I work, I have to reserve time for improving the work itself.

That sounds obvious. In practice, it is one of the easiest things to lose.

I keep a backlog of development work: improving the prompts I use to extract evidence from customer interviews, refining the workflow around customer stories, testing better ways to connect GEO questions to reporting, and working out which parts of an AI-assisted process could actually be useful to somebody other than me.

None of those things usually has tomorrow’s deadline attached to it. There is almost always an article to finish, a stakeholder request to answer, a campaign moving into production or an approval that needs chasing first.

So the delivery work wins, the development work waits, and then another week starts.

Delivery has a built-in advantage

The problem is not that I have been prioritising badly. Delivery is structurally easier to prioritise because its urgency is visible.

A published article is an output. A completed customer story leaves the desk. A campaign deadline has a date and other people waiting on it. Development work is less legible. Improving an evidence prompt today might make the next 20 interviews easier to use, but the value arrives later and is spread across work that has not happened yet.

That makes development unusually vulnerable to the phrase when I get time.

There is another version of this trade-off that I have been seeing in live work. Today I was working on a thought-leadership article built from a customer story. I could have treated the article as the only deliverable: get the structure right, edit the copy, move it towards publication and close the task.

Instead, I was also looking at what the article exposed about the process behind it. What should the reusable thought-leadership prompt ask for? Which parts of the customer evidence need to be surfaced earlier? What instructions would help the next article start from a stronger brief rather than relying on the writer to reconstruct the logic each time?

That makes today’s task take longer. I think that is sometimes the correct trade.

The extra time is not automatically inefficiency. Part of the effort is being spent on the article in front of me; part is being invested in making the next version of the work easier to brief, easier to evidence and less dependent on remembering what worked last time. The important test is whether that second part actually gets reused.

I have been thinking about this alongside a problem I wrote about recently in The problem with knowledge work is how much of it is alive at once. When too much work is active, the rational response is usually to close loops rather than open new ones.

That is still true.

But there is a difference between opening another interesting project and spending deliberate time reducing the friction that keeps recurring inside existing work. If every busy week is solved only by pushing delivery through faster, the system that creates the pressure never gets examined.

You can become extremely efficient at surviving a process you should have improved months ago.

Development work is not the same as innovation

I am wary of calling this innovation time because that makes it sound more glamorous than it is.

The useful work is often quite mundane.

It might mean changing three questions in a customer interview because the existing ones keep producing vague proof. It might mean comparing several completed stories and noticing that the same evidence gap appears every time. It might mean turning a prompt that works when I use it into a briefing tool another writer can actually understand.

It might also mean deciding that something I built does not deserve further development.

That last part matters. Generative AI has made experimentation cheap enough that it is very easy to accumulate prototypes. A workflow can look clever after an hour. An agent can produce an impressive demonstration. A new framework can make messy work feel beautifully organised.

None of those things means the system has improved.

The harder questions come afterwards. Does somebody use it twice? Does it maintain quality when the source material is weak? Does it reduce rework? Does it save enough time to justify the maintenance? Does it survive a real deadline rather than a controlled test?

Development time should exist to answer those questions, not to create an endless side collection of interesting machinery.

AI work especially needs protected time

There is a contradiction in a lot of organisational AI adoption.

People are expected to keep delivering their existing workload while also discovering the workflows that are supposed to transform that workload. In reality, some of the most useful development happens alongside live delivery: you notice the missing instruction because you are writing the article, or the weak evidence question because you are reading the transcript.

That is valuable, but it has a cost. The current task can take longer because you are solving it at two levels at once: producing the output and improving the method that produced it.

The assumption seems to be that this second activity can happen invisibly in the gaps around the first. It cannot always. If organisations want the learning from live work to become reusable capability, some of that additional effort has to be recognised rather than treated as avoidable drag.

Sometimes it can. A useful prompt can emerge while solving a live problem, and I prefer that to inventing theoretical workflows with no real work attached to them. But turning an improvised solution into a repeatable method still takes another kind of attention.

You have to separate what was specific to that task from what is reusable. You have to find the points where the model was confidently wrong, where the human had to intervene, where the source material was not good enough and where a second person would not know what you knew.

That is why I increasingly think the interesting unit of AI-enabled work is not the prompt. It is the designed relationship between evidence, judgement, workflow and output.

I explored some of that in The AI draft is not the article. The point of the workflow was not to generate prose more quickly. It was to preserve the stages where evidence, challenge and authorship still changed the result.

You do not discover those stages simply by asking the model to go faster.

A backlog can hide a decision you have not made

Backlogs are useful because they stop ideas disappearing. They are also very good at allowing us to avoid deciding whether something is genuinely important.

If a development item has been sitting there for three months because live delivery always outranks it, I think there are only two honest possibilities: either it is not important enough to do, or it is important and I have not allocated capacity to it.

Leaving it permanently between those two states is not prioritisation. It is just a soft form of no.

This is the distinction I want to make more explicit in my own work now. A backlog is where I can keep possibilities. Development is work I have actually decided deserves investment.

That means giving it a real place in the week rather than hoping a quiet afternoon appears.

Protecting the time changes the standard

The obvious answer is to block out a few hours. But a calendar block on its own is not much protection.

The harder rule is deciding what the time is for.

I want mine to be for a small number of problems that have already appeared in real work: evidence quality, customer-story workflow, GEO-informed editorial methods, or another repeatable friction point that is costing time or weakening output.

Not five agents because I can build them, not a new framework because I enjoy frameworks, and not general catch-up time with a more strategic label.

The development queue probably needs to stay deliberately small. One evidence problem, one workflow problem and perhaps one discovery or measurement problem is plenty. If something new is more important, something else should leave.

That makes the block accountable. At some point each item should produce a decision: adopt, change, scale, hand off or stop.

There is a legitimate counterargument

Protected development time can become a luxury disguised as strategy.

A writer can spend hours polishing a system that saves five minutes. A team can automate a process that should simply be removed. Someone can build an elaborate internal method while customers are still waiting for the actual work.

That criticism is useful because it gives development time a test.

The work should connect back to delivery.

A better interview method should produce better evidence. A workflow should reduce rework or improve consistency. A GEO method should change a brief, a page or a reporting question. An AI tool should survive contact with another user.

If the development never changes the work, it is probably not development worth protecting.

This is also why I do not want to move away from execution. Staying close to writing, editing, interviews and publication is what reveals where the system fails. The development work should come from that friction and return to it.

The work should compound

The attraction of this kind of time is not that it lets me step away from delivery. It is that a good change can improve multiple future pieces of delivery.

One better customer question can create a stronger case study, a more credible campaign claim, a useful sales proof point and a better source for AI-mediated discovery. One better briefing stage can remove the same misunderstanding from a whole batch of articles. One workflow that genuinely works for another person can free up time without requiring the original designer to become its permanent operator.

That is the kind of compounding I care about. I have argued before that content work needs to compound. The same should be true of the way the work is produced.

Otherwise every week begins too close to zero.

Make improvement part of the job

My practical answer is not dramatic. I am going to protect a small block of time each week for development work and treat it as part of the job rather than something I earn by finishing everything else.

A genuine deadline will occasionally displace it. That is normal. But the response should be to move the time, not quietly delete it until the next quiet week that never arrives.

The bigger change is conceptual: delivery is work, and improving the evidence, systems and methods that make future delivery better is also work.

The second category will rarely shout as loudly as the first. That is exactly why it needs protecting.