What is a technical steering committee and when does a company need one?

A technical steering committee is a group that makes cross-team technical decisions, usually about architecture, standards, shared infrastructure, and choices that affect multiple engineering teams at once. A company needs one when individual teams are making the same decisions independently and arriving at different answers, or when a decision affects multiple teams but no single team owns it. Without a committee, those decisions either stall or get made by whoever is most opinionated.

Who should be on a technical steering committee?

The people who have to live with the decisions. That means technical leads or staff engineers from the teams most affected by the kinds of decisions the committee will make, the person responsible for the overall technical direction of the company, and in some cases a product leader who can describe the business constraints a decision has to work within. Keep the group small enough to reach a decision in a meeting: five to seven people is a practical ceiling. A larger group can advise, but only a small group can decide.

What decisions should a technical steering committee own?

Decisions that cross team boundaries and would otherwise be made inconsistently. Architecture choices that affect how systems connect to each other. Standards for how teams do common tasks, like authentication, logging, or deployment. The choice of a shared platform or service that multiple teams will depend on. The technical steering committee should not own decisions that belong to a single team, like the internal design of that team's service, because owning those decisions makes it a bottleneck without adding value.

What decisions should a technical steering committee not make?

Anything a single team can decide for themselves without affecting other teams. The internal architecture of a team's own service. The choice of a testing library one team will use. Implementation details that do not cross system boundaries. When a steering committee starts reviewing decisions at this level, it becomes a gate rather than a decision-maker, and the value it was supposed to provide disappears into coordination overhead.

How often should a technical steering committee meet?

Often enough that decisions do not stall waiting for a meeting, and not so often that the meeting itself becomes a burden. For most teams, two weeks is a reasonable default. The more important question is whether the committee has a process for handling urgent decisions outside the regular meeting, since forcing every decision to wait for the next scheduled date will push teams to route around the committee entirely.

How do you prevent a technical steering committee from becoming a rubber stamp?

Give it real decisions to make, with real consequences, and require it to make them rather than to advise. A committee that only reviews decisions already made by others is a rubber stamp by design. A committee that owns the final call on cross-team technical choices, and is accountable for those choices over time, has the structure to make real decisions. The accountability part matters: if the committee's decisions are never revisited or evaluated, there is no cost to approving everything.

How do you prevent a technical steering committee from becoming a bottleneck?

Define what goes to the committee and what does not, and enforce the boundary. If teams learn that any technical decision can be escalated to the committee, they will escalate rather than decide, because escalation moves the accountability. Write down the categories of decision the committee owns. For anything outside those categories, the team decides and the committee does not review. Publish the boundary so it is clear before anyone escalates.

How should a technical steering committee handle disagreement?

State the disagreement clearly, record the reasons each position rests on, and make a decision rather than deferring it. The purpose of the committee is to end the disagreement with a decision the organization will act on. A deferred disagreement is not a resolved one, and unresolved disagreements resurface repeatedly until someone forces a close. If the committee genuinely cannot decide, that is a signal that the question is not ready, and the next step is to identify what information would make it decidable.

What should a technical steering committee's output look like?

A written record of each decision, the options that were considered, the reasons for the choice, and the date it was made. A decision without a written record gets relitigated every time a new person joins the team or the original participants disagree about what was decided. The record does not need to be long, but it needs to exist and be findable. One paragraph per decision, stored where engineers can find it, is enough.

How do you know if a technical steering committee is working?

Cross-team technical decisions happen without stalling. Teams do not build conflicting versions of the same infrastructure. The same question does not get raised and deferred repeatedly. Engineers know where to bring a cross-team technical question and get an answer within a known timeframe. If those things are not true, the committee exists but is not functioning, and the question is whether the structure or the participation is the problem.

How to run a technical steering committee: Reveneau

A technical steering committee exists to solve a specific problem: decisions that cross team boundaries and would otherwise be made inconsistently, stall indefinitely, or get made by whoever is most persistent. The committee brings the right people together to make a call, records the decision, and moves on.

