When Two Good Engineers Disagree

Two of my best engineers spent the better part of a week not speaking to each other properly. Not shouting, nothing dramatic. Just clipped Slack replies, meetings where each one addressed me instead of the other, and a pull request that had been open for nine days with forty-one comments on it. The subject was whether we should model our ledger entries as immutable append-only records or as mutable rows with an audit trail. Both of them were right. That was the problem.

I have come to think that how a team handles a disagreement between two strong engineers is a better signal of engineering health than any velocity chart. Weak teams don't have these fights, because nobody cares enough to fight. The dangerous ones are when both people are competent, both are invested, and both have a legitimate case. That is exactly when your process, or the lack of it, gets exposed.

The ledger fight that started this

Let me stay with that ledger example, because it's concrete and it still shapes how I think. Maria wanted immutable append-only entries. Every state change becomes a new row, nothing ever gets updated, and the current balance is a fold over history. Clean, auditable, and it maps beautifully onto how regulators actually think about money movement. Tomas wanted mutable rows with a separate audit log. Simpler queries, less storage, faster to build, and easier for the analytics team to consume without a degree in event sourcing.

Here is the uncomfortable truth: neither position was wrong on the merits. Maria's design was better for correctness and for the audit conversations we'd eventually have with a banking partner. Tomas's design was better for shipping the feature in three weeks instead of seven, which mattered because a client contract was tied to the date. The disagreement wasn't technical ignorance colliding with technical wisdom. It was two correct answers to two slightly different questions, and nobody had made the questions explicit.

Disagreement is a feature, not a defect

I want to be blunt about my bias here, because I think a lot of engineering leadership advice is squeamish on this point. I like the fights. A team where senior people never disagree is not a harmonious team, it's a team where someone has stopped thinking. Usually the more junior of the two, and usually because they learned that pushing back costs more than it's worth.

The cost of suppressed disagreement is invisible right up until it's catastrophic. You don't see the design that didn't get challenged. You see the incident six months later, at 2am, when the thing everyone had a quiet bad feeling about finally breaks. I've sat in enough postmortems to notice a pattern: the root cause is often a decision that one person doubted at the time and didn't voice, because the room didn't feel safe for it or because they were tired of being the one who always objected.

Two kinds of disagreement, and only one is worth your time

Not every disagreement deserves the same treatment, and conflating them is where managers waste enormous energy. I sort them into two buckets, and I try to figure out which one I'm looking at within the first few minutes.

• Reversible and cheap: naming conventions, folder structure, whether to use one HTTP client library or another, tabs versus the correct answer. These are two-way doors. The cost of being wrong is a refactor, and the cost of debating them for a week vastly exceeds the cost of just picking one.
• Irreversible or load-bearing: your data model, your consistency guarantees, how you handle money and idempotency, your service boundaries. These are one-way doors, or expensive-to-reverse ones. Being wrong here compounds. The ledger fight was firmly in this bucket.

The mistake I see constantly is treating a cheap decision like an expensive one, and vice versa. When someone brings me a week-long argument about a library choice, my honest reaction is mild frustration, because that week was a gift they set on fire. But when someone tries to rush a data-model decision to hit a date, I slow everything down, and I don't apologize for it. The skill isn't resolving disagreements. It's diagnosing which ones actually matter.

Disagree and commit is not a magic spell

Everyone quotes "disagree and commit" like it's the end of the conversation. It isn't. It's a specific, demanding discipline that only works if two conditions hold, and most teams that invoke it are missing at least one.

First, the disagreement has to have been genuinely heard. Not acknowledged, not politely noted, actually engaged with on its own terms. If Maria feels her append-only argument was waved away because Tomas talks faster in meetings, "commit" is just a nicer word for "lost." Second, whoever loses the decision has to be protected from being proven right. This sounds strange, so let me be clear about it.

The person who disagreed and committed must never, ever pay a price when their concern turns out to be valid. The moment "I told you so" has social currency on your team, disagree-and-commit is dead, and everyone quietly reverts to defending their turf.

