Collaboration & Process › Communication

Disagree and Commit

Voicing disagreement, then fully backing the decision.

Disagree and commit is a decision practice: people raise concerns while a choice is open, then support the agreed direction once the decision owner has decided. It does not require pretending the disagreement disappeared or staying silent when new evidence changes the risk.

A useful disagreement names the concern and its consequence: “I think this rollout plan can lose updates during backfill; here is the case I tested.” The group can then decide whether to change the plan, run an experiment, or accept the risk. After the decision, team members help execute it rather than repeatedly reopening the same debate without new information.

The phrase can be misused to shut down dissent or pressure people to support an unsafe decision. Clarify who owns the decision, what evidence would trigger reconsideration, and which concerns remain documented. Ethical, legal, and security issues may need escalation rather than quiet acceptance.

Backend, frontend, and data engineers should contribute domain-specific risks early and communicate the decision to affected teams. Commitment means honest execution, not concealing a failure or claiming personal agreement. Revisit the decision when assumptions change. See saying no, project kickoff, and psychological safety.

Choose the channel and amount of detail for the people who need to act, then make important outcomes findable later. If a conversation changes scope or ownership, record that change rather than relying on memory. Backend developers can explain service impact, frontend developers can clarify interaction concerns, and data engineers can make lineage or measurement implications visible.

After trying it, ask whether people had enough context to act and revise the agreement if it created extra coordination or left someone out.