AI Didn’t Break Your Operating Model. It Changed Its Clock Speed.

A new bottleneck is appearing in organisations that have started using AI seriously.

Individual output has jumped. People are producing drafts, analyses, designs, scenarios and code faster than they ever have. But producing first-pass work was never the whole job. Reviewing it, judging it, prioritising it, funding it, integrating it and acting on it are different kinds of work — and many of those have not sped up at all.

That is why the gain can feel strangely uncomfortable. Work now arrives at the manager’s desk faster than it can be reviewed, challenged, approved or turned into a decision. Options multiply. Decisions wait. Queues form. And a growing number of managers describe the same feeling: they are not so much managing a team as standing in front of a permanently moving conveyor belt.

The common reading is that this is an AI problem. Either the technology is not mature enough yet, or the organisation has not adopted it well, or managers need to get better at working alongside it.

Plenty of sensible advice follows from that reading: review at a higher altitude, filter the noise, set quality bars, ask people to bring recommendations rather than drafts, use AI to summarise the AI output.

Some of that helps. But it treats the symptom.

The bottleneck is not really a management problem. It is an operating model problem. And AI did not create it. It exposed a problem that was already there, and added a new one on top.

AI changed the economics of attempting work

AI has not simply made existing work faster. It has changed the economics of attempting work.

Things that were previously too expensive, too slow or too effortful to produce are now cheap to generate. A market analysis that once took a week can be drafted in an hour. Ten product variants can appear where previously there would have been two. A business case, customer segmentation, policy note, architecture option or first version of code can be produced before anyone has decided whether it deserves serious attention.

That matters because organisations were not designed for a world in which the cost of producing options collapses.

For years, effort was a natural constraint. If something took time to prepare, people were forced to choose what was worth preparing. The friction of production did some of the prioritisation work. It limited how many options entered the system.

AI removes some of that friction. It makes more things possible to attempt.

So the scarce capacity starts to move. The constraint is no longer only the production of work. It becomes the judgement about which work should exist at all.

That is where much of the new pressure is coming from. Managers are not only reviewing more of the same. They are being asked, often implicitly, to choose between a much larger set of possible things the team might now do.

The work-generation clock has accelerated. The judgement clock has not.

A set of clocks that no longer agree

An operating model is, in part, a set of components running at different speeds, connected by interfaces.

Work generation runs at one speed. Review runs at another. Coordination, decision rights, risk judgement, resource allocation and sign-off each run at others, usually slower.

For years, those differences were manageable because the gap was small enough for people to absorb by hand. Managers chased, sequenced, translated, filtered and nudged things through the system. It looked as though the operating model coped. In fact, people coped.

AI has changed the clock speed of one component: the production of first-pass work.

But the rest of the operating model has not necessarily moved. Prioritisation has not become instant. Risk judgement has not become effortless. Architecture review, legal approval, customer-impact assessment, funding decisions and governance forums still often run on the old cadence.

The interfaces that used to flex around a modest difference in pace are now spanning a much larger one. And the person standing on the interface — usually the manager — is the one holding it together.

The manager is not necessarily the true constraint. They are where the constraint becomes visible.

Two things are happening, not one

It is worth separating two effects, because they call for different responses.

The first is more obvious: more output is moving through interfaces that were never designed for the pace. That is an old flaw being exposed. The mismatch between doing, reviewing and deciding was always there; AI has simply removed the slack that used to hide it.

The second is newer and more demanding: AI has widened what an organisation can attempt.

More customer segments can be analysed. More propositions can be drafted. More scenarios can be modelled. More code can be generated. More internal documents can be produced. More options can be placed on the table.

That sounds like a gain, and often it is. But every new option asks for attention. Some need review. Some need challenge. Some need funding. Some need approval. Some need to be integrated with other work. Some should never have been generated in the first place.

So the manager’s job quietly shifts. They are no longer just supervising work already chosen. They are selecting from a proliferating field of possible work.

In many teams, the default response has been to attempt more.

That is where the real load lands. Not just in the volume of work, but in the judgement about which work is worth doing.

Put the two together and the manager starts to look like the bottleneck. They are the visible point where a fast clock meets a slow one. When the fast side speeds up, the slow side cannot automatically follow, and the work backs up — not evenly, but at the handoffs, and on whoever owns the slowest step.

The chain starts to behave like a queue.

