Stop “Design by Committee” in Architecture
Keep stakeholders involved without turning every decision into a meeting series
If you’re a CIO choosing between ‘the architecture review board as the gate’ and ‘empowered teams with guardrails’, use the matrix above and pick your default. If decisions keep bouncing between recurring meetings, and every stakeholder feels like they get a vote, you’re living the design-by-committee anti-pattern. The good news is you don’t need a dictatorship to fix it. You need clear decision rights, a fast path for input, and a simple way to record the call so you stop re-arguing the same topics next quarter.
What “design by committee” looks like in real architecture work
You don’t usually see it written on a Jira ticket. You feel it. The calendar fills up, the same diagram gets re-litigated, and the “decision” turns into a series of polite compromises that nobody’s proud to own. If you’ve ever left a meeting thinking “Wait… did we actually decide anything?” this is what you’re dealing with.
The symptoms (you can almost hear them)
Every decision needs “one more meeting”
There’s always another stakeholder to “bring along”, another review to “sanity check”, another forum to “socialise the approach”.
Architecture turns into negotiation, not trade-offs
Instead of cost, risk, operability, and time-to-value, you’re bartering preferences: “If we add your requirement, can we keep mine?”
Solutions grow features to satisfy everyone, then satisfy no one
You end up with the “camel” solution: heavy, awkward, and expensive to run. It technically includes everyone’s request, yet it misses the actual goal.
People leave meetings unclear on who decided what
There’s a vague sense of alignment, but no decision owner, no decision record, and no next step that anyone can quote later.
The system gets complex, inconsistent, and hard to operate
More moving parts, more exceptions, more bespoke integrations. The on-call experience gets worse, and delivery slows because every change has hidden dependencies.
Why it happens (good intent, bad mechanics)
Most teams don’t choose this on purpose. It’s usually a well-meaning response to pressure.
Leaders want alignment and risk reduction
When the blast radius is high (security, compliance, shared platforms), leaders understandably want visibility and confidence.
Decision rights are unclear, so consensus becomes the fallback
If nobody can point to a decision owner, the group defaults to agreement-by-exhaustion. It feels safe, but it’s slow, and it avoids accountability.
The architecture review board (ARB) becomes the place where work goes to slow down
Instead of a focused escalation path for “red line” decisions, the ARB becomes a queue. Teams start designing for approval, not for outcomes.
The hidden cost: speed, coherence, and accountability
Design by committee feels polite. Everyone gets heard, risk feels “managed”, and nobody walks out upset. Then the bill arrives in delivery time, system quality, and ownership. You don’t notice it in a single sprint. You notice it when the same decisions resurface, the platform drifts, and teams stop taking initiative because initiative gets punished with meetings.
Speed tax
Lead time balloons because feedback is serial, not parallel
One review triggers another review, which triggers another stakeholder request. Each loop adds days, sometimes weeks, and none of it shows up cleanly on your delivery dashboard.
Teams wait for permission instead of shipping evidence
When the default is “get everyone to agree first”, teams stop running small experiments. They stop bringing options with data. They bring slide decks and hope for a blessing. That’s how architecture governance turns into a queue instead of a capability.
Coherence tax
“Camel architecture”: stitched compromises, no unifying direction
You end up with a solution built from negotiated pieces rather than a clear set of trade-offs. The result usually has extra components, inconsistent patterns, and awkward seams. It works… until it has to scale, or be operated at 2am, or be secured properly.
Accountability tax
When everyone is involved, no one owns the outcome
A group can create a decision, but it can’t carry responsibility the way a named decision owner can. When the outcome is messy, you get finger-pointing or silence — neither helps the next decision.
Decisions are hard to revisit because the reasoning was never captured
Without an Architecture Decision Record (ADR) or similar, you can’t tell whether you’re reversing a bad call or repeating a good one in a new context. So you re-run the debate from scratch, with a slightly different cast, and call it “alignment”.
The fix in one sentence
Separate input from authority, then record the decision so you can move fast without losing control.
Here’s what that looks like in practice: you still invite strong input from security, platforms, data, finance, and delivery, but you don’t pretend it’s a vote. You name a decision owner, timebox the consultation, make the call, and capture the “why” in an Architecture Decision Record (ADR). That’s lightweight governance: fewer meetings, clearer decision rights, and far less déjà vu the next time the topic comes up.
Step-by-step playbook to kill design by committee (without killing collaboration)
You don’t fix this by telling people to “be decisive”. You fix it by changing the operating system: decision types, decision rights, and a simple record of what got decided. Here’s a playbook you can roll out in a week, then tighten over the next month.
1) Define decision types and the escalation line
Start by sorting decisions into three buckets. This stops the ARB (or “governance”) being dragged into everything.
Team decisions: local, reversible, low blast radius
Examples: library choice for a service, minor refactors, feature flags, internal API shaping.
Platform decisions: shared, hard to reverse, multi-team impact
Examples: standard logging pattern, event contracts, shared CI/CD approach, platform authentication method.
Enterprise “red line” decisions: security, regulatory, major spend
Examples: anything touching regulated data, material vendor lock-in, new payment rails, material cost commitments.
One rule that changes everything: if it’s a red line decision, it gets a timeboxed review. Everything else stays with the team. No exceptions “because someone’s curious”.
2) Assign decision rights using DACI or RAPID (pick one)
If you want to stop consensus-by-default, you need a decision model people can remember on a busy Tuesday.
Use DACI when you want a simple model that most teams can apply without training wheels.
(Driver, Approver, Contributors, Informed.)
Use RAPID when decisions span layers and you need clarity on who recommends versus who decides.
(Recommend, Agree, Perform, Input, Decide.)
Quick callout: RACI often fails for decisions because it’s task-flavoured. It tells you who’s “responsible” for work, not who has the authority to decide when opinions clash.
3) Install a single “decision owner” per decision
This is the moment everything speeds up.
One person is accountable for the call
Name them. Put it on the doc. If you can’t name them, you’ve found the real problem.
Many people can be consulted
Consultation is encouraged. Chaos isn’t.
Input is a gift, not a vote
People should feel heard. They shouldn’t feel entitled to a veto.
A practical line to use: “We’ll take input widely, then the decision owner will make the call and record it.”
4) Use a one-page pre-read so meetings become decisions
Most architecture meetings fail before they start: no pre-read, no options, no trade-offs, no decision needed. Fix that and half your committee problem disappears.
One-page pre-read template
Context and constraints (what’s true, what’s non-negotiable)
Options (2–3 max, if you bring 7, you’re not ready)
Trade-offs (cost, risk, time, operability)
Recommendation and “what would change my mind?”
Decision needed today (yes/no plus the selected option)
If the pre-read isn’t ready, don’t hold the meeting. You’re just creating calendar noise.
5) Record the decision with ADRs (lightweight, searchable)
This is how you stop re-arguing decisions every quarter.
Store ADRs with the code or in a shared repo
Somewhere searchable, versioned, and easy to link.
Keep them short: context, decision, consequences
You’re writing a memory aid, not a novel.
Link ADRs to principles and standards when relevant
That way the decision isn’t floating on vibes; it’s connected to the operating model.
The win here is cultural: teams learn that decisions are made once, recorded, and revisited only when assumptions change.
6) Turn the ARB into a service, not a gate
An ARB can be useful. The problem is when it becomes the choke point.
Office hours for early advice
Bring rough ideas early and get directional feedback before it becomes a political document.
Async review with a 48-hour SLA for red line items
Give teams a predictable path. Timebox the feedback. Move on.
Publish “approved patterns”
If you keep re-reviewing the same choices (logging, auth, secrets, networking), publish the patterns and let teams reuse them without re-litigating.
Net result: better architecture governance, less theatre, and teams that can actually deliver.
A simple checklist you can copy
Paste this into your project space and use it at the start of any architecture discussion. It’s a quick way to spot when a healthy consult is turning into committee mode.
“Are we drifting into committee mode?”
Do we know who decides (a name, not a group)?
Is the decision reversible? If yes, why is it stuck?
Are we debating preferences instead of constraints (security, cost, time, operability)?
Are we missing architecturally significant requirements (security, latency, audit, availability, data retention)?
Did we timebox consultation (who gets input, by when)?
Will we publish an ADR within 24 hours of the decision (context, decision, consequences)?
What to say in the room
You don’t need to “win” the meeting. You just need to steer it back to a decision. These lines keep things respectful while still moving forward.
When the meeting starts to spiral
“Let’s separate concerns from decisions. What input do we still need, and who’s deciding today?”
“If we can’t name the decision owner, that’s the real problem.”
“Quick reset: are we here to explore options, or to decide one?”
When someone wants a vote
“Happy to take your input. We’re not voting, we’re trading off.”
“Let’s capture your concern as a constraint. Then the decision owner can weigh it with the others.”
“If this is a veto, say it plainly; otherwise, it’s input.”
When someone raises risk late
“Great catch. Is this a red line risk? If yes, we escalate. If no, we document and proceed.”
“What would need to be true for this risk to be acceptable?”
“Let’s record it in the ADR with a mitigation and an owner, so it doesn’t vanish after this call.”
Closing: your operating model in 3 bullets
Clear decision rights (DACI or RAPID), with named decision owners
Lightweight governance (ARB for red lines only, timeboxed so delivery keeps moving)
ADRs as memory (so you don’t re-litigate the past every quarter)
If you want more patterns like this, follow and subscribe to the newsletter. I share practical architecture operating models you can run on Monday morning.