Every Handshake Has a Clock: Why Modular Firms Still Struggle to Rewire

Every organisational handshake carries a timing contract, whether or not anyone has written it down.

The recent Harvard Business Review article AI Adoption Is Testing Modular Firms identifies an important problem. Firms have become good at decomposing work into agile teams, business units, platforms and reusable services. They remain much less capable of recombining those parts quickly when a new opportunity appears.

The authors call this the recombination bottleneck. Their answer is “composable integration”: make recombination a managerial skill, standardise the handshake around each connection, build reusable capabilities and move authority towards the edge.

The diagnosis is right. But rewiring depends on more than a standardised handshake. The proposed handshake needs one more field: time.

An interface can specify who may connect, what data can move, which standards apply, who carries the risk and where accountability sits. Unless it also specifies when a response is due, which cadence governs the decision and what happens when the parties cannot move at the same rate, it remains only half-designed.

When two modules are reconnected, the organisation is reconciling not only two interfaces, but two clocks.

This is one expression of a broader idea I call Requisite Pace: organisations perform not by making every part move uniformly fast, but by making their different clocks work together.

Modularity has a timing condition

Modularity is usually drawn as boxes and boundaries. Work is divided into components, responsibilities are allocated, and interfaces define how the parts fit together. But a modular system does not work simply because its parts have clean edges. It works because most interaction can happen within each part, while a smaller number of consequential connections preserve coherence across the whole.

Herbert Simon's account of near-decomposability was explicitly dynamic. Higher-frequency activity occurs within subsystems; lower-frequency activity connects the larger system. Short-run behaviour is largely internal, while cross-system effects become visible over longer periods.

That frequency dimension applies directly to organisations. Inside a product team, decisions might be made daily and releases weekly. Between that team and finance, investment decisions may happen monthly or quarterly. Risk, architecture and regulatory assurance may each follow another rhythm.

Baldwin and Clark's design-rules framework made modularity more operational by specifying architecture, interfaces and integration tests. Those rules are necessary, but timing is not foregrounded as a distinct interface term.

The same is true of many modern discussions of organisational modularity. They foreground the strength of connections, the clarity of interfaces and the allocation of decision rights, but are less likely to make the characteristic frequency of those connections explicit. The boundary is treated as a line around a body of work when it is also a change of pace.

By a clock I therefore mean three practical things: response time, or how quickly an answer or action is due; decision cadence, or when and how often the relevant decision can be made; and an exception rule for what happens when the two sides cannot move at the same rate.

A team may know exactly who owns a capability and how to request it, but not whether an answer is due tomorrow, next week or at the next quarterly forum. The interface is visible. Its clock is not.

This argument does not start from a blank page. Queueing theory explains how patterns of arrival and service create waiting. The Theory of Constraints directs attention to the system constraint. Agile methods make cadence explicit within teams. The claim here is that timing must also be designed as a term of the interface between organisational modules.

Where the queue moves

AI makes this omission harder to ignore because it changes organisational rates unevenly.

Analysis, model development, first-pass drafting and option generation can all accelerate. Prioritisation does not become instant. Risk judgement does not become effortless. Architecture review, legal approval, customer-impact assessment, funding decisions and governance forums often continue on their existing cadence.

The result is not a general increase in speed. It is a widening gap between the rates at which connected parts of the organisation move.

That leads to a testable prediction. Standardised interfaces, reusable capabilities and delegated authority should reduce recombination time sharply where the participating units already operate on compatible cadences. But where a weekly product squad still depends on a quarterly model-risk forum, technical integration may get much faster while the end-to-end time from opportunity to operation barely moves.

After the reforms, the residual delay should cluster where different cadences meet.

Measure the whole journey

Recombination time needs a clear beginning and end. Measuring only implementation captures the final leg, not the whole journey.

A practical end-to-end measure might run from opportunity recognised to capability operating reliably in its new context. That journey contains at least three stages:

1. Time to know: recognising the opportunity, finding the relevant capability and understanding whether it can be reused.

2. Time to decide: securing commitment, funding, risk acceptance and authority to proceed.

3. Time to change: adapting, integrating, deploying and stabilising the capability.

A firm might reduce implementation from six weeks to two but still take a quarter from opportunity to operation because the proposal spends ten weeks waiting for a decision. The integration team reports a major improvement. The business experiences almost none.

One overall average can also mix unlike cases. Reusing a low-risk internal analytic is not the same kind of recombination as moving a regulated model across jurisdictions or onboarding an external ecosystem partner. Leaders need to classify the recombinations they measure and ask where the elapsed time sits.

The revealing question is not simply, "Did recombination time fall?" It is, "After we improved the interfaces and rules, where did the remaining wait move?"

Cadence is not the same as congestion

Once the journey is visible, there is an important rival explanation to test. A slow decision step may simply lack capacity. The reviewers are busy, the queue is long and work waits because utilisation is high.

In short: if the delay tracks the calendar, cadence is implicated; if it tracks the backlog, capacity is implicated.

