Nobody sets up a steering committee to slow things down. They get created because someone senior wanted visibility into big decisions, or because a previous surprise convinced leadership they needed a gate. Reasonable impulses, every time.
But somewhere between the first meeting invite and the twelfth monthly review, a cost accumulates that nobody tracks. Product teams lose speed. Bold proposals get sanded into safe compromises. The people closest to the customer stop pushing for change because they've learned the answer: "Let's take it to steering."
I call it the Steering Committee Tax. And most organizations have no idea how high it is.
How governance becomes a tax
Here's the lifecycle. Someone says "we need more oversight on product decisions." A steering committee is formed, a recurring meeting lands on the calendar, and the stakeholder list keeps growing from there.
In the beginning it works. People feel informed. Decisions feel safer.
Then the committee becomes a standing gate. Nothing ships without a green light from the group. The agenda gets packed and items start getting pushed to next month's meeting. The body created to reduce risk becomes the single biggest source of delay.
I've seen product decisions that could have been made in a day take six weeks. Three committees needed to weigh in, each meeting monthly, each wanting a slightly different version of the same deck. By the time the decision landed, the context was stale and the team had mentally moved on to the next thing.
This is the norm in most organizations with more than one product team.
Every new governance layer adds latency. And every layer removes context, because the people deciding are further from the problem than the people proposing. This is the hidden trade-off I wrote about in Operating Model Design: Why Structure Decides How Strategy Executes — the operating model is what actually decides who makes which calls, regardless of what the org chart says.
Where decision authority actually sits
On paper, product teams own the product. The org chart says so, the role descriptions say so, the town hall slides say so, and the CEO repeats it in every all-hands.
The meeting calendar tells a different story.
When a Head of Product needs a committee's permission to prioritize a feature within their own domain, the operating model contradicts the stated ownership. When a CPO presents a quarterly plan that gets sent back for "more alignment," the actual decision authority sits somewhere that never shows up on an org chart.
This is common in organizations that grew fast or went through mergers. It's just as common in traditional hierarchical corporations, where every decade has added another layer of oversight and nobody has ever removed one. Governance layers were added as reactions to specific incidents. Somebody shipped something that went wrong, so a review was created. Another team made a decision that surprised leadership, so an approval gate was added. Each one made sense at the time. Nobody looked at the total.
The result: product teams that are nominally empowered but operationally dependent on committees that meet too rarely and know too little about the specifics.
Nobody on the steering committee is doing anything wrong. They're doing exactly what they were asked to do. The structure is the problem.
The cost nobody counts
Organizations measure product team velocity. They measure time-to-market. They measure feature throughput. Few organizations measure how much time decisions spend in governance queues.
If you tracked a single product decision from the moment someone proposed it to the moment it was approved and work began, you'd find weeks of latency that appear nowhere in any dashboard. Waiting for the next committee meeting. Preparing the deck. Revising after feedback. Waiting for the follow-up meeting.
That's the direct cost. The indirect cost is worse.
Your best product people leave when they can't make decisions. They join smaller companies where they can actually ship. You don't see this in governance metrics. You see it in exit interviews, if you read them.
Teams stop proposing bold ideas. When the approval path is long and uncertain, the rational response is to propose things that are easy to approve. Incremental. Safe. Committees default to consensus, and consensus defaults to "do less." Over time, the entire product portfolio drifts toward the median.
And there's the opportunity cost. While three committees debated whether Feature X fits the strategy, a competitor shipped something similar. The window didn't close because you made a bad decision. It closed because you didn't make one fast enough.
The gap between development speed and governance speed used to be tolerable. Building a feature took a sprint or two, and a monthly committee review was annoying but not catastrophic. That arithmetic has flipped. With AI in the loop, what used to be a month of work is now a week, sometimes a day. The dev team can ship five iterations while the steering committee is still rescheduling its first meeting on the original proposal. Monthly governance on AI-accelerated development is past slow. You're losing in slow motion.
Organizations with clear decision rights ship faster. The difference isn't talent. It's that their decisions don't have to survive a tour of meetings before anyone acts on them. A related pattern shows up in how budget cycles distort product decisions — I unpacked it in Your Budget Structure Is Your Real Operating Model.
Redesigning decision authority without removing governance
This doesn't mean removing all governance. It means redesigning where decisions get made.
Start with one question: is this decision reversible?
Reversible decisions should be made by the team. If you try something and it doesn't work, you change it. The cost of a wrong decision is low. The cost of a slow decision is high. Most product decisions fall into this category. Feature scope, prioritization within a quarter, UX changes, pricing experiments. These don't need committee approval. They need team judgment.
Irreversible decisions deserve more scrutiny. Entering a new market or shutting down a product line belongs in this category. These should go through a deliberate review. But "deliberate" doesn't mean "slow." It means the right people with the right context making a decision in days, not months.
Here's what this looks like in practice. One client had four monthly steering committees covering different aspects of the product portfolio. We mapped the decisions each committee had made in the previous six months. Most were confirmations of what the product teams had already decided. The committees weren't adding judgment. They were adding delay.
We replaced the four monthlies with a weekly 30-minute exception review. Same people, different structure. Product teams decide by default. If something feels risky or cross-cutting, they flag it. The weekly review handles exceptions. Everything else moves.
Same oversight. Decisions in days instead of months.
What made it work was defining decision rights explicitly. Not in a 50-page governance document. In a one-page table: this type of decision, this person decides, this is the escalation path. When people know who decides, they stop routing everything through committees. I've written more about this pattern in Operating Model: Enabling or Killing Strategy.
The test: does your operating model trust your product teams?
Three questions. Answer them honestly.
Can your product team ship a feature without committee approval? If the answer is no for any feature regardless of size, the committee isn't providing oversight. It's providing control. There's a difference.
When was the last time a steering committee approved something the product team didn't already support? If you can't remember, the committee is a rubber stamp with a six-week delay. You're paying for process, not decision quality.
If you removed one approval layer tomorrow, what would actually go wrong? Think about this carefully. Not what might theoretically go wrong. What would actually happen, based on what you know about your teams and your products.
If the answer to that third question is "probably nothing," that's where I'd start.
I'm Jenni. Most strategies stay vague. I help organizations define what their strategy actually means in practice, then build the operating models, processes, and concepts to execute it. Founder of Digital Rebel.