When Tomas's mutable design later needed exactly the kind of reconstruction Maria had warned about, I made a point of saying, in front of the team, that Tomas had made the right call for the constraints we had, and that Maria's foresight was the reason we recovered in a day instead of a week. Both true. Both said out loud. That's the tax you pay to keep people willing to disagree next time.

Someone has to break the tie, and it should usually not be me

There's a fantasy that good teams reach consensus. Sometimes they do, and it's lovely. But two strong engineers with legitimate positions often will not converge, no matter how much whiteboard time you give them, because they genuinely weight the trade-offs differently. At some point the disagreement stops being productive and starts being a standoff. My rough rule is forty-eight hours. If a load-bearing decision hasn't resolved in two days of real effort, it's not going to resolve on its own.

My instinct early in my career was to jump in and decide, because I was the most senior person and deciding felt like the job. I was wrong about that more often than I'd like to admit. When the CTO breaks every tie, you train your best people to escalate instead of resolve, and you slowly become the bottleneck on every hard call. Now I try to name a directly responsible individual for the decision, ideally the person who owns the consequences, and let them decide with both cases in front of them. My job is to make sure the process was fair and the reasoning was written down, not to substitute my judgment for theirs.

Write down the losing argument, not just the winning one

The single highest-leverage habit I've pushed onto my teams is this: when you make a consequential decision, write down the option you rejected and why. Not a triumphant record of the winner. A fair account of the loser. A short design doc with a "considered and rejected" section is worth more than any amount of process ceremony.

The reason is partly institutional memory and partly something subtler. Eighteen months later, when the context has shifted and someone asks "why on earth did we build it this way," the answer is right there, written by the people who actually made the call. Without it, every old decision looks like negligence, and new engineers waste weeks relitigating fights that were already settled with good reasons that simply expired. I've inherited systems with zero decision records, and it feels like archaeology. You're brushing dirt off choices with no idea whether they were brilliant, lazy, or just a Tuesday.

Telling ego apart from substance

I'll admit this is the part I find hardest, because it requires reading people, not code. Some disagreements are about the work. Some are about status, or about someone feeling steamrolled on the last three decisions and finally digging in on this one. The tell, usually, is what happens when you offer new information. An engineer arguing about substance updates when the facts change. An engineer arguing about ego gets more entrenched, because the facts were never really the point.

When I sense it's turned personal, I stop the technical discussion entirely, because you cannot solve a relationship problem with an architecture diagram. I've taken two people for a walk, separately, and asked a simpler question: what are you actually worried about here? More than once the real answer had nothing to do with the ledger or the library. It was "I don't think my work is respected" or "I got burned last time we rushed something." That's a conversation worth having. The technical argument was just the socially acceptable shape it took.

What I tell newly promoted leads

When I hand someone their first team, the disagreement question is the one they're least prepared for, and the one that will define whether people trust them. New leads tend toward two failure modes. Some avoid conflict entirely, smoothing everything over until their strongest engineers stop bothering to raise hard points. Others weigh in on everything, turning themselves into the referee for disputes that two adults should settle in ten minutes.

The advice I give is unglamorous. Most disagreements are cheap and you should get out of the way. A few are expensive and you should slow them down, make the trade-offs explicit, protect the person who might lose, and make sure the reasoning is written where the next person can find it. Learn to tell which is which, and you've learned most of the job. Get it backwards, and no amount of technical brilliance will save you.

Conclusion

Maria and Tomas still argue. They argued last week, in fact, about retry semantics on a payout job, and it was sharp and specific and it made the design better. What changed isn't that they agree more. The argument now costs the team a good hour instead of a resentful week, because we finally built the scaffolding around it. Here's the part I got wrong for years: I used to measure my own progress by how quiet the room got. Fewer fights, better manager. That was exactly backwards. The room I want is one where two good engineers can go at each other hard over something that matters, and walk out still wanting to build the next thing together. If your best people have stopped disagreeing, don't congratulate yourself on the harmony. Go find out what they've decided isn't worth saying.