Skip to main content
Engineering Leadership

Driving Consensus

Ravinder··7 min read
Engineering LeadershipStaff EngineerCareerConsensusDecision Making
Share:
Driving Consensus

The word "consensus" gets misused constantly in engineering organizations. Most of what passes for consensus is actually one of two things: acquiescence (the dissenters give up, not because they are convinced, but because they are tired of arguing) or false unanimity (no one voiced their actual objection because the social cost felt too high). Neither produces durable decisions.

Driving real consensus — shared understanding of a decision and why it was made, with dissent heard and recorded — is one of the highest-leverage skills a staff engineer can develop. It is also one of the hardest, because it requires holding two things simultaneously: moving the decision forward and genuinely engaging with objections.

What Consensus Actually Requires

Consensus does not mean everyone agrees with the outcome. It means everyone understands the decision, had a real opportunity to influence it, and commits to executing it regardless of whether it was their preference.

That last clause is what makes disagree-and-commit more than a management buzzword. The commit is real. Engineers who say "I disagree and commit" and then undermine the decision passively — slow-walking implementation, re-litigating in other forums, building workarounds without escalating — are not disagreeing-and-committing. They are disagreeing and defecting.

Your job as the person driving consensus is to make genuine commitment achievable: give people the information they need, hear the objections seriously, be transparent about constraints, and close the decision cleanly enough that defection is clearly a choice rather than a default.

The Three-Phase Consensus Process

Consensus built in a single meeting almost never holds. The objections that surface in real-time are usually not the objections that matter. What matters is giving people time to think, and having a clear process they can trust.

flowchart TD A[Identify Decision Needed] --> B[Phase 1: Diverge] B --> C[Async RFC / problem framing published] C --> D[5-day open comment window] D --> E[Collect all objections — do not resolve yet] E --> F[Phase 2: Synthesize] F --> G[Group objections by type] G --> H{Objection type?} H --> I[New information that changes the tradeoffs] H --> J[Preference differences within acceptable range] H --> K[Genuine blocker or risk not addressed] I --> L[Update recommendation accordingly] J --> M[Acknowledge, record, proceed] K --> N[Address head-on in doc + meeting] L --> O[Phase 3: Converge] M --> O N --> O O --> P[Synchronous decision meeting — 45 min max] P --> Q[State decision explicitly] Q --> R[Record dissent with attribution] R --> S[Publish decision + rationale]

Phase 1: Diverge

Publish the RFC or problem framing with a clear question: "We are deciding X. Here is my recommendation and reasoning. I am looking for objections to the recommendation, evidence I have not considered, or constraints I have misunderstood."

The framing of the request matters. "What do you think?" produces rambling. "What is wrong with this recommendation, and what evidence supports your concern?" produces useful signal.

Phase 2: Synthesize

Before the convergence meeting, do the synthesis work. Group objections into three categories:

  1. New information — something you did not know that materially changes the tradeoffs. These require updating the recommendation or explicitly showing why the new information does not change the conclusion.
  2. Preference differences — the objector would choose differently but the stakes are low enough that either option is acceptable. Acknowledge these, record them, and proceed.
  3. Genuine blockers — the objector has identified a risk or constraint that your recommendation does not adequately address. These need a real response in the meeting, not a dismissal.

Most objections are type 2. The ones that derail consensus are type 3 that get treated as type 2.

Phase 3: Converge

The convergence meeting has one job: close the decision. Not re-open the discussion, not reach unanimous agreement, not surface new objections that should have been filed during the comment window.

Structure the meeting:

[0:00–0:05]  Recap: decision question, recommendation, key objections received
[0:05–0:20]  Address type-3 objections directly — hear response from objector
[0:20–0:30]  Final round: any new information? (Not preferences — information)
[0:30–0:35]  State the decision explicitly: "We are doing X. We are not doing Y."
[0:35–0:45]  Record dissent: "These engineers disagree for these reasons, and
              commit to executing the decision."

The explicit statement of the decision is not ceremonial. It is the moment where "I think we're going with X" becomes "we have decided X." That precision matters when someone tries to re-open the question three weeks later.

Disagree-and-Commit: Making It Real

Disagree-and-commit only works if the dissenter believes their objection was genuinely heard. This means the record must reflect their objection accurately, not a sanitized version. It also means you must not punish the dissent — not now, not during execution, not at performance review time.

Template for recording dissent in a decision document:

## Decision
 
We will migrate to the event-streaming pipeline by Q3 2026.
 
## Recorded Dissent
 
**@engineer-name** disagrees with this decision. Their concern: the migration
timeline does not account for the batch pipeline's role in end-of-month
reporting, which has a hard SLA. They recommend delaying the migration start
until the reporting dependency is explicitly resolved.
 
**Response from decision owner**: The migration plan includes a carve-out for
the reporting workload. That carve-out is documented in Appendix B. If the
carve-out proves insufficient, @engineer-name is empowered to escalate before
Phase 2 begins. They have committed to executing Phase 1 on schedule.

This level of specificity does two things. It shows the dissenter their concern was understood. And it creates accountability — both for the decision owner to deliver on the stated response, and for the dissenter to escalate appropriately if they see the concern materializing.

When to Escalate Instead of Converge

Not every disagreement should be resolved through the consensus process. Some decisions require escalation — to the EM, to a senior leader, or to a formal architecture review.

flowchart TD A[Persistent disagreement after Phase 2] --> B{What is the nature of the block?} B --> C[Factual dispute — we disagree on what is true] B --> D[Values dispute — we weigh the tradeoffs differently] B --> E[Authority dispute — we disagree on who decides] C --> F[Run a time-boxed spike or experiment to generate data] D --> G[Escalate to the person whose values should govern] E --> H[Escalate to EM or architecture council to clarify ownership] F --> I[Reconvene with results] G --> J[Implement their resolution; record it] H --> K[Follow the clarified ownership; update decision process]

Escalating is not failure. Escalating the right dispute to the right person is how organizations handle genuine value conflicts without personal antagonism. The failure is escalating disputes that could have been resolved locally, or not escalating disputes that genuinely need a higher authority.

Key Takeaways

  • Real consensus means everyone understands the decision, had genuine input, and commits to execute — not that everyone agrees with the outcome.
  • Disagree-and-commit requires the dissent to be genuinely heard and accurately recorded; otherwise it is just managed capitulation.
  • The three-phase process (diverge, synthesize, converge) builds more durable decisions than single-meeting consensus because it gives people time to think.
  • Classify objections before the convergence meeting: new information requires response, preference differences require acknowledgment, genuine blockers require a real answer.
  • The explicit statement of the decision in the convergence meeting is not ceremonial — it is the transition from discussion to commitment.
  • Escalation is the right move for factual disputes (run an experiment), values disputes (escalate to the person whose values govern), and authority disputes (clarify ownership).
Share: