The dual-layer governance problem.

Most large enterprise programs do not fail for lack of strategy. They do not fail for lack of capital. They very rarely fail for lack of talent. They fail because the operating model that connects strategy to delivery is broken, and nobody on the program is responsible for the operating model itself.

The pattern is consistent enough that you can almost set your watch by it. A program is conceived in a strategic plan. It gets a name, a budget, an executive sponsor, and a steering committee. The steering committee meets monthly. It receives a slide deck. The slide deck reports green. Six months in, the slide deck still reports green. Then there is a quarter where the slide deck reports yellow on a single workstream. Then a quarter where the program is suddenly behind. The steering committee asks what changed. Nothing changed. The reporting changed.

This is not a failure of execution. It is a failure of operating model design. And it has a specific shape that, once you see it, becomes hard to unsee.

The conflation

Strategy and delivery operate at different velocities. Strategy makes decisions in months and quarters. Delivery makes decisions in days and weeks. Strategy needs to know about capital deployment, portfolio prioritization, and risk at the enterprise level. Delivery needs to know about scope, dependencies, and unblocking.

Most program operating models try to serve both with a single governance layer. A monthly steering committee that hears about workstream-level dependencies. A weekly working group that surfaces capital decisions. The result is two governance bodies doing each other's job badly, and neither one doing its own job at all.

The strategic body cannot move fast enough on the things delivery needs decided in days. The delivery body cannot resolve the things strategy needs to weigh in on. So both layers escalate. The escalation pile grows. Decision velocity slows. By the time the program is reporting yellow, the operating model has been broken for two quarters and nobody noticed because the reporting was calibrated to a single audience that was getting comfortable signal from a different layer's work.

The dual-layer model

The fix is structural, not behavioral. You cannot tell people to "communicate better" through a broken operating model. You have to design the operating model so that strategy and delivery operate as two distinct layers connected through a small number of well-designed translation points.

The macro layer governs strategy. Investment decisions, portfolio alignment, risk oversight, executive visibility. Cadence is monthly or quarterly. Decisions are about capital and direction. The body is small, senior, and meets when capital decisions need to be made, not on a calendar.

The micro layer governs delivery. Coordinated execution across teams. Cadence is weekly. Decisions are about dependencies, scope, and unblocking. The body is the people doing the work, plus the program manager, plus a single decision-maker per workstream. It does not invite executives. It does not produce slide decks for executives. It produces decisions and a one-page status that the macro layer can read in five minutes.

The translation points are the moments where the two layers meet. There should be very few of them. A monthly executive readout where the macro layer hears the state of delivery in language calibrated to capital decisions. A standing escalation channel where the micro layer can surface a strategic question without waiting for a calendar slot. A quarterly business review where both layers reconcile the program's trajectory against the value case.

The single design choice that separates programs that land from programs that drift is whether the operating model has two governance layers or one trying to be both.

What the layers actually decide

Once you have two layers, you have to be disciplined about what each one decides. The macro layer decides on capital. Should we keep going? Should we accelerate? Should we expand scope? Should we kill it? Those are the questions an executive committee is built to answer. They are not built to decide whether workstream three should pull in the contract negotiation by two weeks.

The micro layer decides on coordination. Which dependency moves first? Where does the slip propagate? What gets unblocked this week? Those are the questions the program manager and workstream leads are built to answer. They are not built to decide whether the program's value case is still valid.

The translation points carry the rest. The monthly readout tells the macro layer how delivery is going in language they can act on. If a strategic decision is needed, the readout names it explicitly and the macro layer decides. If no strategic decision is needed, the readout is short and the macro layer's role is to confirm direction. The escalation channel handles the in-between cases. The quarterly review is where the value case gets refreshed against operating reality.

Why this is hard to retrofit

If your program has been running for a while with a single governance layer, splitting it is harder than designing it correctly from the start. The same people will need to operate in different bodies with different decision authorities. The reporting will change. The cadence will change. The implicit power structure that has formed around the original governance will resist.

The retrofit is still worth doing. The alternative is the slow erosion of program credibility that ends with the slide deck going yellow, then red, then with a write-down. Splitting the layer is rarely as disruptive as it feels in the design phase. Most program teams privately welcome it. They have been doing two jobs in one body for months and were not going to say so out loud.

The takeaway

If you are running a program where the steering committee is reporting green and you have a quiet sense that delivery is slower than green implies, look at your governance structure first. You are probably running a single layer trying to be two. The fix is design, not effort. Once the operating model is right, the discipline that makes it work is comparatively cheap.

This is the structural conviction at the center of the M² framework. It is the design choice that makes everything else in M² possible. The methodology, mobilization, measurement, and maturity pillars all assume the dual-layer structure underneath. If you only take one thing from how we run programs, take this.