Running a Cross-Functional Steering Committee That Works

A group that discusses cross-functional issues but has no authority to actually decide anything defaults to becoming a status meeting, since discussion without decision-making power just circles the same open questions every time without resolving them. Define explicitly what this committee can decide on its own versus what it can only recommend upward, and if the honest answer is 'nothing, it just surfaces issues,' rename it accordingly rather than pretending it's a decision-making body when it structurally isn't one.

Status updates belong in written form, shared before the meeting, not read aloud during it. The meeting time itself should be reserved for items that genuinely need multiple functions in the room to resolve: a tradeoff between two teams' priorities, a resourcing conflict, a decision that touches more than one function's roadmap. If a topic can be resolved by one person reading a document and replying with a decision, it doesn't need committee time.

For example, suppose product wants to move a launch date and support says it can't staff the change. That belongs in the room, because two functions have conflicting priorities and each holds information the other lacks. By contrast, a note that engineering finished a migration is a status update, and it should circulate in writing beforehand. A simple test for building the agenda: for each proposed item, ask what decision the group is being asked to make and which functions must be present to make it. If nobody can answer, move the item to the written update or drop it. Publish the agenda a day ahead so people arrive ready to decide.

An item that shows up on the agenda five meetings in a row without ever being marked resolved is either not actually a committee-level decision, or the committee is avoiding making a call on it. For every open item, require an explicit outcome at the end of discussion: decided, assigned to someone with a deadline, or explicitly deferred with a reason. 'We talked about it again' is not an acceptable outcome for an item that's been on the agenda for over a month.

End each agenda item with one of these outcomes:

• Decided: the group made the call, and the decision is recorded along with the reasoning behind it.
• Assigned: a named person owns the next step, with a deadline everyone in the room heard.
• Deferred: the group chose to wait, and wrote down the reason and when the item will return.
• Removed: the item turned out not to be a committee-level decision and moved to the right owner.

Decisions made in a meeting and never written down effectively didn't happen, since anyone who wasn't in the room, or who was but has since forgotten the reasoning, has no way to reference them later. Keep a running decision log, in a compliance-adjacent tool like Vanta or Drata if you already use one for governance tracking, so a decision from three months ago can be checked rather than re-litigated from scratch.

A committee's ideal membership and meeting frequency at launch often don't match what the company needs a year later, as priorities shift and some functions become more or less central to the kinds of decisions actually coming up. Revisit both the roster and the cadence at least annually rather than assuming the original structure remains right indefinitely just because nobody has formally proposed changing it.

A group that started with three functional leads and grew to include a representative from every team touched by any decision tends to lose the ability to actually decide anything quickly, since more voices in the room generally means more positions to reconcile before landing on an outcome. If attendance has grown steadily since launch without a deliberate reason, that's worth questioning directly rather than assuming broader representation automatically makes for better decisions. A smaller group that can move fast, with a clear channel for looping in anyone materially affected by a specific decision, usually outperforms a large standing committee trying to cover every base at once in every single session.