"And for Heaven's Sake, Don't Overlook Governance!" - Principle 16, Principles by Ray Dalio
The Art
"And for Heaven's Sake, Don't Overlook Governance!" - Principle 16, Principles by Ray Dalio
Ray Dalio sort of buried that line near the end of Principles, his book about how he runs Bridgewater Associates, the world's largest hedge fund. After several hundred pages of advice on culture, hiring, decisions, and machines, he stops, turns to the reader, and effectively says: whatever else you do, please do not skip this part. I couldn’t agree more.
Dalio had reason to insist. He ran Bridgewater for the better part of forty years without much in the way of formal governance. There was no board overseeing the CEOs. No internal rulebook. No appeals process. It worked because he was there to make it work. When he tried to step back, the firm discovered that nobody was quite sure how decisions were supposed to get made without him, and they had to construct a governance system after the fact. The chapter is, effectively, a confession masked as advice [see callout]. An advice every programme manager should pay heed to.
What governance actually means on a programme
Ask ten people on a programme what governance is and most will reach for the word "framework." A few will mention RACI charts. One might produce a diagram with arrows. And then there are books, research papers and certifications galore. None of this is wrong. But most of it describes the machinery rather than what the machinery is for.
A plainer way to put it: governance is the system that decides who decides. It is the arrangement of forums, decision rights, and escalation routes that determines how the programme makes choices, surfaces problems, and corrects course. If you have ever been in a meeting where everyone agreed something was going wrong but nobody could say with confidence who had the authority to fix it, you have already met a governance problem.
At any moment, a working governance system is answering four questions:
Who has the authority to make this decision?
Where does this problem go to get solved?
Who is checking that the programme is still doing what it said it would?
What happens when any of the above stops working?
Everything else i.e. the steering committees, the gate reviews, the risk forums, the assurance lines is machinery built to keep those four answers relevant and current. When the machinery works, nobody notices it. When it does not, it becomes the thing everyone points at in the post-mortem.
Why programme governance is not enterprise governance
This is the bit organisations very often miss. They assume the governance that runs the company will also run the programme. It certainly will not, and the reasons are structural.
Enterprise governance is built for a permanent organisation doing more or less the same thing year in year out. Boards meet quarterly. Audit committees look backward. The cadence aligns with the business cycle, which is appropriate, because the business is not going anywhere. Continuity is the goal.
Programme governance is built for almost the opposite situation. A temporary organisation, doing something it has never done before, on a fixed timeline, often under public and political scrutiny, with a budget that everyone is watching. Decisions need to be made in weeks rather than quarters. The shape of the risk changes from one delivery phase to the next. The governance arrangement that worked in design will probably not work in construction, and the one that worked in construction will likley not survive handover. Programme governance has to be designed to evolve, because the programme itself does.
There is also a difference in what is being protected. Enterprise governance largely protects shareholders from the executive. Programme governance protects the sponsor - and, indirectly, the public and the eventual users - from the optimism of the delivery team. Quite frankly, delivery teams have to be optimistic; otherwise nothing gets built. Governance is the structural counterweight that asks the uncomfortable question when everyone else is too busy delivering to ask it.
Treat one like the other and the predictable result is a programme that produces beautifully formatted quarterly board reports describing a situation that diverged from reality two months earlier. This has been a root cause for a surprising number of major failures.
When it worked: London 2012 Olympics
The London 2012 Olympics is the case British practitioners cite most often as what good looks like.
The governance was deliberately layered and these layers were well-defined. The Olympic Delivery Authority handled venues and infrastructure. LOCOG organised the Games themselves. The Government Olympic Executive sat above both, with the Treasury and the National Audit Office (NAO) ammes would have had one. In reality, the redundancy was the whole point. When problems arose, and they certainly did, there was always a forum to escalate into and a decision-maker with the standing to act.
The venue security shortfall in the weeks before the Games is the example everyone remembers. G4S had committed to providing the security workforce. It became clear, late in the day, that it could not. In a less well-governed programme this would have become a slow-motion disaster. On London 2012, the problem surfaced quickly because there was a forum equipped to receive it. The decision to bring in the military was made in days rather than weeks, by people with the authority to make it. The public reporting line through the NAO meant the response was visible and accountable from the start.
The Games were delivered on time and broadly on budget. The governance architecture has since become the template for most major UK programmes that followed it. None of which is to say it was elegant; and frankly elegance is not what governance is for.
When it went badly wrong: Berlin Brandenburg Airport and its 550,000 problems
Berlin Brandenburg, on the other hand, is the European case study that practitioners outside Germany still wince at.
The airport eventually opened in October 2020, roughly nine years after its original planned opening of 2011. The cost rose from an initial €2 billion to somewhere north of €7 billion, depending on how generously you count. None of the technical problems was unprecedented - fire safety systems failing certification, poor cabling, design changes piling up during construction. What was unusual was the governance arrangement that allowed them to compound for years before anyone with the standing to act actually acted.
The airport was governed by a state-owned company whose supervisory board was dominated by political appointees. Few had the technical depth to challenge what they were being told, and the structure gave them no independent source to check it against. The CEO sat across the design and the oversight of the delivery system. Independent assurance, a common feature on such programmes, was effectively absent.
The German parliamentary inquiry that followed read, in places, like the Hardie report on Edinburgh Trams; a steady accumulation of small failures that a working governance system would have caught early. The airport opened, eventually. The reputational damage took longer to repair than the construction.
So what?
If you are running a programme, or sponsoring one, the practical takeaway is this: governance is not the form you fill in for the assurance team. It is the thing that determines whether the programme survives its own complexity. The successful cases are not the ones with the cleverest delivery teams. They are the ones where the people overseeing those teams can actually see what is happening, and have somewhere to take it when they do.
The most useful test, at any stage of a programme, is to ask: if something serious goes wrong in the next three months, where will it surface, and who has the authority to do something about it? If you can answer that quickly and specifically, the governance is probably working. If you find yourself reaching for an org chart, it probably is not.
Some things that tend to work
A short list, drawn from what the programmes that succeeded seem to have in common:
Design the governance before delivery starts. Retrofitting it later costs more, and the gap is where most of the damage gets done.
Make governance someone's job. Someone senior needs to own the governance system itself - not run the programme, but watch whether the oversight is doing what it was set up to do, with the standing to say when it is not.
Keep the forums small enough to decide. A governance meeting that cannot make the decision it was set up to make is not a governance meeting. It is a status update in better clothes.
Re-design at every phase gate. The structure that worked through design will not work through construction, and the one that worked through construction will not survive handover. Plan for the handovers, not just the phases.
Reward surfacing. Make it cheaper to raise a problem than to hide one. This is structural, not cultural. It is about who chairs what, who reports to whom, and whether independent assurance actually has a line into the sponsor.
Assume the founders will leave. The Programme Director who set the thing up will not be there in year eight. Build a system that works for the people who will inherit it, not just for the people who designed it.
None of this produces anything that catches the limelight. None of it gets pointed at during a ribbon-cutting. It is, exactly as Dalio said, the part you are most likely to overlook.
Which is presumably why he put the exclamation mark on it.
15 Years Late and £100 billion over; HS2 and the Art of the Reset
May 26, 2026
Major Programme Leadership - A Poorly Understood Profession
Mar 15, 2026
