By Thursday evening, four decisions have found their way to you.
Architecture has sent three design options “for review”. Finance wants your view on two ways to shorten the month-end close timeline. The data team wants approval for an exception they believe is necessary. A workstream lead wants you to settle a sequencing decision with another team.
All four are waiting.
And in every case, the people sending the paper understand the subject better than you do. You could spend your evening reading every page and still know less about the detail than the person who wrote it.
Yet somehow the programme is waiting for your name.
A programme leader is often the least qualified person to judge the paper sent up for approval, and still the one the programme waits for.
That is the part worth paying attention to. Because sometimes the programme genuinely needs your decision. And sometimes it has simply learned not to move without you.
What “for review” can hide
Ask the person who sent you the paper what they recommend. Quite often, the answer comes immediately.
“I would choose option two.” Then ask why. Usually they can explain that too. They know the trade-off. They understand the risk. They know what they would do.
The specialist who sent the options can usually name the one they would choose. What is missing is permission to own that choice.
The analysis was never the missing piece. What was missing was permission to own the decision.
There are good reasons for decisions to come upward. A choice may change the programme date. It may require more funding. It may create risk for another workstream, commit the organisation externally or cross a risk threshold that belongs with the programme leadership.
Those decisions should come to you.
The problem is when everything does.
When every recommendation turns into a request for approval, your calendar becomes part of the critical path.
One question that sorts the pile
When something arrives for review, ask: “What happens if I do nothing for a week?”
There are usually three answers.
1. Nothing happens
The work continues. You were copied because somebody wants you informed. That is fine. It is information, not a decision. Treat it that way.
2. The work genuinely stops
There is a trade-off nobody below you has the authority to make. Perhaps the decision changes cost, scope or timing. Perhaps two workstreams need the same scarce resource. Perhaps it changes the business case, crosses a risk threshold or creates an external commitment.
That decision belongs with you. Make it quickly. The programme is paying for every day it waits.
Ask what happens if you do nothing for a week. Nothing, the work stops, or nobody moves although they could. Only the second one is yours.
3. The work could continue, but nobody will move
This is the interesting category. Nothing material prevents the person from deciding. They have the expertise. They have a recommendation. They are still waiting for somebody more senior to put their name against it.
If this category is large, you do not have a review problem.
You have a decision-rights problem.
Programmes teach people where decisions belong
This behaviour rarely appears from nowhere. A programme teaches people what is safe. If somebody makes a reasonable call and gets overruled in front of their peers, everybody watching learns something.
If nobody says what a workstream lead, architect, or functional owner is allowed to decide, they learn something else.
If a mistake follows somebody around for six months, while escalating everything carries no cost at all, the rational response is obvious. Send the next decision upwards.
Overrule one reasonable call in front of somebody’s peers, and everybody watching learns where decisions are safe to make.
And programme leaders can create this behaviour without meaning to. Reopen enough decisions that were properly made below you, and people stop making the next one.
Ask for “one more review” often enough and eventually every decision arrives with a request for yours. The team slows down while you get busier.
It shows up in the governance too, which is why steering committees fail 48 hours before they meet.
The aim is not delegation
I do not think the answer is simply “delegate more”. Some decisions should stay at programme level. The question is whether they are there by design. A useful rule is to keep decisions at the lowest level that has both the context and the authority to make them.
I would be clear about three things.
You own a decision when it is inside the agreed guardrails for your area and does not create material consequences elsewhere.
Bring me a recommendation when it affects another workstream, changes an important assumption or approaches an agreed risk realisation point.
I will decide when a decision changes the programme’s funding, scope, major milestones, risk profile, benefits case or an external commitment.
The exact boundaries will differ for every programme. What matters is that people know where they are.
A decision-rights split only works when people can repeat it from memory: what they own, what needs a recommendation, what belongs to the programme.
Then change the way work comes upward. Instead of:
Here are three options. Please advise.
Ask for:
Here is my recommendation. Here is why. Here is the risk I am accepting. Here is what changes elsewhere if we proceed. Here is when I need a decision.
That is a very different conversation. You are no longer being asked to become the architect, finance lead or security specialist for an evening. You are being asked to exercise the judgement that belongs at your level.
Where that judgement actually gets exercised is often the meeting before the meeting.
The first mistake matters more than the rule
You can publish the clearest decision-rights matrix in the world. The real test comes when somebody uses it and gets a decision wrong. That will happen.
The question is what you do next. If the response is to take the authority back, require more approvals and make the person explain themselves repeatedly, everybody has learned that the old system still applies.
The safer choice is still to escalate. Correct the decision. Understand what was missed. Change the guardrail if necessary.
Somebody will use the authority you gave them and get a decision wrong. What happens next teaches the programme more than any governance slide.
But if the person made a reasonable decision within the authority you gave them, do not remove that authority simply because the outcome was imperfect. That moment will shape behaviour more than the slide where you explained the governance model.
AI is making this problem more visible nowadays
None of this started with AI. A programme in 2011 could bury its director in options, design papers and requests for review just as effectively as one today.
What has changed is the supply of analysis. AI can produce alternatives, comparisons, draft impact assessments and recommendations in minutes. A team that once brought you three options after several days of writing those up may soon bring you twelve to evaluate before lunch.
But AI has not added another five hours to your day. And it has not answered the organisational question: “Who is actually allowed to decide?”
AI can produce twelve options before lunch.
It cannot say who is allowed to choose one.
That may become one of the less discussed constraints on AI productivity in transformation. If analysis becomes dramatically faster while decision authority remains concentrated, you do not remove the bottleneck. You feed it faster.
And as agents move from producing recommendations to taking action, the question becomes even more important. What may the agent decide? What must stop at a human? Which human? What happens when confidence is low? Who owns the exception?
Those are not only technology questions. They are programme governance questions.
One thing to try this week
For five working days, make a simple note of everything that arrives asking for your review or approval.
Put each item into one of three categories:
1. Information
The work could continue without you.
2. Genuine escalation
The decision crosses a boundary that belongs at your level.
3. Avoidable escalation
The person has the expertise and authority, but the programme has taught them to wait.
Do not worry about creating a perfect framework. Just count them. If the third category is larger than you expected, choose one recurring type of decision and reset the boundary.
Count one week of requests for your approval in three piles: information, genuine escalation, avoidable escalation.
The third pile is the real decision-rights gap.
Tell the people involved what they can decide. Tell them when you want to be consulted. Tell them what must still come to you. Then watch what happens the first time somebody uses that authority and gets something wrong. That is when the programme will find out whether you really meant it.
A programme where every choice reaches one person cannot scale beyond that person’s calendar.
And with AI increasing the speed at which choices can be produced, that limit is only going to become more visible.
— Roman