Between a business intent and its execution sit words, choices and translations. One misunderstood word can turn a firm requirement into a casual option, while everyone works correctly from a technical point of view.

Suppose a bricklayer delivers a perfect wall. Plumb, neat joints, solid materials. It just stands three metres further along than on the plan.

Nobody would conclude the project is a success because the wall is at least straight. Technically well executed but in the wrong place is still simply wrong. Impressively solid, even.

With digital products, processes and communication, such deviations are harder to spot. There is no wall in the way. The code works, the briefing is ticked off and everything looks tidy. Even so, the result may have drifted along the way into meaning something other than what was originally needed.

Sometimes one word is all it takes.

Mandatory availability is not the same as optional

In a conversation about how to build tools, I stated a simple requirement: depth must be available in every tool, internal and for clients, but it does not have to sit on the first screen level.

That distinction matters. On the first level you want to see quickly what is going on, what needs attention and what the next step is. Anyone who needs more context clicks through. So the depth is mandatory to provide. Using it is not.

Along the way, this was summarised as: the depth is optional.

That sounds almost the same. It is not. In my wording, the user chooses when to open the depth. In the summary, a builder can understand that it may not need to be built at all. One word turned a hard product requirement into a non-binding possibility.

The discussion revealed the difference between my requirement and the summary. That wording left room for an implementation different from what I intended. Meaning can already shift in a summary that sounds reasonable.

Every handover is also a translation

A business intent rarely goes straight to execution. It gets discussed, summarised, put in a briefing, turned into screens or process steps, translated into code and finally tested.

Each step can be done carefully and still shift a little. A condition becomes a preference. A preference becomes an example. An example becomes the default. In the end the result matches the last instruction perfectly, but no longer the original request.

It is like a building plan copied half a metre off. The next crew carries on with great precision along that new line. The better everyone does their own part, the firmer the deviation becomes.

New technology does not necessarily make this worse, but it does make it faster and sometimes more convincing. A model writes a fluent briefing. A developer turns it into correct code. A test confirms the code does what the briefing says. None of those checks proves the user still gets what was originally intended.

Nor is this typical of AI. People have been summarising, filling silences and choosing words that make sense to them for far longer. A polished formulation just reads as easily as a correct one. Fluent and correct are not synonyms.

Delegating takes more than a good briefing

Anyone handing work to a colleague, a supplier or a model does well to pass on three things. Context the person doing the work can actually reach. A clear description of what has to come out. And afterwards, a check of the result against the original intent.

A folder of documentation does not replace that. Documentation proves something was written down, not that the result is right.

That you do not simply trust a model with everything came up before in ‘The model can do it. But who gave permission?’ That article is about authority. This one is about meaning. Both belong to the same handover.

The intent has to come along, not just the sentence

You do not prevent this by making every briefing endlessly long. More words also mean more chances for confusion. What does help is stating what is fixed, where there is room in the execution and why a requirement exists.

In the example, it was fixed that every tool had to offer depth. The freedom lay in the presentation: not everything on the first screen, but logically reachable as soon as someone needs more context. The aim was a simple start without hiding information.

If only the loose words travel, “not on the first level” can turn into “not necessary” along the way. If the aim travels too, that leap gets much harder. A designer, developer or reviewer can then check whether the chosen solution still serves the same need.

Outside software the same holds. A commercial promise has to mean the same thing in execution. A legal agreement has to be watertight and workable for the people applying it. And when an order passes through several systems and hands, “no sauce” is better left as an instruction than a suggestion.

Check the result against the real request

A lot of quality control rightly looks at execution: it works, it is safe, the form is right and the agreed parts are present.

One more check belongs alongside. Someone explains in plain language what the user can now do, what is mandatory and which business intent that carries out.

That is not an extra layer of ceremony. It is the simplest way to notice that everyone now has a different wall in mind. Preferably before the bricklaying is finished.

For a tool, that read-back sounds like this: on the first screen the user sees what is going on and what the next step is, and in every tool the necessary depth is logically reachable. That tests more than a screen or a specification. It tests the line between the original choice and what someone will actually experience.

Sometimes the briefing turns out fine and the execution has to be corrected. Sometimes the problem is already in the wording. And sometimes it turns out the original request was not yet sharp enough. That is not a failure. That is how a check is supposed to work, before a deviation becomes costly and visible.

Straight is not enough

Good execution remains essential. Nobody benefits from a wall in the right place that falls over in the first strong wind. Technical quality just does not replace the right direction.

In my work a lot revolves around that piece in between: keeping the meaning intact while a request moves through different disciplines, people and tools. Not doing everything myself, but making sure the commercial choice, the agreement, the communication and the execution are still about the same thing.

From business choice to execution without losing the line may sound abstract. Until a perfectly straight wall stands in the wrong place. Then that line suddenly becomes very concrete.

On LinkedIn, I explain what I pass on when I hand over work: read the companion article (in Dutch).

Wat ik meegeef als ik werk uit handen geef

Companion article on LinkedIn (in Dutch)