Guide

Disagreement is how teams avoid shipping the wrong thing. The failure mode is not disagreement. It is disagreement that becomes identity ("my design" vs "your design") or that never resolves. The skill is to fight on the work, decide, and then execute.

Concept

Disagree and commit means you argue hard before the owner decides, then execute the chosen path as if it were yours. Relitigating in Slack after the meeting destroys trust faster than being wrong.

The big idea

A naked "I disagree" forces the room to do your homework. Prefer a packet: shared facts, two or three real options, a recommendation, and whether the bet is cheap to undo.

Steelman first: restate the strongest version of the other position until they say "yes, that's what I mean." Often the conflict was a vocabulary mismatch. When it was not, you still earned the right to push.

Walking through it

  1. Shared facts. Metrics, constraints, deadlines, prior incidents. Agree on reality first.
  2. Options. At least two viable paths, including the one you like least if it is real.
  3. Recommendation. Pick one and say why. Indecision is also a position.
  4. Reversibility. Note what is cheap to undo. People accept more risk when rollback is easy.

Example

Bad: "We shouldn't use Kafka for this." Better: "Options: (A) Kafka — strong for fan-out, +2 weeks ops learning; (B) existing SQS — enough for 10× load, ships this sprint. Recommend B until we have a second consumer team. Happy to revisit if fan-out lands on the roadmap."

Critique the proposal, not the author. "This approach doubles on-call load because…" lands. "You always over-engineer" does not.

Once the right owner decides (tech lead, manager, staff engineer, product), execute fully. Document dissent briefly if the stakes are high ("I preferred B because latency; we chose A; I'll own A"), then stop campaigning. If new data kills your option, say so in public: "I argued for B; the load test shows B melts at 3× — I'm with A." Sandbagging the path you opposed is noticed.

Trade-off

Fight hard before the decision on irreversible bets (data model, public API, security boundary). Save energy on reversible ones (library choice, ticket order). Calibrate intensity to blast radius.

Teammate conflict is usually about expectations, credit, style or load — rarely pure technical truth. Handle it early and privately: write down facts vs inferences, talk 1:1 with SBI-style feedback, propose a working agreement ("PRs over 400 lines get a design ping first"). Escalate to your manager if it repeats. Do not prosecute teammates in group chat.

Common mistakes

  • Identity combat. "My design" vs "your design" instead of options on a shared problem.
  • Relitigating after the decision. Campaigning in Slack after the owner chose.
  • Public shame. Group-chat prosecution creates drama and allies for the other person.

Check yourself

  1. What four pieces belong in a disagreement packet?

Shared facts, at least two real options, a recommendation, and whether the bet is reversible.

  1. The team chose the path you opposed. What do you do on Monday?

Execute it fully. Reopen only with new evidence, not the same argument louder.

Key takeaways

  • Steelman, then argue with facts, options and a recommendation.
  • Intensity tracks blast radius: fight irreversible bets, let reversible ones go.
  • After the owner decides, disagree-and-commit — or reopen with new data.

Further learning

Next: influence without authority.