Technical Leadership: Separate the Practice from the Problem

Ammar Najjar · Posted on September 28, 2026 · 3 min readleadership

AI-generated image

I recently noticed how quickly an engineering discussion can become centered on a practice rather than the problem that triggered it. In one team conversation, we were discussing whether to introduce test-driven development. The discussion could easily have turned into the usual exchange of opinions about TDD, its benefits, its overhead, and whether it fits the way the team works.

Instead, I tried to move the conversation one level back. What problem were we actually trying to address? What outcome would tell us that we had made progress?

Move One Level Back

Once those questions became explicit, TDD stopped being the subject everyone had to take a position on and became one possible approach among several. People could reason about the outcome without first defending or rejecting a particular engineering practice. A quieter team member also contributed a different perspective, and the team eventually decided against introducing TDD at that point. They agreed on a smaller step around making the expected tests more explicit.

AI-generated image

The interesting part for me was that the discussion still produced action even though the original practice was rejected. Earlier in my career, I might have interpreted that as the proposal failing. I now see it differently. If the underlying problem becomes clearer and the team chooses an approach it can actually own, the conversation has done useful work.

Keep the Problem, Change the Solution

This pattern appears frequently in engineering. We discuss adopting a testing method, introducing a new architectural pattern, adding observability, changing the branching strategy, or bringing in another tool. These ideas often enter the discussion because somebody has already connected them to a real problem. Once the proposed solution becomes the headline, however, that original reasoning can disappear.

A technical leader can help by recovering it. I find three questions useful: What problem are we seeing? What outcome would tell us it improved? What constraints should shape the first attempt? This is the discussion-level version of a move I describe in giving a team autonomy a time boundary: make the problem, the outcome, and the constraints explicit, and the proposed approach becomes one option to evaluate against them instead of the subject of the discussion. The sequence matters to me. Establish the problem, the desired outcome, and the constraints first, and only then evaluate the proposed practice alongside smaller or different approaches against the same outcome. Toyota’s problem-solving method follows the same order: observe, understand the problem, form a hypothesis, only then experiment (The Toyota Way). The practice is one hypothesis among several, not the target of the discussion.

This also reduces the pressure on the person who introduced the idea. Their proposal no longer needs to win for their concern to be taken seriously: the team can keep the problem and change the solution.

In your next discussion about adopting a practice or tool, try spending the first few minutes without evaluating it. Write down the problem, the desired outcome, and the relevant constraints first, then return to the proposal.

The Question I Now Ask

When a team rejects a proposed engineering practice, how do you make sure the underlying problem does not disappear with it?

If you have tried moving a discussion back to the problem first, what did you notice? Share it in the comments or reach out directly.

I read every response.