Fifteen people are sitting in the room.
Three vendors are represented. The PMO is present. Legal has joined remotely. Finance has a delegate. The programme director has prepared 42 slides.
The meeting runs for 90 minutes.
Nobody decides.
The budget issue is “taken away for further consideration.” The scope dispute is “referred to the appropriate forum.” The delivery date is “subject to validation.” Everyone leaves with actions. Nobody leaves with authority.
That is the empty chair problem.
The chair is physically empty, but the real absence is more serious: there is no person in the room with the authority, accountability and confidence to break the deadlock.
This is how the Execution Gap widens:
Strategy → Technology → Execution → Adoption → Business Outcome
The strategy may be sound. The platform may be capable. The vendors may be competent. But if decision rights are diffused across committees, execution stalls before adoption ever begins.
A steering committee is not a status meeting
A steering committee exists to make decisions that the programme team cannot make alone.
It should resolve cross-functional conflicts, approve material changes, allocate resources, accept significant risks and protect the business outcome. It should not spend most of its time receiving status updates that could have been read in advance.
Yet many steering committees operate as reporting forums.
The programme team presents. Vendors defend their position. Business leaders raise concerns. The chair asks for more analysis. A decision is deferred.
Then the same issue returns at the next meeting, usually with higher cost and fewer options.
The problem is not always indecision. Often, it is that nobody has been explicitly empowered to decide.
A committee can contain very senior people and still have no decision authority.
A CIO may attend but lack budget authority. A CFO may be represented by someone who cannot approve the change. A vendor executive may be present but unable to commit delivery resources. A programme director may own the outcome but not the commercial levers needed to achieve it.
That is not governance.
It is attendance.
The uncomfortable truth: consensus is often a hiding place
Transformation leaders frequently ask for consensus.
That sounds responsible. It is often operationally dangerous.
Consensus is useful when the decision is reversible, the consequences are limited and the group has enough time to deliberate. It is a poor operating model for decisions affecting a critical path, regulatory obligation or major budget commitment.
When everyone must agree, the person who disagrees becomes the de facto decision-maker.
The programme waits for the unresolved concern to disappear. It does not. Work continues around the issue, creating assumptions, workarounds and hidden dependencies.
Eventually, the programme discovers that five teams have built five different interpretations of the decision.
The cost is not limited to delay. It includes:
- Rework caused by unresolved design choices.
- Vendor claims created by ambiguous scope.
- Resource capacity consumed by competing priorities.
- Business benefits delayed by missed release dates.
- Loss of confidence among sponsors and delivery teams.
- Increased risk when temporary workarounds become permanent architecture.
The committee believes it is reducing risk by postponing the decision.
In reality, it is transferring risk into delivery.
The three controls every steering committee needs
A functioning steering committee needs more than a charter and a recurring calendar invitation. It needs three operating controls.
1. One empowered decision-maker
Every material decision needs one named owner.
Not “the steering committee.”
Not “the business and technology sponsors.”
Not “the executive team.”
One person.
The committee can provide challenge, evidence and advice. The decision owner makes the call. The owner is accountable for the decision, not necessarily for every task that follows it.
A practical decision-rights register should include:
| Decision | Decision owner | Required input | Escalation trigger | Decision deadline |
|---|---|---|---|---|
| Approve revised scope | Executive sponsor | CIO, finance, programme director | Benefit reduction above agreed tolerance | Five working days |
| Accept residual delivery risk | Business risk owner | Security, legal, technology | Risk exceeds appetite | Three working days |
| Reallocate critical resources | Programme sponsor | Workstream leads, HR | Critical path affected | 48 hours |
| Approve vendor recovery plan | CIO or transformation sponsor | Commercial, PMO, vendor lead | Milestone slip exceeds tolerance | Five working days |
The decision owner must have written authority to commit the organisation.
If an alternate attends, the alternate needs delegated authority. “I will take this back to my boss” is not a decision mechanism. It is a delay mechanism.
The rule is simple:
If nobody can approve the consequence, nobody is empowered to approve the decision.
2. Decision age as a management metric
Most programme dashboards track cost, schedule, scope, risks and dependencies.
They should also track decision age.
Decision age is the number of working days between a decision being formally raised and the decision being closed.
This metric exposes a problem that RAG reporting often misses. A programme can remain “green” while dozens of critical decisions are ageing in the background.
Track at least:
- Number of open decisions.
- Average decision age.
- Oldest open decision.
- Number of decisions past their deadline.
- Decisions deferred more than once.
- Decisions blocking critical-path activity.
- Decisions reopened after being closed.
Set thresholds before the programme becomes distressed. For example:
- 0–5 working days: within normal tolerance.
- 6–10 working days: sponsor attention required.
- 11–15 working days: automatic steering committee escalation.
- More than 15 working days: executive intervention or formal re-baseline.
These are operating thresholds, not universal laws. The point is to make delay visible and measurable.
A decision that is four days old may be routine. A decision that is 20 days old is no longer an administrative item. It is a programme risk.
3. Explicit escalation rules
Escalation should not depend on personality.
The loudest person in the room should not determine what gets attention. Nor should a programme manager have to repeatedly persuade senior leaders that a problem is serious enough to escalate.
Define the triggers in advance.
Escalate when:
- A decision exceeds the authority of the current owner.
- A critical-path milestone is forecast to slip beyond tolerance.
- A risk crosses the agreed business or regulatory appetite.
- A vendor dependency remains unresolved beyond the committed date.
- A decision has been deferred twice.
- The business case changes materially.
- A local decision creates consequences for another business unit.
- The programme cannot proceed without an explicit trade-off.
Each escalation should arrive with four things:
- The decision required.
- The available options.
- The consequence of each option.
- The date by which the decision is needed.
Do not escalate a problem without a recommendation. A steering committee should challenge the recommendation, not reconstruct the analysis from scratch.
Make the meeting decision-first
A steering committee agenda should begin with decisions, not status.
A useful structure is:
- Decisions required today.
- Risks requiring executive action.
- Variances against approved tolerances.
- Delivery evidence and milestone confidence.
- Matters for information only.
Move routine reporting into a pre-read. Use the meeting for choices and commitments.
Every decision item should have a single sentence at the top:
Decision required: approve Option B by 30 September to protect the integration test window.
That sentence changes the quality of the meeting.
It forces the team to distinguish information from action. It also makes it harder to hide behind vague language such as “discuss,” “review” or “consider.”
The committee should record the decision, owner, rationale, conditions and follow-up date before moving to the next item.
If the committee cannot decide because the required authority is absent, the issue should not simply be deferred. It should be escalated immediately to the person who can decide.
An empty chair is a governance defect. Treat it like one.
What CIOs and programme directors should do this month
You do not need another governance redesign lasting six months.
Run a focused decision-rights reset.
Week one: identify the backlog
Review the last six steering committee packs. Extract every open decision, repeated action and deferred item.
Calculate decision age. Identify which decisions are blocking delivery.
Week two: assign ownership
Name one decision owner for every material item. Confirm the owner has authority. If they do not, move the decision to the correct level.
Remove committees that are being used as substitutes for accountability.
Week three: set the rules
Publish thresholds for budget, schedule, scope, risk and escalation. Define the decision clock for each category.
Agree what happens when quorum is missing. Written circulation may be appropriate for urgent, well-documented decisions. Silence should never equal approval for high-risk matters unless the governance charter explicitly permits it.
Week four: change the meeting
Replace status-heavy agendas with decision-first agendas. Track decision age as a standing delivery metric.
Then enforce the rules.
Governance only works when people believe the rules will be applied.
The real role of the steering committee
A steering committee is not there to make every decision.
It is there to ensure the right decisions are made by the right person at the right time.
That requires authority to sit close enough to delivery that issues can be resolved quickly, while keeping enterprise-level decisions visible to accountable executives.
This is the difference between governance and governance theatre.
The Execution Gap is rarely caused by the absence of another strategy document. It is usually caused by a failure to connect authority to action.
If your programme has 15 people in the room but no one who can break a deadlock, the problem is not the quality of the meeting.
The problem is the empty chair.
Book a Delivery Diagnostic with Dark Consultancy to identify where decisions, accountability and execution are breaking down in your programme.
FAQ
What is the empty chair problem in programme governance?
The empty chair problem occurs when a steering committee has many participants but no person with the authority and accountability to make the decision required. The result is repeated deferral, slow escalation and delivery paralysis.
Who should be the empowered decision-maker?
The decision-maker should be the person accountable for the relevant business outcome and authorised to commit the required budget, scope, resources or risk acceptance. The role may differ by decision type, but every material decision should have one named owner.
How do you measure decision latency?
Measure the number of working days from the date a decision is formally raised to the date it is closed. Track average decision age, oldest decision, overdue decisions, repeat deferrals and decisions blocking the critical path.
Should steering committees aim for consensus?
Consensus can be appropriate for low-risk or reversible decisions. For time-critical transformation decisions, a named decision owner is more effective. The committee should provide challenge and evidence, but not allow consensus to become a reason for indefinite delay.
How often should decision rights be reviewed?
Review decision rights when the programme enters a new phase, changes scope, introduces a new vendor, crosses a major delivery gate or experiences repeated escalation failures. At minimum, review them quarterly on complex programmes.
What should happen when the decision-maker is absent?
The absence should trigger a defined delegation or escalation process. An alternate must have written authority to decide. If no authorised person is available, the decision should be escalated rather than silently deferred.
Summary
A steering committee cannot control a transformation programme if it cannot make decisions.
Give every material decision one empowered owner. Measure decision age. Define escalation rules before the pressure arrives. Make the meeting decision-first.
The programme does not need more people in the room.
It needs the right person in the chair.
SEO Details
- SEO title: The Empty Chair Problem in Steering Committees
- Meta description: Learn how decision rights, decision age metrics and escalation rules help steering committees stop delays and restore transformation execution.
- Suggested URL slug:
empty-chair-problem-steering-committee - Focus keyword: steering committee decision-making
- Secondary keywords: programme governance, decision rights, decision latency, transformation execution, escalation rules
- Image alt text: Enterprise steering committee in a modern boardroom with one empty chair representing missing decision authority
- Internal linking suggestions:
- External authoritative source recommendation: Project Management Institute : Escalate Decisions to Project Sponsors
- Recommended schema: Article, FAQPage and Organization schema
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia ; ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn