Make the Gears Mesh

The second discipline of Requisite Pace

Blog 3 in the Requisite Pace series

In the last post, I argued that every leadership team under pressure to move faster needs to answer a prior question: faster than what?

The first discipline of Requisite Pace is to choose the external clocks you couple to. But choosing the clocks is only the starting move. It tells you which rhythms outside the organisation matter. It does not tell you whether the rhythms inside the organisation can work together.

Most organisations do not fail because one part is simply too slow. They fail where one legitimate rhythm depends on another: product waiting for governance, delivery outrunning assurance, procurement blocking work that moves in days, strategy landing on teams faster than they can absorb it, and middle managers quietly becoming the only interface between incompatible clocks.

Organisations fail at the joins.

The second discipline: design the joins

An organisation does not have one speed. Customer response may run in minutes. Operations in hours. Product delivery in weeks. Architecture in quarters or years. Vendor contracts lock in for three years. Governance meets monthly. Strategy may be refreshed annually, while regulatory assurance works to a different calendar again.

Those different speeds are not the problem. They are the natural response to different kinds of work, different risks, different stakeholders, and different time horizons. The problem is what happens where those speeds meet.

Most organisations have never explicitly designed their internal pace architecture. What they have is the accumulated residue of historical choices: structures, forums, funding cycles, approval chains, role definitions, policy thresholds, and supplier arrangements. Each carries a tempo. Each may have made sense locally. Few have been tuned against the others.

The organisation is not one system running at the wrong speed. It is a collection of subsystems running at different rhythms, connected by interfaces nobody designed.

The second discipline of Requisite Pace is therefore not to make the whole organisation faster. It is to make the gears mesh.

Start with the pace profile

The first move is to see the organisation as a profile of speeds, not as a single entity with one.

A pace profile maps the major domains, capabilities, processes, and value chains by their dominant rhythm and horizon. It asks four questions about each: how fast does it sense what is happening, decide what to do, act on the decision, and assure that what it did was safe, compliant, and correct?

Those four verbs map to the Requisite Pace measures. Mean Time to Know (MTTK) runs from a signal appearing in the world to the organisation knowing it requires a response. Mean Time to Decide (MTTD) runs from knowing to a committed decision. Mean Time to Change (MTTC) runs from the committed decision to the change actually landing and being assured.

A simple cross-enterprise profile might look like this:

The point is not to force these domains into one rhythm. The point is to make their rhythms explicit, then design the interfaces between them.

The operating grammar: cadence, latency, bandwidth

Three words do most of the diagnostic work.

Cadence is the rhythm at which a domain, forum, or process operates - how often it recurs and how long each instance lasts. A monthly one-hour forum and a monthly full-day forum have very different decision capacity.

Latency is the delay between a signal arriving and a response being enacted. MTTK, MTTD, and MTTC are specific latencies at specific stages of the loop. Latency accumulates at every stage, and especially at every interface.

Bandwidth is how many signals, decisions, or escalations a role, forum, or process can handle in a given period. When bandwidth is exceeded, queues form, priorities blur, workarounds appear, and latency gets worse.

Many leadership teams talk about whether work is fast or slow. The more useful question is: what cadence, latency, and bandwidth has the organisation actually designed - and do they fit the work flowing through them?

Where friction lives

Once you have a pace profile, look at the boundaries. Do not start by asking which domain is failing. Ask how the domains connect.

Friction is the sound of gears that do not mesh. At every interface between two paces, four questions are worth asking:

• How fast does work, information, or risk arrive from the faster side?

• How fast can the slower side absorb, decide, or respond?

• When those rates do not match, does the work queue, stall, escalate, or get routed around?

• Who holds the translation between the two paces - and is that what they were designed to do?

Map the workarounds and you map the friction.

Interfaces between fast and slow are not optional. Delayering does not remove them. A new operating model does not remove them. A platform migration does not remove them. If the interface is not designed formally, it reappears as informal escalation, shadow governance, and individual heroics.

Formal interfaces are less dangerous than invisible ones.

Four ways to connect different speeds

The mechanisms for connecting domains that legitimately run at different tempos fall into four broad moves.

Absorb the mismatch. Use a buffer, backlog, or time-boxed envelope so a faster domain can act without the slower side dictating its rhythm. A protected funding envelope inside a quarterly governance cycle is the canonical example.

Synchronise the mismatch. Use shared planning rhythms, asynchronous triggers, or pre-authorised exception channels so domains recouple when they need to, not continuously. A standing fast lane for cyber, regulatory, or safety exceptions is the canonical example.

Translate the mismatch. Use a boundary-spanning role or a formal interface contract to interpret between two rhythms and judge what must move when. A platform team operating to a defined service contract for the product teams it supports is the canonical example.

