Two engineers disagree about a technical solution, and neither is ready to move. Consensus is the shared agreement they can reach after hearing different views and weighing the decision together. The goal is to resolve the disagreement without letting one person dominate or leaving important concerns unheard. section 3.1.3
When a disagreement stalls, work toward consensus in stages:
- Give people a chance to resolve it themselves. If the deadlock persists, open a conversation and make room for each perspective. section 3.1.3
- Speak with each person individually when a safer setting would help reveal concerns. Then bring the group together around evidence, constraints, and the broader goal. section 3.1.3
- Ask what each option costs in effort, time, reuse, and resources. If needed, invite a neutral person to offer feedback; keep every opinion in the discussion. section 3.1.3
Consensus is one decision-making method, not a substitute for a decision process. For cross-functional work, clarify who provides input, who makes the final call, which criteria matter, and when a decision is due. Voting, delegation, and consultation may suit different decisions. Agree on how to handle conflict and record the resulting agreement so people have a shared reference. section 9.2.4 section 9.1.5
Choosing a technical approach
One engineer favors a new tool; another favors a different solution. Rather than letting the louder argument decide, their manager holds individual conversations and asks about effort, timelines, reusability, and infrastructure costs. Recognizing the costs of the new tool helps the engineers converge on a solution, resolving the impasse and strengthening trust. section 3.1.3
Agreeing on launch documentation
A product-launch partner wants more detail in an operational readiness document, while another contributor worries about timeliness. They explain their constraints, listen, and agree on a shorter document containing essential metrics and mitigation plans. The compromise supports the launch without treating either concern as irrelevant. section 9.3.2
For a distributed team deciding how to collaborate, review code, and meet, brainstorming and virtual polls can gather views before the team settles on an approach. Seek agreement, but establish final authority early when a project needs a clear way past persistent disagreement. section 3.3.4 section 9.1.5
