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.
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.
| Word people say | What they usually mean | What the org actually has |
|---|---|---|
| Consensus | Nobody argued loudly | Shared comfort, no pick |
| Aligned | Thread went quiet | Exhaustion or politeness |
| LGTM | I read enough to react | Attention, not commitment |
| Decision | We can start tickets | Often still missing |
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.
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.
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.
Option. Which of the named alternatives is binding? If the document only has a theme, there is no option.
Owner. Which human is accountable for that binding? A team name is not an owner.
Time. When did the binding start? If there is no date, the debate can reopen forever.
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.
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.
Find
decision/status/ "we will ship X."Find the human name attached to that line.
Find the date.
Only then read options and rationale.
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:
| Heard | Say instead |
|---|---|
| We are aligned | No decision yet; options still open |
| Rough consensus | Mood is calm; pick still missing |
| LGTM from platform | Platform reviewed; Jordan has not selected |
| Let's take it offline | Decision owner still unset |
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.
