Consensus Is Not a Decision

Wrong definition, stated the way most orgs use it:

Consensus means the RFC thread collected enough LGTMs that nobody feels blocked.

That sentence is how teams stall for a quarter while believing they are being collaborative. It treats comfort as if it were choice.

Corrected definition:

Consensus is a mood in a room or a thread. A decision is a recorded pick: one option, one owner, one time after which work proceeds.

If those two stay fused under the word "aligned," every long RFC becomes theater with better manners. This piece unpacks only that distinction. It is not a template guide. It is not a scoring sheet. It is the vocabulary that makes templates worth writing later.

Comfort in the thread is not a pick on the page

The company names below are composite. The word mix-up is not.

Two words that collapse in Slack

Say "we have consensus" in a design channel and people hear "the decision is made." Say "we decided" after twelve LGTMs and people hear "the architecture is settled." Neither statement names an option.

Consensus can be useful. It can lower friction after a pick. It cannot replace the pick. When you ask "do we have consensus?" before you ask "which option did Jordan select?", you are polling mood.

A decision answers a different question: which option is binding, who owns that binding, and when did it become binding? If any of those three is blank, you do not have a decision. You have a conversation that felt finished.

Why LGTM feels like authority

LGTM is borrowed from code review. On a pull request, LGTM usually means "this change may merge under the author's ownership." The author still ships. The reviewer is not the decider of product direction. The merge button is.

On an RFC thread, there is often no merge button. There is no single commit that encodes the pick. So LGTM drifts. It becomes social cover: "I was present; therefore the group chose." Presence is not selection.

LGTM on a PR vs LGTM on an RFC

In code review, ownership is clear: the PR author lands the change. In RFC review, ownership is often fog. Who is allowed to end the debate? If the answer is "the thread," you have outsourced the decision to whoever has the most stamina.

That is why a quiet thread after forty comments feels like consensus. The loud options exhausted themselves. Exhaustion is not selection either.

Consensus optimizes for belonging

People seek consensus because dissent is socially expensive. A named decision makes winners and losers visible. A soft "seems aligned" lets everyone keep face. Leadership that only protects face will never close architecture questions that have real trade-offs.

Consensus-seeking shows up as:

• Expanding the reviewer list until someone friendly reacts
• Rewriting the title to be less sharp so fewer people object
• Waiting for the person who disagrees to go on leave
• Archiving the doc because "energy moved on"

None of those acts picks an option. They manage belonging. Belonging matters on a team. It is the wrong instrument for binding a platform contract.

Belonging loop vs decision write-back

A decision optimizes for downstream clarity. Tickets need an option. ADRs need an option. On-call needs to know which path is live. Clarity creates a different social cost: someone must put their name next to the pick. That cost is the job.

A decision has three anchors

You can test any "we decided" claim in thirty seconds.

1. Option. Which of the named alternatives is binding? If the document only has a theme, there is no option.
2. Owner. Which human is accountable for that binding? A team name is not an owner.
3. Time. When did the binding start? If there is no date, the debate can reopen forever.

Three anchors of a decision

Miss the option and you have vibes. Miss the owner and you have a rumor. Miss the time and you have a reversible suggestion wearing permanent language.

Consensus needs none of these anchors. That is why it is easy to claim and hard to operationalize.

What consensus is still good for

After a decision lands, consensus language is fine: "the payments leads support Jordan's pick." That is endorsement of a decision that already exists. Before the pick, the same sentence is a substitute. Sequence matters. Endorsement after selection strengthens execution. Endorsement before selection replaces selection.

How the mix-up burns a quarter

Composite week. Edge delivery for checkout.

Week 1: long RFC titled "Improving edge delivery." No option list. Thread fills with LGTMs and latency anecdotes.

Week 3: Slack announces "we seem aligned on edge." Still no named option in the file.

Week 6: engineering opens tickets that assume edge POPs. Another team opens tickets that assume regional origins. Both cite the RFC.

Week 9: the conflict surfaces in planning. A new RFC appears with a softer title. The old thread is called "prior art."

Nobody lied. Everyone had consensus at some point. Nobody had a decision with three anchors. The roadmap paid for the vocabulary error.

Same quarter: consensus claimed, two builds

The fix in that week was not a better template. It was forcing the sentence: Jordan selects regional origins on 11 April; ADR-42 records it. After that sentence existed, consensus talk became optional. Before that sentence, consensus talk was the whole product.

Read the document backwards

Most people open an RFC at the background section. That is how design dumps win attention. If you are checking whether a decision exists, read backwards.

1. Find decision / status / "we will ship X."
2. Find the human name attached to that line.
3. Find the date.
4. Only then read options and rationale.

Read order for decision hunters

If step 1 fails, stop reviewing prose. Ask for a decision sentence. Reviewing a novel that cannot state a pick trains the org to produce more novels.

This is the opposite of a forward template walk. You are not learning how to write RFCs from scratch here. You are learning how to refuse fake closure.

When engineers say "aligned," translate

Engineers are often the bilingual speakers in the room. Product hears "aligned" as green light. Legal hears "aligned" as residual risk accepted. Engineers hear "aligned" as "stop arguing in public."

Translate out loud:

Translation is leadership work. Without it, polite words ship conflicting workstreams.

I would rather be blunt once than fund two implementations of a non-decision. Bluntness without a named owner is just another mood. Name the owner when you refuse the fake consensus.

Keep the words expensive

If every chat ends with "consensus," the word dies. If every doc is an "RFC," the label dies. Spend both words only when the three anchors are present or explicitly being requested.

A short decision record can look like this when the debate is over:

decision: regional_origins
owner: jordan.lee
decided_on: 2026-04-11
supersedes: rfc/2026-03-edge-delivery

That block is not a process religion. It is proof the vocabulary changed from mood to pick. Until a block like it exists, do not say you decided. Say you are still seeking consensus if you must. Better: say you are still deciding.