Technical Leadership: Turn Disagreement into a Testable Decision

Ammar Najjar · Posted on October 1, 2026 · 5 min readleadership

I recently found myself in an engineering discussion that kept circling around the same disagreement. We were considering two ways of structuring part of a frontend application, and both had reasonable arguments behind them. One approach promised a cleaner separation and more consistent structure. The concern from the other side was that we would pay for that structure with additional indirection and make future changes harder to follow.

We spent time walking through both positions, challenging assumptions, and looking at possible consequences. That part of the discussion was useful because it helped us understand where the disagreement actually came from. After a while, though, I noticed that we were repeating variations of arguments we had already heard. Nobody had uncovered a constraint that ruled one option out, and neither side had enough evidence to demonstrate that its concerns would actually materialize.

At that point, continuing the debate was unlikely to teach us anything new. We needed evidence that was relevant to the problem we were trying to solve.

AI-generated image

From Positions to Evidence

I suggested that we stop trying to settle the decision in the discussion and instead identify what we would need to see to make it with more confidence. Rather than asking which engineer had the stronger argument, we looked at what was still uncertain and how we could make some of that uncertainty observable.

This builds directly on my piece on separating the practice from the problem. Once the problem, desired outcome, and constraints are explicit, they also tell us what evidence matters. If maintainability is the concern, for example, we might care about how easily someone can understand and change the implementation, how much testing it requires, or how failures propagate. A different problem would lead to different criteria.

From there, the next step was to make the experiment deliberately small. We did not need enough implementation to prove that one approach would work everywhere. We needed enough to examine the uncertainties that were keeping us from making the decision.

Agree on the Evidence Before the Experiment

One thing I have learned from situations like this is that the criteria need to come before the experiment. Before running a spike, I want the team to agree on what we expect to learn from it.

Otherwise, it is easy to build something and only afterward decide which aspects of the result matter. Each side can then interpret the same experiment through the assumptions it already had. I therefore try to make the criteria explicit before the work starts: what will we examine, and what evidence would make us prefer one option?

In this kind of frontend decision, that could mean implementing one representative part of the application in both ways and reviewing the result together. We can then look at the code we actually produced and discuss how understandable a change is, what testing it requires, and where complexity appears. The criteria come from the original problem rather than from a generic checklist.

This is also where my piece on giving autonomy a time boundary applies. An experiment needs a clear boundary and review point. The team owns how it explores the alternatives within that space, while everyone knows when the experiment ends and what question it is expected to answer.

Review the Result Together

The important part for me is the review afterward. The team comes back to the decision with something concrete in front of us. We can inspect the same implementation, discuss the same tradeoffs, and compare what we see with the criteria we agreed on before knowing the outcome.

The result may still require judgment. Engineering decisions rarely reduce to a single number, and an experiment can expose new tradeoffs rather than producing an obvious answer. Even then, the team is reasoning from a better position. Someone who strongly preferred one option may still disagree with the final choice, but the basis for that choice is visible and shared. That is the team-level version of the shift I describe in Thinking, Fast and Slow: when judgment feels intuitive and the team already has a preference, the useful move is to slow the process down and make the disagreement testable instead of letting the stronger argument win.

The Question I Now Ask

This experience gave me a useful signal for discussions that start going in circles. When the assumptions are understood, the reasonable arguments are already on the table, and another round of discussion is unlikely to reveal anything new, I ask:

What is the smallest experiment or piece of evidence that would help us decide?

I am curious how others handle this. When two reasonable engineering opinions remain after the assumptions have been explored, what small experiment has helped your team make the decision? Share it in the comments or reach out directly.

I read every response.