---
title: "The steering committee that steers nothing"
url: "https://vucale.com/blog/the-steering-committee-that-steers-nothing"
description: "A monthly committee receives status slides and approves everything, while the decisions that mattered are taken elsewhere or not at all. How to run one that steers."
---

# The steering committee that steers nothing

October 20, 2026·4 min read·Editorial team

A young presenter stands at a bright meeting table with pastel printouts in front of a small group, while a colleague at the end of the table looks at a single unmarked card in her hand

The steering committee for the data programme meets on the first Thursday of the month. Eight people, one hour, forty slides. The programme manager walks through the status: the integration is amber but recovering, the training plan is on track, the budget is within tolerance. Two questions are asked, both answered. The chair thanks everybody, the minutes record that the status was noted and the next phase approved, and the meeting ends ten minutes early.

Three weeks earlier, the warehouse team quietly stopped using the new stock report because the numbers did not match the one they trusted. Two days before the meeting, the vendor and the programme manager agreed to drop a reporting module to protect the go-live date. Neither item appears on the forty slides. Both are decisions. Neither was taken by the committee.

The committee is not negligent. It is doing exactly what it has been set up to do, which is to receive information. Nothing in its design gives it anything to decide.

## Why committees go passive

**There is no decision backlog.** The agenda is a status report, so the committee’s job becomes listening to one. If nobody keeps a list of open decisions with a date by which each one is needed, the meeting has no natural content other than being told how things are going, and being told how things are going produces nods, not choices.

**Every proposal arrives alone.** A single option, recommended, with the risks of not approving it. A committee shown one option can only approve or delay it, and delay looks obstructive, so it approves. A real decision needs at least two credible alternatives and an honest account of what each one costs.

**The cost of delay is never stated.** Deferring a decision to next month feels free. It is not: the team waits, the vendor bills, the window in which the change could still be shaped closes a little more. Because nobody prices the month, the committee treats a deferral as the safe choice.

**The hard things are settled before the room.** The programme manager cannot afford a surprise in front of the sponsor, so anything contentious is resolved beforehand in corridors and one-to-ones. The committee then sees a clean story and confirms it. Governance has happened; it just has not happened here.

**Status is reported as colour, not as consequence.** Amber tells the committee that something is late. It does not tell them what will not be delivered as a result, who will notice, or what the committee could do about it. A colour invites concern; a consequence invites a choice.

**Nobody on the committee loses anything.** The people whose work changes, whose budget pays and whose team gives up a person are rarely in the room. The ones who are can approve at no personal cost, and a body that bears no cost rarely says no.

## What a committee should actually decide

**Scope cuts, explicitly.** When the plan is late, something gets dropped. The committee should be the place where it is decided what, in the open, with the people who will miss it. A module removed in a corridor to protect a date is the single most common hidden decision in a programme.

**Stop or continue, at fixed points.** Every phase should end with a genuine question: given what we now know, do we carry on, change direction, or stop. If the answer is always continue, the question was never real. The honest version includes stopping, as the [article on measuring the baseline](https://vucale.com/blog/measure-the-baseline-before-the-ai-pilot) argues, and needs numbers to be worth asking.

**Who moves to the team.** The scarcest resource in any transformation is the handful of people who understand how the company works, and they are already busy. Taking one of them off the day job for a quarter is a decision only the committee can take, because only the committee has the people who own both sides of the trade.

**Which conflict gets resolved, and how.** Two departments that disagree about a definition, a process owner who will not change the process, an IT policy that blocks the pilot. These do not resolve themselves at the working level. They are what the senior people in the room are for.

**What the next decision is.** Each meeting should end by naming the decisions the next one will have to take, so the material can be prepared as options rather than as status.

## How to run one that steers

Put the decision backlog on the first slide and the status in an appendix sent two days before. Anybody who needs the status can read it; the hour is for choices. For each decision, require two or more options, the cost of each, and the cost of deciding a month later. Record decisions as decisions, with an owner and a date, rather than as “noted”. Invite the people who bear the cost of the change, not only the people who sponsor it. And when a phase ends, make stopping a written option with a named advocate, so that continuing has to argue its case.

A committee run this way is less comfortable and shorter. It is also the only version that justifies eight senior people in a room every month.

## A test you can run before the next meeting

Take the minutes of the last three steering committees and list every item recorded as decided. Beside each, write down who proposed it, how many alternatives were presented, and what would have changed if the committee had said no.

Then list the three most consequential things that happened in the programme over the same period: a feature dropped, a deadline moved, a team that stopped using something. Check whether any of them appears in the first list. If the decisions that mattered were not the decisions the committee took, the committee is reporting, not steering, and the next one is the place to change that.

This is governance as change work, which is why it sits inside [how VUCALE works](https://vucale.com/) rather than beside it. The same question returns with more force when a pilot has succeeded and the company must decide whether to scale it, which is the subject of [the next article](https://vucale.com/blog/the-pilot-worked-scaling-is-a-different-project).

-   governance
-   steering committee
-   decisions
-   programmes

## Keep reading

-   [Agent factories will not stay in IT](https://vucale.com/blog/agent-factories-will-not-stay-in-it)
-   [The pilot worked. Scaling is a different project](https://vucale.com/blog/the-pilot-worked-scaling-is-a-different-project)