Most technical steering committees do not work this way. They meet regularly, they discuss things, and they produce recommendations that may or may not be followed. The decisions that were supposed to come to them get made elsewhere, because the committee is too slow, too large, or too advisory to be the place where things actually close.

Here is how to build one that makes real decisions.

Define what it owns

A committee that can review anything owns nothing. The first step is to list, specifically, the categories of decision the committee makes the final call on. This is a short list: usually three to five categories. Architecture choices that cross system boundaries. Standards for how teams do common tasks, like how services authenticate or how they log errors. The choice of a shared platform that multiple teams will depend on.

Write this list down and publish it. Any decision in one of these categories goes to the committee. Any decision outside the list, the team makes on its own. The boundary has to be enforceable: if engineers cannot tell from reading the list whether a given decision belongs to the committee, the list needs more specificity.

This boundary protects the committee from becoming a gate on individual team decisions. When a steering committee starts reviewing choices that belong to a single team, like the internal design of that team's service, it adds latency without adding value. The team has to wait. The committee has to review something it does not understand as well as the team does. The result is slower decisions and no better ones.

Keep it small enough to decide

A group of five to seven people can reach a decision in a meeting. A group of twelve cannot. For every person added beyond the core group, the meeting spends more time on context and less on the decision.

The right people are the ones who have to live with the choices. Technical leads or staff engineers from the teams most affected by the committee's decisions. The person responsible for the overall technical direction of the company. In some cases, a product leader who can speak to the business constraints a technical decision has to work within.

Advisory roles are different from decision roles. If there are more than seven people who need to understand the decision, some of them can be informed after it is made. Only the people who make the call need to be in the room.

Give every decision a close

The purpose of a meeting is to leave with a decision, not with a plan to decide. That sounds obvious. It rarely happens without structure.

Before each meeting, the person who brought the decision prepares a one-page write-up: the question, the options, the tradeoffs, and a recommended choice. The meeting is not for presenting this document. It is for questioning the analysis and closing on an answer. If the committee arrives without having read the write-up, the meeting turns into a presentation, which is a different activity from decision-making.

If the committee genuinely cannot decide, the right output is to name what information would make the decision possible, assign someone to get it, and set a date to close. A deferred decision is not a resolved one. Decisions that are deferred repeatedly are usually decisions where nobody has made the case clearly enough, or where the committee does not have the authority it needs to make the call.

Record everything

A decision without a written record gets relitigated the next time the topic comes up. New engineers join who were not in the room. Original participants remember different things. The technical context changes and nobody remembers whether the original decision accounted for the new situation.

The record does not need to be long. For each decision, write down the question, the options considered, the choice made, and the date. One paragraph. Stored where engineers can find it. When someone questions the decision six months later, the record is the starting point, not a conversation about what people remember.

This record also makes the committee accountable in the way that matters. If decisions are recorded and later reviewed, the committee can see which calls held up and which did not, and adjust how it makes decisions. Without a record, there is no feedback loop.

Handle urgent decisions outside the regular meeting

A committee that meets every two weeks has a two-week decision latency. For most cross-team technical choices, that is acceptable. For some it is not: a dependency that is breaking three teams needs a resolution faster than the next scheduled meeting.

The committee needs an asynchronous process for urgent decisions. The simplest version is a written proposal, a 48-hour window for comment, and a designated person to close the decision if the committee does not object. This keeps the committee in the loop without requiring a meeting, and it prevents teams from routing around the committee because the committee is too slow.

Routing around the committee is the failure mode to watch for. When teams learn that the committee is reliable for some decisions and slow or absent for others, they start deciding which decisions to bring and which to handle on their own. The categories get blurry. The inconsistency the committee was supposed to solve returns.

What success looks like

A technical steering committee that works produces a few observable results. Cross-team technical decisions happen without stalling. Teams do not build conflicting versions of the same infrastructure. When a question comes up that crosses a team boundary, engineers know where to bring it and expect an answer within a known timeframe.

None of this requires a large committee or a long meeting. It requires a committee with clear ownership, a small enough group to reach a decision, and a habit of recording what it decided and why.

How to run a technical steering committee