📝 ESSAY

Most ServiceNow steering committees meet monthly, watch a status deck, nod at the risk slide, and close without deciding anything. The attendance is senior, the preparation is thorough, and the platform drifts anyway. That is not a steering committee, it is an audience.
📍 In Brief
If a member of your steering committee cannot name a decision they made in the last quarter, that seat is decorative. A committee steers when every member carries decision authority, and when defined thresholds route real choices into the room.
Membership lists built from job titles produce audiences, and membership lists built from decisions produce governance.
Years of presenting to these committees, and later serving on them, taught me the tell. The ones that worked never had the best slides, they had the shortest gap between a question being asked and someone in the room owning the answer.
The delivery data makes the point sharper than any anecdote. Across every task that makes up the platform's standard implementation method (over 5,000 per implementation), every task names exactly one accountable role, with no exceptions. The business sponsor, the most senior person at the table, is accountable for four of them, which is 0.1% of the delivery plan, while the platform owner carries 31.3%. Yet ServiceNow's own guidance, and two decades of change research behind it, puts active and visible sponsorship first among the success factors for transformational change. If seniority mattered because of the work it oversees, the sponsor would be the least useful person in the room, when experience says they are the most. So the committee's value cannot come from overseeing work, it has to come from somewhere else.
Steering produces decisions, not reassurance
A steering committee's only product is a recorded decision. Everything else on the agenda is input.
Status can travel by email, and progress reports, milestone charts and risk registers do not need twelve senior people in a room to be read. The meeting exists for the things a report cannot do. It settles which of two competing initiatives gets the scarce people, releases funds beyond what the programme can approve for itself, rules on conflicts the delivery team has no authority to end, and starts and, more importantly, stops things.
Picture the ordinary version of the test. Two workstreams need the same integration specialists in the same quarter, and the programme manager cannot resolve it because the fix costs money or delays a commitment made to another executive. This is precisely the decision a steering committee exists to make, and it is the one a status review quietly defers. The programme absorbs the delay, the minutes record that resourcing pressures were noted, and the committee has functioned as a witness to its own programme slipping.
The working discipline is unglamorous. The agenda names the decisions required before anyone walks in, so members arrive knowing what they are there to settle. Papers land about three days ahead, far enough out that reading them is an obligation rather than an aspiration. The delivery team brings options with the costs and consequences attached, never an open question. And every decision is written down with the date, the owner and the consequence, because an unrecorded decision gets re-litigated the following month.
None of this is sophisticated, which is rather the point. A committee that cannot manage the unglamorous mechanics of deciding will not manage the strategy either.
A seat in the committee belongs to someone who can decide
Choose members for authority and stake, not for representation.
The instinct when forming a committee is to make it representative. Every affected function gets a seat, fairness is preserved, and the room fills with people whose job is to carry information back to the person who could actually have decided. Representation is a reasonable principle for a parliament and a poor one for a body whose purpose is to conclude.
Three tests qualify each member, and they are the same tests ServiceNow’s own delivery method applies. The member has a vested interest in the outcome, so the programme's success costs or rewards them personally. The member has the authority to commit their function, so a yes in the room is a yes in the organisation. And the member has a clear line of authority over the teams the decision touches, so what is decided actually happens. A delegate who attends to observe and report back fails the second test, and every decision that reaches them defers a month while the answer travels up and back down.
The familiar five-role census still stands. A sponsor, a platform owner, executives from the businesses the platform serves, the delivery leadership, and a voice for the suppliers doing the work. But the census is not the design, because titles only tell you who might sit down, while the three tests tell you whether they should. A business unit executive who controls their function's budget belongs at the table. The same title held by someone who must check upward before committing does not, however accurate the representation looks on the slide.
There is also a ceiling on size. Each added seat makes the room fairer and the conclusion slower, and committee size is an explicit trade against decision effectiveness. When a committee grows past the point where it can conclude, it has stopped being a governance body and become a briefing.
The sponsor's power is inverse to their task load
The sponsor owns almost none of the work, and that is the design.
Return to the anomaly of four tasks out of over 5,000. On paper the sponsor barely exists in the delivery plan, and the temptation is to conclude that the role is ornamental. The change research says the opposite, and the resolution is what this essay has been arguing all along. The sponsor matters because of decisions, not tasks.
What the sponsor owns cannot be delegated downward. They decide what value means for the investment, which is the yardstick every other decision is measured against. They unblock what delivery cannot move, the cross-functional obstruction that outranks the programme manager. And they lend their authority to the change itself, visibly enough that the organisation concludes the platform matters. A sponsor who does these three things earns their seat with almost no accountability in the plan at all.
Most sponsors fall short of that standard. Roughly half of delivery teams rate their sponsor's effectiveness as poor to fair, and the leading causes are mundane. Some sponsors are spread across too many concurrent changes, with no capacity left for any of them. Others mistake support for sponsorship, believing that approving the business case and turning up to the kickoff was the job, when the job is deciding and being seen to decide, month after month, in the room.
The platform owner is the sponsor's mirror image. Nearly a third of the delivery plan lands on that one role, which is why the platform owner is the seat most committees get right. The pairing only works because the two roles are different. The platform owner carries the work and escalates what exceeds their authority, while the sponsor holds the authority and receives the escalation. Merge the two, as organisations do when a platform owner is left to sponsor their own platform, and escalation has nowhere to go, because the committee above the programme has become the programme reporting to itself.

Thresholds do the routing
A committee without decision thresholds receives either everything or nothing.
Authority in the room solves half the problem. The other half is deciding which questions reach the room at all, and this is where most committees have no design whatsoever. The mechanism that fixes it is a threshold agreed in advance. Spend above an agreed value comes to the committee, and below it the programme manager decides alone. Changes to timeline or scope beyond an agreed tolerance come to the committee, and inside the tolerance delivery adjusts and reports. Technical questions go to the technical authority and demand questions to the demand authority, so that only what exceeds a threshold, or conflicts across the boards, rises to the steering table.
Skip this design and one of two failure modes follows. Either everything escalates, and senior leadership is dragged into chaotic ad hoc decisions the delivery team should have owned, or nothing escalates, and the committee reviews reassuring decks until the difficult news arrives at go-live with no thresholds left to catch it earlier.
Thresholds also answer the question committees rarely ask until it hurts, which is who decides between meetings. A monthly cadence leaves roughly thirty days in which the programme does not stop generating decisions. The working answer is named people for named domains, an agreed trigger for when the sponsor personally intervenes, and one ultimate point of escalation so that two boards cannot each assume the other is handling it.
Where this doesn't apply
A platform running one workflow for one function does not need this machinery. Where the sponsor and the platform owner can settle direction in a fortnightly conversation, a thresholded committee with formal papers is ceremony, and ceremony at that scale costs more than it routes. The model earns its keep at the point where demand outgrows the people who built the platform, when multiple executives hold competing claims on the same roadmap and no single conversation can arbitrate between them. Most organisations cross that line earlier than they notice.
The bottom line
Do not redesign the committee by revisiting the membership list, audit the seats instead. For each one, ask what this person decided in the last quarter and what threshold routes decisions to them. A seat with no answer to either question, twice running, gets a different occupant or gets removed. The titles can stay on the org chart, but the table is for people who decide.
A steering committee seat is a decision obligation, not a status honour.
P.S. Watch the first agenda after the audit. If "decisions required" is still an empty heading, you have not rebuilt a committee, you have reseated an audience.