Governance and accountability

Governance architecture is the structural backbone that decides whether your strategy accelerates or gets stuck. It is the set of forums that exist, the reason each one exists, and how they connect up and down the chain.

The test is whether you can explain why each forum is there. In most organisations at least one exists because of a risk that was live three years ago, and nobody has retired it. Each addition looked sensible on the day. The accumulation is what costs you.

When governance is not engineered it becomes a constraint rather than an enabler. Decisions get made in isolation and land at the wrong level. Leaders act without seeing the whole system. Information moves at the pace of the reporting cycle rather than the pace of the strategy.

Organisations that do this well design governance on purpose. They are clear about which forums exist and why, which decisions sit where, what pace the strategy requires, where risk is managed, and how information flows so people can act with confidence. And they make sure leaders have the skills to govern, not just to attend.

This is the distinction between governance as compliance and governance as an execution system. Compliance governance asks whether the process was followed. Execution governance asks whether the organisation can still make the calls the strategy needs, at the speed it needs them.

Decision making is the wiring that runs through execution. It works when you have deliberately designed where decisions sit and who owns the call. Most organisations never define, communicate or monitor it, and then wonder why execution slows.

When the decision system is not designed, the organisation improvises. Teams do not simply slow down. They start guessing, escalating, and reworking decisions that should have been clean. Decisions drift to the safest place, the biggest meeting, or the most senior person in it.

I watched this on a major enterprise systems programme. The organisation valued collaboration, so it ran a weekly steering committee with most of the executive team, regularly pulling tier three leaders into the room. It looked robust. It also trained the organisation to escalate. Because key decisions had never been agreed up front, everything defaulted to the committee, including decisions those tier three leaders were entirely capable of making.

The hidden cost was not meeting time. Teams spent more time explaining and justifying decisions than designing and delivering. Ownership blurred. Decision velocity dropped. Trust eroded.

The design principle is simple. Some decisions need a forum where leaders trade off cross-functional impacts. Others need a single owner with the remit and the expertise to make the call. Losing that distinction is what turns governance into a queue.

Escalation is not a culture problem. It is what capable people do when they are not certain they are allowed to decide. The fix is not encouragement, it is design.

Once the machine is running, leaders need line of sight to govern well. Not more updates. Enough clarity, and enough trust in the integrity of the information, to make good calls early rather than late.

Four things need to be visible. Pace, meaning what decisions are needed next and what is slowing momentum. Risk, meaning what is exposed and whether it is being managed. Value, meaning what trade-offs are being made and whether they are compromising the outcome. And truth, meaning whether what leaders are hearing reflects what is actually happening.

That does not appear in a pack by itself. Early in my career I watched an enterprise CRM project stay green until user acceptance testing. The sponsor was engaged and well intentioned, but updates flowed almost entirely through the project manager, and the steering committee rarely heard from the business owner or the leads closest to the affected processes. Requirements had never been locked down and end-to-end processes had not been validated. Because that reality did not travel up through the governance mechanisms, it did not surface as a risk. It surfaced later as defects.

By the time testing started it was not a handful of bugs, it was fundamental workflow failure. The programme went red quickly, not because people were not working hard, but because leaders had not had line of sight early enough to challenge the assumptions.

Governance that reports is easy to build. Governance that decides, and that surfaces bad news early enough to act on, has to be designed that way from the start.

A useful standard: nothing comes to a forum unless it is decision-ready. That means a clear recommendation, the options considered, the trade-offs, the unknowns, and what would change the call.

Most people do not experience governance as a system. They experience their slice of it: a project steering committee, a programme board, a portfolio checkpoint, a functional leadership forum.

Each of those can be well run in isolation while execution breaks in the seams between them, where dependencies, trade-offs and decision pathways cross boundaries. This came through strongly in my research. Leaders described how limited their visibility was beyond their own forums, and how the cost shows up later as rework, slow decisions, and escalations that feel unavoidable.

Interlocks are the answer, and they are not extra meetings. They are the minimum touchpoints and rules that connect the governance system, surfacing cross-functional dependencies early and keeping them visible as the work moves.

They operate at two levels. At governance level, leaders surface and route enterprise dependencies, priorities and trade-offs, set decision boundaries, and track what has to be resolved outside the forum. At delivery level, teams solve sequencing, capacity and dependency tension themselves, and elevate only what genuinely needs enterprise judgement.

In one organisation we ran both: a cross-functional leadership forum that prioritised the roadmap and managed interlocks across functions, and delivery-level planning where teams mapped dependencies, flagged decision points and exposed constraints early. The result was not more alignment. It was faster execution, with fewer surprises and cleaner decisions, because leaders could see what was being managed between the forums.

The failure mode here is subtle, because nothing looks broken. Every forum has an owner, an agenda and minutes. The gaps between them have none of those things, and that is where the delay accumulates.

Escalation tells you the truth about execution. In strong environments it is normal, early and useful, and it protects value. That only works when decision rights are clear and escalation thresholds are explicit, so teams know what to resolve and what genuinely needs enterprise judgement.

In weaker environments teams swing to extremes. They sit on issues until they are urgent, or they escalate everything and call it governance. Both are expensive.

This came through continually in my research. The pain was not the escalation itself, it was the pattern. Leaders either found out late or were flooded with noise, and by the time an issue arrived the options had already narrowed.

Healthy escalation has one job: to surface drift early enough to reset course. If an escalation does not end in a decision, a re-baseline, a named owner and an updated guardrail, it was not an escalation. It was venting, and the same issue will climb again next month.

Escalation patterns are not a behaviour problem either. They are what people do when thresholds were never set, so nobody knows what they are allowed to settle.

The question worth asking your leadership team is deliberately uncomfortable: do issues reach you too late, or do they reach you too often? Both answers point at the same missing design.