In a product organisation, this might show up as teams producing three times as many concepts, business cases and feature variants, while the forums that vet, fund and prioritise them meet no more often than they did last year.

The visible problem is an overloaded manager. The design problem is that several different decision classes are being routed through the same person and the same approval path.

The right question is not how to clear the queue faster

It is which steps in the queue still need to be there.

A surprising amount of review and sign-off exists out of habit rather than necessity, especially around low-risk or reversible work. It survives because, until now, someone had time to do it. When that time disappears, the honest question is which steps were ever load-bearing, and which can simply go.

The most useful adjustment I have seen managers make is not getting faster at the work. It is getting comfortable deleting steps that were only there because there used to be room for them.

The deeper move is to stop treating all AI-assisted output as the same kind of work.

Some outputs need no review. Some need peer review. Some need managerial judgement. Some need risk, legal, architecture or customer approval. Some need a funding decision. Some need a customer-impact assessment. Some are reversible and local. Some are systemic and hard to unwind. Some should be stopped before they enter the system at all.

If all of those continue to arrive through the same managerial doorway, AI has not made the organisation faster. It has made the queue longer.

How that work is sorted and routed is an operating model question, not a personal productivity one.

The trap is to speed everything up

The tempting move is to compress all the surrounding steps to match the new pace of first-pass work.

Shorten the review cycle. Squeeze the governance meeting. Push decisions faster. Ask the whole system to run at the speed of AI-assisted production.

This fails, and it fails for a reason worth being precise about.

Some parts of an operating model are slow for good reasons. Some judgement takes time. Some governance should take time. Decisions that are hard to reverse should take time. Safety, ethics, finance integrity, architecture, regulatory assurance and strategic commitment cannot always be accelerated without degrading the quality of what they exist to protect.

Forcing those functions to keep pace with AI-assisted output does not remove the friction. It relocates it — usually onto people — and quietly degrades the decisions themselves.

Faster is not the goal. The goal is to create value, and pace is one of the variables you design to reach it. Running everything as fast as possible is not a strategy. It is the absence of one.

Pace as a design variable

Which points to the actual work.

Rather than asking how managers can keep up, the question is one of design: which parts of the operating model should run at AI’s pace, which legitimately should not, and how the handoffs between them are built.

Start with one overloaded seam.

For two weeks, look at the work arriving there. Then sort it into decision classes.

Which work is low-risk and reversible? Which needs peer review? Which requires managerial judgement? Which has customer, legal, regulatory, financial or architectural consequences? Which decisions allocate scarce resources? Which are strategic commitments? Which are hard to reverse? Which items should not have entered the queue at all?

Then redesign the route for each class.

Move decisions to where they can be made at the right speed. That only works if the point you move them to can actually carry them. Relocate a decision without the authority and the cover to make it, and you do not get speed. You get freeze.

Delete approvals that are not load-bearing. Create guardrails for decisions that can be made locally. Preserve deliberation where the consequences are material, systemic or hard to reverse. Make the sorting of work explicit, rather than leaving every item to fight for attention in the same queue.

The point is not to make every clock faster. It is to make the clocks work together.

This is the heart of what I have been calling Requisite Pace: treating the pace of an organisation not as something to maximise, but as something to design. The wider framework sets out how to do that systematically; this piece is concerned only with the diagnosis at one level.

AI has made that diagnosis harder to ignore.

The same flaw, one floor down and one floor up

It is worth noticing that the manager is not the only place this is happening.

Look down, at the person doing the work. They are absorbing the same mismatch inside their own head: judging, attending, choosing and recovering at human speed while their output runs at machine speed. It shows up as depletion long before anyone calls it a process problem.

There is a quieter cost one level down as well. The drafting and false starts that used to build judgement are increasingly handled by the machine, so the output improves while the path that turns a capable junior into a seasoned one slowly closes. That is its own design problem, and one for a later piece.

Look up, at the board. The same gap is opening between how fast the outside world is moving and how fast strategy is sensed and decided. Customers, competitors, suppliers and technologies are shifting faster than many strategic planning and governance cycles can interpret. A gear behind costs far more there than an overloaded middle manager does locally.

AI is doing at every level what it is doing to the manager. It has not broken the operating model. It has changed the clock speed of some parts of it and widened the choices around all of it. The mismatch this creates was always partly there, and is now partly new. Either way, it can no longer be absorbed by hand.

Speed is not the issue.

Timing is.