Technical Leadership: A Good Impact Story Still Needs a Measurable Direction

Ammar Najjar · Posted on October 9, 2026 · 4 min readleadership

AI-generated image

In planning discussions, I have often seen proposals that sound convincing because their local impact is easy to describe. A feature may remove friction for a customer, simplify a workflow, or enable something that was previously difficult. Those are useful arguments, but they can still leave an important question unanswered: how does this work move the broader goal we are trying to achieve?

Make the missing contribution visible

This became clearer to me in one planning discussion after I made a missing part of the data visible. We already had a broader business goal, but the dashboard did not make it easy to see how much our own product was contributing to it. Before the discussion, I worked with a colleague to add a per-channel breakdown that made our product’s share visible. Once that view existed, we could look at the current state directly and ask how each planned initiative was expected to move it.

A good story is not enough

What I noticed was that the individual proposals were well explained. For each one, there was a reasonable story about customer value and expected benefit. The weaker part was the connection between those benefits and the direction we had already agreed on. I inferred that we were treating a plausible impact story as enough evidence for prioritization, even when the expected contribution to the larger goal had not been made explicit.

AI-generated image

Make the expected movement explicit

Since then, I have found it useful to add one question before discussing implementation details or delivery sequence:

If this work succeeds, what should change in the metric or outcome we are trying to move?

The answer does not need to be a precise forecast. Many product and engineering decisions involve uncertainty, and assigning precision without evidence would only create false confidence. The useful part is making the assumed relationship explicit. If we cannot explain what we expect to change, we may still decide to proceed, but at least we understand that the decision is based on exploration, learning, risk reduction, or another form of value.

This also matters to me from a technical leadership perspective. Engineers and architects often have enough system and product context to notice assumptions that have not yet been discussed explicitly. Making relevant data visible, asking how proposed work contributes to the agreed outcome, and clarifying uncertainty can improve the conditions under which a decision is made while leaving prioritization with the people responsible for it. In The Five Dysfunctions of a Team, Lencioni calls inattention to shared results the final layer, and I read this planning pattern as its individual version: a good local story without a connection to the shared goal.

I now try to distinguish between two levels of explanation when reviewing planned work: what value the feature creates locally, and what movement we expect at the level of the broader goal. That distinction is the planning-level version of a move I describe in Separate the Practice from the Problem: name the problem and its desired outcome first, and the proposal becomes one option to evaluate against them instead of the subject of the discussion.

The Question I Now Ask

A practical question for the next planning discussion is:

What evidence would make us believe that this work moved the outcome we actually care about?

I am curious how others handle this. When a proposal has a strong local story but a vague link to the broader goal, what do you ask before it gets prioritized? Share your approach in the comments or reach out directly.

I read every response.