Disagreeing Well

Disagreement is most of the value a senior engineer adds, and the way it is delivered decides whether it lands or costs you influence.

Separate the idea from the person. "This approach has a failure mode under partition" is about the design. "You didn't think about partitions" is about the author, and it converts a technical conversation into a defensive one.

Steelman first. "If I understand it, you're choosing multi-leader so European writes stay local — that's a real benefit." Demonstrating you understood the proposal before objecting is what buys you the right to object. Skipping it means the rest of your argument is heard as not having read the document.

Argue from consequences, not preference. "I prefer Postgres" invites a preference war. "We'd need cross-table transactions for the billing flow, which this store doesn't support" is checkable, and checkable claims resolve.

Calibrate your strength of opinion explicitly. "Weak preference, happy either way" and "I think this is a serious mistake and want to escalate if we proceed" are both useful, and being unclear which one you mean wastes everyone's time. Teams work far better when people state confidence honestly.

Disagree and commit, genuinely. If the decision goes the other way, support it — and note the specific thing that would change your mind: "I think the write throughput will be the constraint; let's revisit if we cross 5k writes per second." That converts a lost argument into a tripwire, which is more valuable than winning.

Escalate on principle, not on emotion. Escalation is appropriate for consequential, hard-to-reverse decisions. Escalating everything spends credibility you will want later.