When Both Teams Are Right

Some years ago, at a company where I owned a set of financial data products, engineering and data science got into a standoff over how to improve the way we categorized bank transactions — turning a cryptic merchant string into a business entity and a category a lender could actually reason about.

Engineering wanted deterministic pattern matching. It was fast, it was cheap, it was debuggable at three in the morning, and when it was right it was right forever. Data science wanted to invest in better models, because the space of merchant strings is effectively unbounded and no human is going to hand-maintain rules for the tail of it.

Both arguments were correct. Neither team was going to concede. The work stalled, and worse, the relationship between two teams that needed each other started to sour — the sort of damage that outlives whatever decision eventually gets made.

The trap

The tempting move as the product leader is to adjudicate. You have the authority, everyone wants the deadlock broken, and picking a side takes ten minutes.

It's also the most expensive ten minutes available to you. You'll need both teams fully engaged on execution regardless of which approach wins, and the losing side doesn't stop believing they were right — they just stop saying so, which is worse, because the objection goes underground and resurfaces as low-grade disengagement for the next two quarters.

There's a subtler cost too. Adjudicating assumes the framing you were handed is correct: that this is one problem with two candidate solutions. That assumption is often the actual error.

The reframe

What I've come to believe is that a durable technical disagreement between two competent, well-informed teams is rarely a disagreement about the answer. It's evidence that the problem contains more than one regime, and each team has been reasoning honestly from a different one.

In our case, that's exactly what it was. There's a head of the distribution — a few thousand merchants that account for an enormous share of all transactions, stable, high-volume, well-known. Deterministic matching is not merely adequate there, it's strictly better: cheaper, faster, and correct in a way that stays correct.

And there's a long tail — endless, weird, constantly changing, where no rule set will ever keep up and only a model can generalize.

Engineering had been looking at the head. Data science had been looking at the tail. Both were describing their region accurately, and the argument was unresolvable because it was being conducted as though there were one region.

We shipped the hybrid: deterministic matching for the known head, models for the tail. Accuracy landed meaningfully beyond where either proposal would likely have reached alone — which makes sense, since each half of the problem was finally being handled by the approach suited to it.

How to spot it

The diagnostic I use now is one question, asked of both sides separately: on which specific inputs is your approach clearly the best choice?

Not "why is your approach better" — that invites the argument you're already stuck in. Ask for the territory each approach owns outright.

If the answers barely overlap, you don't have a conflict. You have a partition, and your job is to name the boundary and decide who owns which side of it. Common boundaries: head versus tail, hot path versus cold path, high-confidence versus low-confidence, cheap-and-reversible versus expensive-and-permanent. That last one shows up constantly in agent design — deterministic logic for actions you can't take back, model judgment for the ones you can.

If the answers overlap heavily, you have a genuine either/or, and now you have to decide. But you'll be deciding with a much clearer picture of what you're trading away, because both teams have just told you precisely where their approach is strongest.

The honest counter-case

Hybrids are not free, and I don't want to make this sound like a universal solvent. Two systems mean two things to maintain, two failure modes, and a routing layer that becomes its own source of bugs. There's an ownership question that has to be answered explicitly or the boundary becomes a place where accountability quietly disappears. And a hybrid chosen to avoid conflict rather than to fit the problem is just a decision nobody made, wearing a costume.

The test is whether the split is real. If you can state the boundary in one sentence and both teams nod, it's real. If the boundary requires a paragraph and some hedging, you're probably conflict-avoiding and you should pick.

What actually mattered

The accuracy improvement was the headline, but it isn't the part I think about. What mattered more was that each team walked out owning the half of the problem they were genuinely best at, and neither had to be publicly wrong to get there.

That's worth a lot. You are going to need both of those teams again next quarter, on a problem you can't see yet.