Cadence delay has a different signature that can often be found retrospectively in decision logs.

Start with the date an item was ready for review, not merely the date it was first discussed. Then calculate where that date fell within the relevant forum cycle and compare it with the time taken to reach a decision.

Suppose a forum meets every 30 days. An eligible item that becomes ready two days after the last meeting waits about 28 days for the next decision window. One that becomes ready two days before the next meeting waits about two. As the ready date moves through each cycle, the wait falls from almost the full interval to almost zero before jumping back again. Plotting decision-stage elapsed time against position in the cycle should therefore reveal a downward slope or sawtooth pattern.

Across requests that become ready evenly throughout a fixed review interval, cadence alone contributes an average wait of roughly half that interval. If there is an agenda cutoff, the pattern should contain a step: an item that becomes ready just after the cutoff may wait an additional full cycle. When work is prepared backwards from a meeting deadline, the effect can begin earlier still. That is one reason to separate time to decide from the total journey.

Congestion produces a different pattern. Delay rises with backlog or workload and tends to develop a long right-hand tail, without a stable relationship to the calendar. The practical test is therefore to plot decision delay against both position in the forum cycle and backlog when the item became ready.

A calendar slope or cutoff step is evidence of cadence delay. A strong relationship with backlog is evidence of constrained capacity. Many systems will show both.

This is a diagnostic, not proof. Its value depends on recording when work was genuinely ready for review and on distinguishing that timestamp from the administrative date on which it entered the system.

This matters because conventional constraint analysis looks for the busy resource. Cadence analysis also looks for the batching interval. A forum can impose months of waiting even when its participants are not continuously busy.

Timing differences do not disappear

Giving a team responsibility without the authority, funding or risk cover to act does not eliminate the queue. It relocates it from technical integration into approval, exceptions and cross-functional coordination.

An unresolved timing difference must be absorbed somewhere. It can be queued, so one side waits until the other is ready; buffered, using capacity, pre-approved limits or decision guardrails to absorb ordinary variation; or translated through a role, process or protocol that reconciles the different clocks.

If none of these routes has been designed, a manager usually absorbs the difference by hand. They chase responses, translate between functions, package work for the next forum, negotiate exceptions and nudge decisions through the system. The manager then appears to be the bottleneck. More often, they are where the underlying timing constraint becomes visible.

The organisation looks as though it is coping because a person is carrying the mismatch. But the cognitive route has a ceiling. As the number of connections grows, manual translation becomes slower, more fragile and increasingly dependent on individual relationships.

Continuous coordination is a costly form of reconciliation. If every local change triggers high-frequency negotiation across multiple units, the organisation may remain modular on paper while behaving as one tightly coupled system. Explicit timing terms protect autonomy by making coordination selective rather than permanent.

Some time protects value

Not every cadence gap is a design failure.

A quarterly risk forum is not automatically good governance, but neither is it automatically bureaucracy. Independent challenge, evidence gathering, safe testing and accountable commitment can require time where consequences are material, systemic or hard to reverse.

The question is whether the time is deliberate.

If the review interval reflects the risk, the evidence requirement is clear, ordinary cases have an appropriate route and genuine exceptions can escalate, the slower clock may be part of the control. If an item waits three months merely because it missed the agenda, the delay is an accident of scheduling.

The task is to distinguish time that protects value from time created by habit, congestion or poor design. The first should be protected. The second should be removed.

Design the clock at the join

Every strategically important connection needs a deliberate mechanism for handling the timing difference across it.

There are four basic moves:

• Absorb the difference. Use capacity buffers, pre-approved limits, decision guardrails or service-level commitments so ordinary variation does not require fresh negotiation.

• Synchronise selected moments. Create shared decision rhythms, trigger-based reviews or exception channels. Bring the parties together when interdependence matters, not continuously.

• Translate across the boundary. Use a clear interface contract or an intentional boundary-spanning role with the authority and capacity to carry context, standards and decisions.

• Remove the boundary. Combine the work when separation no longer protects customer value, expertise, risk, identity or local responsiveness.

Making the mechanism explicit is only the beginning. Each choice makes a different trade-off between speed, cost, reversibility, risk and local autonomy. If the clocks remain mismatched, the load will appear somewhere else.

For the three connections that matter most to your current strategy, ask:

1. Where is the time? How long does it take to move from recognising an opportunity to operating differently, and where does the elapsed time accumulate?

2. Which clock governs? What response time, decision cadence and exception rule apply, and are they deliberate?

3. Who carries the difference? Is it absorbed through a buffer, a shared rhythm, a designed translation mechanism or simply a person?

This is the broader design problem behind Requisite Pace. The goal is not to make every part of the organisation move at the same speed. It is to design the relationship between the pace of the work, the pace of accountable judgement and the mechanisms that connect them.

Every handshake already has a clock. The question is whether it has been designed into the interface or left for a manager to carry by hand.

Speed isn't the issue. Timing is.