How I Handle Disagreements With Other Engineers Professionally

Technical disagreements are normal and often productive. Handled poorly, they damage relationships and produce worse decisions. Here's the approach I've developed over years of getting it wrong first.

Why Technical Disagreements Get Personal

Engineers tend to develop strong opinions. That's partly a professional virtue — the work requires making confident decisions under uncertainty, and developers with no opinions are often indecisive in unhelpful ways.

The problem is that strong opinions can calcify into identity. "I believe X" becomes "I am someone who believes X," and at that point disagreeing with the position feels like attacking the person. This is almost always unconscious. And it's very common.

I've been on both sides of it. I've dug in on positions I knew were defensible rather than right because admitting error felt like losing. And I've watched colleagues do the same, getting more entrenched with each exchange, until what started as a technical discussion became something else.

Start by Understanding, Not Rebutting

When someone pushes back on my technical position, the instinct is to strengthen my case. Add another argument. Address the specific objection. Hold the line.

The more useful first move: make sure I actually understand their position. Not as a rhetorical tactic — genuinely try to reconstruct their reasoning.

"If I understand your concern correctly, you think X because Y — is that right?"

This does several things. It often reveals that I've misunderstood the objection, and the disagreement is smaller than it appeared. It signals to the other person that I'm engaging with their actual position, not a version of it I've constructed. And it occasionally reveals that they're right, which is the best possible outcome.

Winning an argument by not actually engaging with the other person's point is not winning.

Separate the Technical Question from the Relationship

Technical disagreements that go badly almost always involve some degree of relationship friction — a history of previous disagreements, a status difference that makes it uncomfortable to push back, a sense that one person's opinion gets more weight than it should.

I try to keep these dimensions separate. The technical question: which approach is better, and on what basis? The relationship question: do we communicate in a way that maintains mutual respect and enables future collaboration?

You can be firmly opposed to someone's technical position while being genuinely collegial. In fact, that combination — clear disagreement, respectful delivery — is how good technical cultures work. It requires a bit of deliberate effort, especially when you're frustrated or certain you're right.

The signal I try to send: "I'm pushing back on this idea because I think it matters, not because I think you're incompetent." That signal has to come through in tone and framing, not just intent.

Use Evidence, Not Authority

The weakest form of technical argument: "I've been doing this for ten years and this is how you do it." The strongest form: "Here's data, or here's a failure mode, or here's a concrete example."

Experience is evidence — but it's low-quality evidence. Sample size one, potentially confounded by many variables, filtered through memory. "I've seen this go wrong before" is worth saying, but it's not sufficient on its own, especially when someone else has seen different things.

When I'm confident in a position, I try to ask myself: what would actually demonstrate that I'm right? Can I construct a test case? Can I find a documented example of the failure mode? Can I point to benchmarks?

This disciplines my own thinking and shifts the conversation from opinion exchange to evidence exchange. Evidence is easier to evaluate and less threatening to update on.

Know When to Defer and When to Persist

Not every hill is worth dying on. Most technical decisions are reversible — they can be made one way now and changed later if they turn out to be wrong. For these, I've learned to state my position, make the case once clearly, and then defer if the other person or the team makes a different call.

"I still think approach A is better, but I understand we're going with B — let's make sure we know what to watch for." This acknowledges my position, respects the decision, and sets up a way to learn from the outcome.

The cases where I persist: when the decision has real lock-in and the cost of being wrong is high, or when I believe there's a genuine correctness problem the team hasn't fully grasped. Even then, the right form of persistence is making the case more clearly, not more loudly.

Louder is not more persuasive. It's just more friction.

After the Disagreement

How a disagreement ends matters as much as how it goes. If the decision went my way, the right move is to implement it without the victory lap — no "as I said" or "I told you so" if it turns out to work well. If it went the other way, I implement it without residual resistance or passive sabotage.

The unspoken norms around how teams handle the aftermath of decisions are part of their culture. Teams where people implement decisions fully regardless of whether they agreed with the call are more effective than teams where partial buy-in is common. Being a full participant in that culture — even when I lost the argument — is part of being a professional.

The best technical disagreements end with a clearer decision and an intact relationship — and those two outcomes are more compatible than most engineers act like they are.