Dissolve the boundary. Merge domains where the interface itself is the problem. DevOps is the canonical example. The boundary usually moves rather than disappears, so this move tends to intensify friction at adjacent interfaces.

Each move carries consequences for role design, governance, process, information flow, and accountability. The question is not which move you like; it is which one fits the tempo difference at this interface.

Not every decision needs the same path

The same logic applies to the decisions flowing through those interfaces.

Many organisations route too many decisions through roughly the same path. That only works if every decision has roughly the same shape. They do not.

The sharper distinction is decision type. Decisions differ by blast radius, reversibility, and the tempo the external signal is demanding. Three types carry most of the diagnostic load.

Reversible operational decisions (supplier swap for one order, local resource move, SLA adjustment within policy) should land in hours to one day. They should be delegated. If this kind of decision needs a forum, the system is broken.

Strategic, hard-to-reverse decisions (platform migration, acquisition, market entry or exit, major reorganisation) should take months, deliberately. They belong in an executive or board process. The slowness should be earned by real deliberation, not procedural accumulation.

Time-critical exceptions (cyber incident, regulatory breach, supply disruption, safety event) need to move in minutes to hours, through a pre-authorised fast lane with standing authority. Not a committee being invented mid-crisis.

When the standard path becomes too slow, a shadow path appears. Decisions still get made, but under the table, with unclear accountability and little visibility to governance. That is not agility. It is the organisation telling you its interface has failed.

Three sources of interface friction

When a leadership team says the organisation cannot decide or cannot coordinate, the first diagnostic move is to locate which of three failures is happening at which interface.

Type mismatch. The mechanism is legitimate, but the wrong type of decision is being routed through it. A reversible operational decision waits for a board forum; a time-critical exception is routed through a monthly committee. The mechanism is not the issue; the queue is.

Wrong mechanism. An interface exists, but it is the wrong kind for the tempo difference it sits across. There is a buffer where translation is needed, a rhythm where an exception channel is needed, or an interface contract where the two domains need to be merged.

Missing mechanism. There is no formal interface at all. Two paces collide and the mismatch is absorbed by whoever happens to sit at the boundary, usually informally and without mandate.

The remedies differ. Redesign the path for type mismatch. Replace the mechanism for wrong mechanism. Install one where it is missing.

The goal is not to remove all friction. Useful friction - the kind that protects rigour, safety, legitimacy, or coherence - has to be distinguished from accidental delay.

There is one pattern in particular - middle managers absorbing the work of multiple missing or wrong mechanisms - that I think has been widely misdiagnosed as resistance or capability failure. I will return to it in a separate post.

Where poor joins get misdiagnosed

Two patterns are worth naming, because they are routinely labelled as something else.

Fast delivery, slow governance. Delivery accelerates beyond the governance cycle. Signals about emerging risk exist, but the time from signal to intervention is too slow. By the time governance catches up, the condition has normalised itself. This usually gets labelled a culture problem or a risk-appetite problem. It is more often a cadence problem.

Delayering damage. A layer removed as bureaucracy may actually have been performing pace-mediating work: filtering signals, translating intent, buffering fast teams from slow governance. Remove that work without redesigning it elsewhere, and the remaining structure inherits the mismatch. The symptoms are usually attributed to the people now sitting at the wrong altitude. The cause is the work that left with the layer.

The pace diagnosis asks a prior question: is the organisation blaming people for absorbing a mismatch the operating model never designed?

Where this leads

Designing the joins is the heart of the operating-model conversation, but it is not the final move.

Every miscalibrated interface, every queued decision, every workaround, every middle manager absorbing what the operating model should have resolved - all of it is interest being paid on something. That something has a name: pace debt.

Pace debt is the cost of past timing choices that now limit the organisation's ability to move, decide, govern, or reconfigure. The interest you pay daily is bad enough. The capacity it costs you when the world shifts and you need a larger change is worse.

That is the next discipline: preserve the ability to shift. It is where today's design quality compounds into tomorrow's reconfiguration capacity, and where the question changes from "Does this work?" to "Could we change it, in time, if we had to?"

A final question

Take one interface in your organisation where you know friction is high: where decisions sit too long, where workarounds have become the standard path, where assurance is out of step, or where middle managers are absorbing the strain.

Can you say, clearly and without guessing:

• what the tempo mismatch actually is;

• which of the three failures is happening: type mismatch, wrong mechanism, or missing mechanism;

• which decision types are flowing through it; and

• which design move would fit?

If those answers are not available in specifics, then you do not have an interface.

You have an accident.

Speed isn't the issue. Timing is.