Felipe Tavares A team needs to pick a message broker. The proposal visits the domain design authority, which asks for a comparison matrix. Then the security forum, which adds two conditions. Then the architecture review board, which requests alignment with a platform strategy that is itself under review. Then an ad hoc session with a principal architect who was on holiday for the first three. Four forums, eleven weeks, and the decision that finally emerges carries conditions from each, several of them mutually incompatible. Nobody said no. Nobody said yes either.
Ask who owned that decision and you’ll get a list of people who were consulted. The list is the problem. Slow architecture decisions are an ownership problem, and adding diligence to them adds waiting: every extra reviewer arrives with the authority to slow the decision and no accountability for its speed.
Here is what fixing ownership buys the team doing the waiting:
- One named person decides, and you know the name before you write the proposal.
- Vetoes can land only on grounds published in advance, so you can engineer for them instead of guessing.
- The decision has a clock, because a single owner can be asked “when,” while a committee can only be asked “whether.”
An answer in days, from a person, with reasons. That is the entire pitch, and it’s buildable with a framework Bain has been publishing since 2006.
Responsibility matrices manufacture committees
Most organizations that try to fix decision-making reach for a responsibility matrix: RACI, RASCI, or a local variant. The matrix assigns work, and for work it’s fine. Applied to decisions, it quietly builds the committee it was meant to prevent. Everyone holding a letter feels entitled to weigh in; every C is an invitation to schedule a meeting. Accountability, the thing the matrix was bought to create, ends up distributed, which is the polite word for nowhere.
The tell is the question the matrix can’t answer: if this decision is wrong, who was wrong? A RASCI row names five people. Five people can’t be wrong together in any way that changes what happens next quarter.
There’s a second mechanical failure, and the opening scene runs on it: conditions accumulate. A reviewer who lacks the authority to say yes still has to justify the meeting, and the cheapest justification is a condition. Each forum adds one or two, nobody reconciles them, and the proposing team inherits the merge conflict. Malice has nothing to do with it. Participation without ownership produces conditions, every time.
RAPID, quickly
Paul Rogers and Marcia Blenko published “Who Has the D?” in Harvard Business Review in 2006, drawing on Bain’s decision-effectiveness practice. Their RAPID framework assigns five roles per decision, and the letters are jobs rather than seats at a table:
- R, Recommend: builds the proposal and owns its quality.
- I, Input: supplies facts and constraints to the R, with no vote attached.
- A, Agree: holds a veto, and the veto comes with obligations.
- D, Decide: one person who commits the organization to action, in the authors’ words “the single point of accountability.”
- P, Perform: executes what was decided.
Two design choices carry the framework’s force. The D is singular by construction; the moment two people share it, you’ve rebuilt the committee under a new name. And the A is deliberately scarce. Rogers and Blenko warn that “only a few should have such veto power,” and a legitimate veto must come with grounds and an alternative, never a bare no.
The architecture mapping
Apply this to architecture governance and the enabler model turns into something concrete: a role assignment.
Break architecture decisions into classes: technology selection inside one team’s boundary, cross-team interface contracts, deviations from a standard, platform-wide choices. Give each class one D, and place that D where the consequences live. For most classes that means the team that ships and runs the system. They hold the pager; they hold the D.
The central architecture function takes different letters, and takes them deliberately:
- A on the small set of grounds where a local decision can hurt the whole: security, compliance, interoperability. Grounds published in advance, veto exercised with a written alternative.
- R on genuinely enterprise-wide questions, platform choices and cross-cutting contracts, where someone has to do the comparative work honestly.
- I everywhere else: real expertise, offered into someone else’s decision, with no vote attached.
One dispute, worked through
Two teams need an interface contract; each prefers its own event schema. Under forum governance this becomes a standards debate that outlives the feature. Under RAPID it has a shape: the architecture function holds R and does the comparative work in the open, both teams and the platform group hold I, the D sits with the team that will own the interface once it ships, and architecture’s A can veto only on interoperability grounds, in writing, with an alternative attached. The dispute still happens. It just happens once, inside a week, with a named person accountable for the answer.
The gatekeeper-to-enabler shift the industry keeps writing about compresses into one sentence: the central function stops holding every D and becomes a bounded A. Influence then has to be earned the only durable way, through the quality of its R work and its I contributions. An architect whose recommendation keeps being right gets invited into decisions no org chart routes to them.
I’ve been close to a decision process inside a global enterprise that made this move: from board-approval, where proposals queued for a slot and left with conditions, to owner-plus-grounds, where each decision class had a named D and the central function’s veto surface was written down. Decisions got measurably faster, and a quality effect nobody expected surfaced quickly. When the veto grounds are published, teams engineer for them before submitting, so the vetoes mostly stop happening. The opening scene inverts: instead of the decision traveling to the reviewers, the constraints travel to the decision.
What the change costs is honesty about authority. A review board can feel authoritative while deciding nothing. A bounded A with published grounds is checkable: either the veto cited a ground or it didn’t. Some architects experience that as a demotion. The ones who thrive under it are the ones whose influence never depended on the queue.
Decisions on a sprint rhythm
Ownership fixes who decides. Cadence fixes when. A decision class with a named D can commit to a clock: input windows time-boxed, a decision date set when the R work starts, the answer shipped on a rhythm delivery teams can plan around. Rigby, Sutherland and Noble’s “Agile at Scale” documents the same pattern: teams working in small, fast cycles outpace traditional structures on time to market. Bain’s broader decision-effectiveness research ties it together: organizations that decide quickly and well perform better, and deciding quickly is a design property, available to anyone willing to name an owner.
Close each decision with a record: what was decided, by whom, on what grounds, which alternatives lost. The record does double duty. It’s the audit trail that makes the bounded A checkable, and it’s the raw material your standards and defaults get built from. A decision that lives only in the meeting where it happened will be re-litigated by people who weren’t there.
One forward note, because the next readers of your decision-rights map won’t all be human. As agents start participating in engineering work, the letters split cleanly: an agent can hold R, I and P today, drafting recommendations, supplying analysis, executing decisions. D and A stay human. That single sentence is most of an AI governance policy.
Put it to work
Pick one decision class that recurs, the one whose queue your engineers complain about. Write three things on one page: the single D by name, the A-grounds on which a veto can land, and the clock. Publish the page. Route the next real decision of that class through it, and time it against the last one that went through the forums.
Worth taking away:
- Decisions need owners, matrices assign work. If your framework can’t answer “who was wrong,” it isn’t a decision framework.
- Scarce vetoes, published grounds. Teams engineer for constraints they can see, and the vetoes stop happening.
- The D belongs with whoever holds the pager. The central function earns influence through recommendations, and holds its veto for the few grounds that protect the whole.
- Write the decision down. The record kills re-litigation and becomes the seed of your standards.