Handling Technical Disagreements

I treat disagreement as a search for the best system outcome, not a contest — my rule is that no one should leave a design discussion wondering whether the decision was based on evidence or authority. My first move is to steelman the other person’s design; I repeat their constraints back until they agree I have it right, because half the time I realize I missed a deployment window, a compliance requirement, or an operational angle they were carrying that I had not considered.

When we are still split after that, I propose writing down what "better" actually means for this specific decision — latency targets, operational cost, time-to-ship — and only then comparing options against that shared scorecard. On a recent Spring Boot service we debated caching with Redis versus raw Postgres tuning for a product-detail endpoint. Instead of arguing opinions, we ran a short Gatling test and the numbers showed tuned SQL met the latency bar without adding a new infrastructure dependency, so we documented the reasoning in an ADR and moved on.

If the team picks something I would not choose alone, I commit fully and help it succeed rather than undermining it with passive resistance. The through-line I emphasize is disagree and commit — a fair process followed by wholehearted execution builds more trust than winning every argument. The tip I close with: data settles most debates faster than seniority, and an ADR ensures the next engineer does not reopen the same tradeoff without new evidence.