The Nesting Gap: Why an FDE Can’t Fix an Unstated Purpose

Take twenty product managers in the same company. Put their organization’s mission statement in front of them, provided of course it is simple, focused, and cogent. Ask one question: considering your organization’s mission, what do YOU do here? That is, what is your unit’s mission, and how does it complement the organization’s?

There is a very good chance you will get twenty different ideas and perspectives on the same question. In effect, you will most likely get a spread.

A few will recite the official line. Most will describe the work they ship, the tickets they clear, the stakeholders they keep quiet. A few will name the real job: protect a revenue stream, keep a failure from happening again, make a system look adopted.

That spread is the real finding. It is twenty compasses in the same room, none of them agreeing on north. One of the hottest jobs in the AI marketplace today is the Forward Deployed Engineer, borrowed from the military practice of situating forces as close to the front lines as possible so they can provide a rapid reaction force to the changing nature of the tactical situation as it occurs.

Every military unit keeps a laser-beam focus on its mission, and for good reason. If the unit cannot say what it is there to produce, the people closest to the fighting cannot tell a necessary adaptation from a drift. Focus is not rigidity. It is the standard that lets a rapid reaction force move without losing the point of the fight.

That focus only works if the mission nests. The army has a purpose. Each unit below it inherits a narrower purpose that still points the same direction. A battalion does not invent a new north. It takes the higher mission and states what this unit must produce so that mission can be carried out. The answers should differ in scope, not in direction. When they differ in direction, you do not have nested missions. You have twenty compasses.

That is not a military curiosity. It is the test most organizations never run. How many units inside a company can state their own mission clearly enough that it still points the same direction as the organization above them? Not a slogan. A production purpose. If the answer is “few,” the spread in the room is not a surprise. It is the operating condition.

In the company, that is the job. Send an engineer forward. Sit them inside the unit. Let them see how the work actually runs, write the missing pieces, and get the system into production before the local situation changes again. The hope is that proximity will do what the mission statement did not. If the people in the room do not share a north, put someone on the ground who can see the work as it happens and encode that, fast.

Proximity helps. It does not finish the job. An engineer on the ground can see how the work runs. That is not the same thing as inheriting a stated purpose for why the work exists.

The Forward Deployed Engineer is built to close the implementation gap: the demo does not fit the stack, the workflow is messier than the slide, and nobody on site can make the tool produce value. That work is real. It is not the same as closing the purpose gap.

The purpose gap is different. What does this unit exist to produce? Which workarounds are load bearing? Who already owns the decisions the current process is making quietly? What must never be optimized away?

Think of it this way. The engineer can map every trail on the ground and still not know which one is the supply line. The visible paths get written down. The load-bearing ones may never be marked.

An FDE can map what happens. They are rarely given standing to rule on what should happen.

They inherit the ambiguity in the room, plus pressure to get something into production. If the unit never stated its mission, the engineer does not inherit a north. They inherit a guess.

Then the system locks in. What never gets stated becomes the default. The default becomes permanent. The official process gets encoded. The workarounds that keep the place alive stay outside the code, or they look inefficient on paper and get removed.

That is expensive certainty: the moment the wrong understanding, or the incomplete one, becomes the specification.

So, the FDE is an admission that something upstream is missing. Whether the embed repairs it depends on a question the unit must answer first. Can it state what it exists to produce, in a way that complements the organization’s mission, specifically enough that an outside engineer does not have to guess?

The FDE is usually dropped into a planning problem: map the process, configure the tool, get it into production. That work executes whatever diagnosis is already in the room. It cannot produce the diagnosis. If the unit never asked whether it was answering the right questions, the plan will encode the available story with more speed and more permanence.

If twenty people in the same group write twenty different answers, you do not yet have a unit mission. You have a collection of local theories. The FDE, the vendor, and the roadmap will encode one of those theories. The others will keep showing up as workarounds. Planning will not fix that. Planning executes a diagnosis. It cannot produce one.

I have spent more than forty years practicing and teaching strategy and tactics. The pattern does not change much when the tool changes. Tactics can be brilliant and still serve the wrong object. Strategy is the work of stating that object before the force, or the engineer, has to move. The scarce skill is not getting the system to run. The scarce skill is deciding what should be encoded before someone has to guess. As the storied Chinese strategist Sun Tzu put it: “Tactics without strategy is the noise before defeat.”