August 3, 2026 · 2 min read
Not one of the teams on my current programme reports to me. Several sit inside the same organisation, under different leads. The rest belong to partner organisations, in three different countries.
That is not an unusual situation. It is the normal condition of programme work above a certain size — and most of the advice about it is wrong.
The instinct, when you cannot tell someone what to do, is to build a path to someone who can. Escalation matrices. Sponsor meetings. A RACI with your name in the A column.
These are worth having. They are not worth relying on.
An escalation is a receipt — proof that you raised something. By the time you need one, the cost has usually already been paid: the delay happened, the dependency slipped, and you are now negotiating about who carries it rather than about sequence.
Escalation also scales badly. You can do it three or four times before you become the person who escalates, and then people start routing around you. The mechanism you built to create alignment quietly becomes the reason you stop hearing things early.
What aligned teams across three national clouds was not authority, and it was not escalation. It was making the logic of decisions visible enough that people could predict them.
Two mechanisms did most of the work.
Prioritisation criteria, written down. Not a priority list — the rules by which something becomes a priority. The difference matters more than it sounds. A list invites argument about position. Criteria move the argument up one level, to whether the criteria are right, and that is a conversation you can have once and then reuse. Teams that disagreed about outcomes could still agree about the test.
Go-live checkpoints with explicit conditions. “Ready” is otherwise an opinion, and opinions do not survive contact with an auditor. A checkpoint that states what must be true, and who confirms it, turns readiness into something checkable by someone who was not in the room.
Neither requires authority. Both require that you write things down and then hold yourself to them first — visibly, including when the answer is inconvenient for you.
The programmes I work on run under constraints about where data lives and who may touch it. It is tempting to treat that as an engineering problem: build the control, prove the control, done.
In practice the control is rarely the hard part. The hard part is agreeing who owns it, who demonstrates it works, and who gets woken up when it fails. Those are organisational questions wearing a technical costume. Answer them late and you end up with a control that technically exists and operationally does not.
This is also why “we will sort out the ownership later” is more expensive in regulated work than elsewhere. Later, in practice, means after an audit has asked.
Governance by legibility is slower to start. Writing criteria that survive scrutiny takes longer than issuing a decision, and there is a stretch early on where a directive would obviously be faster. That stretch is real and you have to sit through it.
It pays back because it compounds. A decision you make is worth one decision. A rule people can apply without you is worth every decision they then make on their own — and in a programme built to be handed over, not being in the room was always the point.
