Your organisation doesn't have a speed problem. It has a timing problem.

Different speeds are normal. Undesigned interfaces are the problem.

Every leadership team I've worked with in the last five years has, at some point, said a version of the same thing: we need to go faster.

Faster decisions, faster delivery, faster time to value. The language varies, but the diagnosis is consistent. Speed is the problem. Acceleration is the answer.

I think that diagnosis is mostly wrong.

Not because speed doesn't matter - it does. But because the organisations that are genuinely struggling are rarely slow everywhere. They're fast in some places, and slow in others, and nobody has designed how those different speeds fit together. The product team ships in two-week sprints. Architecture reviews happen quarterly. Governance meets monthly. Vendor contracts lock in for three years. Commercial teams make promises the operational core can't absorb at the pace they arrive.

None of those speeds are wrong in isolation. Some of them need to be fast. And some of them — assurance, risk, architecture, regulatory compliance — need to be deliberately slower. Speed in those domains isn't a virtue; it's a liability. The problem is not that some parts are slow. The problem is what happens where different speeds meet, and nobody has designed the interface.

That collision - between legitimately different speeds, at poorly designed interfaces - is what i've come to think of as the changing-gears problem. And once you see it, you see it everywhere.

The symptom everyone recognises

You'll know the pattern. A transformation programme is launched with real ambition. New ways of working are introduced, usually in delivery. Agile, DevOps, product-led: take your pick. The teams doing the work genuinely speed up. And then they hit a wall that nobody redesigned: an approval chain calibrated to a different era, a governance forum that meets at the wrong cadence, a shared service that can't absorb demand at the rate it now arrives, a funding model built around annual cycles when decisions need to land in weeks.

The usual response is to blame the bottleneck. The governance board is too slow. The architecture function is blocking delivery. The centre doesn't get it. Middle management is frozen.

But notice what's happening in that narrative: slow is cast as the villain. The assumption is that the fast parts are right and the slow parts need to catch up. Thats often exactly backwards. A governance board that meets quarterly may be meeting at precisely the right cadence for the decisions it needs to make well. An architecture function that thinks in years is doing its job. The problem is that the interface between them and the fast-moving parts was never designed to handle the difference.

I've spent enough time inside these situations to be fairly confident that the standard diagnosis - the frozen middle, the resistant bureaucracy - is wrong, or at least badly incomplete. What I see more often is not people who are frozen, but people who are thrashed. They sit at the convergence of incompatible clock speed, absorbing friction that the operating model was never designed to resolve. They're not the problem. They're the symptom.

The real issue is structural. It's a design problem. And it has a shape that's more specific than 'we need to be more agile.'

A different starting point

Over the past year, I've been developing a framework I'm calling Requisite Pace.

Requisite Pace is the ability to create value at the right speed, across different speeds, and to change that arrangement before the world forces you to.

It starts from a premise that's simple enough to state but turns out to have quite far-reaching implications for how you design and govern an organisation:

The goal is not uniform speed. It's the right arrangement of different speeds, in service of value - and the ability to change that arrangement when conditions shift

Pace is not the purpose. Value is. An organisation that has exquisitely synchronised its internal clocks but is delivering the wrong things at the wrong time to the wrong people has solved a timing problem and missed the point. Requisite Pace starts from the proposition that pace choices are design choices about where and how value gets created, protected and renewed. Getting the timing right matters because getting the value right depends on it.

This also means the second half of the premise - the ability to change the arrangement - matters at least as much as the first. An organisation can be beautifully designed for today's conditions and still be fragile, if it can't reconfigure when those conditions change. Efficiency and adaptability are not the same thing, and most operating models have been optimised heavily for one at the expense of the other.

Requisite Pace gives leadership teams a structured way to see the changing-gears problem and do something about it. It works though four diagnostic questions:

1. Which internal clock speeds matter most to us?

Not all of them. Not the loudest. The ones that will actually shape whether you succeed or fail - and that should therefore set the rhythm of your sensing, governance, and investment decisions.

2. What pace profile do we need internally?

Where do you genuinely need speed? Where do you need stability? Where do you need deliberate control? And where is the current arrangement a product of design versus a product of accumulation?

3. Where are the friction points between fast and slow?

This is where most of the day-to-day pain actually sits. The interfaces between domains - handoffs, approval chains, governance cadences, decision paths - are where pace incoherence becomes visible. And costly.

4. Could we change gear in time?

If conditions shifted materially, could you reconfigure quickly enough? Or have you optimised yourself into a shape you can no longer revise? This is the question most organisations never ask until the answer is already no.

Those four questions are deceptively simple. Answering them properly requires looking at your organisation through a lens that most strategy and operating model work doesn't use - one that treats time not as a background condition, but as a design variable in service of value and viability.

Why now?

Three things make this more pressing than it was five years ago.

First the environment is not just faster. It is more uneven. Geopolitics, AI, climate change, supply chain volatility - these don't all accelerate at the same rate or in the same direction. Some demand rapid response. Others demand patience, rigour, and the discipline not to move until you're ready. The challenge is not one-speed acceleration. It's managing a multi-speed organisation in a multi-speed world.

Second, the agile movement - for all its genuine contributions to delivery practice - has left a gap at the enterprise level. Faster teams do not automatically produce an adaptable organisation. The system problem is bigger that the team problem, and most organisations have discovered this the hard way.

Third, many organisations are now several rounds into transformation and restructuring, and the returns are diminishing. The usual layers - delayering, centralisation, platform consolidation, process standardisation - can improve efficiency, but they can also quietly destroy the organisation's ability to reconfigure. That trade-off is rarely made explicitly.

What's coming

This is the first in a series of posts where I'll unpack the thinking behind Requisite Pace in more detail. Future posts will look at how to read your organisation's pace architecture, where the most common failure patterns show up, why hierarchy - when it works - it actually a timing mechanism, and what distinguishes organisations that can change gear from those that can't.

I'm sharing this now because the framework is developed enough to be useful, but I also want to test it in the open. So I'm interested in two things:

First: does this resonate with what you see? The changing-gears problem - different parts of the system running at different speeds with nobody designing the interfaces between them - is that a recognisable pattern in your organisation?

Second: where does the standard 'go faster' prescription fall short for you? What problems persist even after you've done the agile transformation, the restructure, the platform investment?

If you're dealing with tensions like these - delivery speed versus assurance, innovation versus legacy core, strategic ambition versus governance bandwidth, the need to more quickly versus stay coherent - I'd be glad to compare notes.

The idea is simple enough to state. The hard part is organisational.

Speed isn't the issue. Timing is.