Most Technical Arguments Aren't Technical

"He isn't arguing about the queue. He hasn't been arguing about the queue since March."

A principal engineer said that to me in a corridor, about a colleague, roughly four hours of meetings too late. She was right, and I think everyone in those meetings knew it. Nobody said it out loud, because the queue was a respectable thing to argue about and the real thing was not.

A technical disagreement is the socially acceptable container for almost everything that goes wrong between two capable people. Nobody gets pulled aside for caring too much about latency. Nobody's performance review says "argues excessively about idempotency". So when someone feels cut out of a decision, overruled, under-resourced or quietly demoted, the grievance comes out dressed as architecture, and it comes out in a design review, where it's guaranteed an audience and a transcript.

You can usually spot it, and the tells are consistent.

The position doesn't move when the evidence moves. You bring a benchmark, a cost model, a straight answer from the vendor, and the argument sits exactly where it was. Genuine technical disagreements respond to facts. That responsiveness is what makes them technical.

The volume is wrong for the stakes. A decision worth about three days of rework is generating the heat of a decision worth three months.

It keeps returning in new clothes. In April it was the deployment model. In May it's the monitoring stack. Same two people, same temperature, different subject.

And the one that gives it away fastest: one of them keeps raising it in front of other people instead of with the person they disagree with.

The instinct, when two engineers are stuck, is to put them both in a room and get to the bottom of it. Delay that meeting. It reliably makes things worse, because each of them arrives with an audience, a position they've already defended publicly, and no way to move without visibly losing.

Talk to each of them alone first. Twenty minutes each. Two questions, in this order.

"What do you think the actual disagreement is?"

Then: "What do you think they'd say it is?"

The second question does the work. If both describe the dispute the same way, congratulations, you have a real technical disagreement and you can settle it with evidence and a decision. If they describe it differently, and they usually do, the gap between those two accounts is the problem. You now have something specific to define, which is the only place resolution ever starts from.

Stay boringly factual while you do it. No "I can see you're frustrated." No theories about anyone's motives, especially the ones you're sure about. You're collecting two accounts and locating where they diverge, not diagnosing a personality.

A 22-person infrastructure team at a logistics firm, six months into a network refresh across 60 sites. Two team leads deadlocked on whether to standardise on a single SD-WAN vendor or keep the existing dual-vendor estate. Six weeks of it. Three design reviews. Both of them well prepared, both of them right about something.

The written case for dual vendor was resilience and negotiating room at renewal. The written case for single vendor was operational simplicity and roughly 15 per cent off the annual support bill. Neither of them was lying. Neither of them was moving.

What came out in two separate twenty minute conversations: the reorganisation in January had taken four engineers off the dual-vendor lead's team, and every one of his remaining six had spent their careers on the platform that standardisation would retire. He wasn't defending an architecture. He was defending the six people whose skills were about to become the ones nobody needed, and a design review was the only forum where he had the standing to speak.

His colleague had no idea. None at all. He'd read six weeks of resistance as empire building and had started saying so to other people.

Once the actual issue was on the table, the architecture decision took about twenty minutes, because it turned out nobody genuinely contested it. What took longer, and mattered far more, was what shipped alongside the decision: four named engineers into funded certification on the surviving platform, with dates, before the first site migrated. The decision went where the evidence pointed. The thing that made it stick had nothing to do with the evidence.

This is where plenty of leaders overcorrect. They learn that conflict needs listening and neutrality, and then they move into neutrality permanently. Six weeks of sympathetic listening and no decision isn't conflict management. It's conflict laundering, and the team can tell the difference immediately.

Your neutrality has a purpose and an expiry date. It's the instrument you use to get an accurate definition of the problem. Once you've got one, somebody owes the team a decision, and if that decision isn't yours to make, you owe them a recommendation, a name, and a date.

Then go back. Put a reminder in your calendar two weeks out and check. Ask each of them separately whether it actually settled, because the version that resurfaces is always quieter and harder to see than the original. That follow-up isn't admin. It's the only real evidence you'll get that you fixed the right thing.

Pick the disagreement in your team that's been running longest. Probably the one you've stopped noticing, because it's just how those two are with each other.

Before you put them in a room together, book twenty minutes with each of them separately this week. Ask what the disagreement is. Then ask what they think the other person would say it is. Write both answers down where you can see them side by side.

If the two accounts don't match, you've just found the problem you're actually meant to be solving, and as of that moment it belongs to you.