Why programmes drift apart, and what interlocks fix

Most people in an organisation don’t experience governance as a system.

They experience their slice of it: a project SteerCo, a program board, a portfolio checkpoint, a functional leadership forum.

While each forum can be well run in isolation, execution often breaks in the seams between them, where dependencies, trade-offs, and decision pathways cross boundaries.

This came through strongly in my research with senior leaders. Many described how limited their visibility was beyond their own forums, and how the pain shows up later as rework, slow decisions, and escalations that feel unavoidable.

That’s the challenge of multi-layered governance: not the quality of any one forum, but whether the layers connect.

That’s what interlocks solve.

Interlocks aren’t extra meetings. They’re the minimum touchpoints and rules that connect the governance system, surfacing cross-functional dependencies and trade-offs early and keeping them visible as work moves, so leaders can steer with clarity, not surprise.

In practice, interlocks operate across two levels:
- Governance level: where leaders surface and route enterprise dependencies, priorities, and trade-offs, set decision boundaries, and track what must be resolved outside the forum.
- Delivery level: teams solving sequencing, capacity and dependency tensions, then elevating only what needs enterprise judgement.

And when interlocks are working, you’ll see three shifts:
1. Dependencies surface early: while you still have options to resequence, reassign, or make a call.
2. Trade-offs are explicit: because if they’re not named, they still happen late and expensively.
3. Escalation is deliberate: teams resolve what they can at the lowest responsible level, and SteerCo is only involved in true enterprise calls, not day-to-day dependency friction.

In one organisation I worked in, we tackled interlocks at two levels: a cross-functional leadership forum to prioritise the roadmap and quarterly outcomes, and manage interlocks across functions; and a delivery-level big room planning where teams mapped dependencies, flagged decision points, set delivery priorities, and exposed constraints early.

This approach saw those dependencies and risks owned, translated into clear actions and commitments, and elevated into project governance reporting, giving steering committees visibility of execution risk across the roadmap, not just inside individual projects.

The impact wasn’t “more alignment.” It was faster execution: fewer surprises, fewer late escalations, and cleaner decisions because leaders could see what was being managed between the forums.

Every forum can be well run and the system still fails, because nobody owns the seams between them. Designing the connective tissue, and keeping it light enough that people actually use it, is part of what Execution sets up.

This is part of lever 4 (Governance & Decision Rights) of the Strategy Execution by Design Model. See the full framework →

Not sure which of the seven levers is holding your execution back? Take the Strategy Execution Maturity Model Assessment →

Written by Rebecca Reti, strategy and execution consultant working with boards and executive teams across Australia and New Zealand.

There's more on this in the carousel, including how to check whether your governance system is managing its interlocks, and design moves that build rhythm without meeting bloat. See the carousel on LinkedIn →