“Business doesn’t know what it wants.”
I have heard engineers say this in many companies, usually with plenty of examples to support the claim. Requirements change, important details surface late, edge cases seem to appear from nowhere, and business stakeholders are accused of not being willing to spend enough time explaining how things actually work.
Business people often tell an equally frustrating story. They feel that technology does not really understand them. They enter a conversation wanting to explain a process, a decision, an exception or something that needs to change, but before long the discussion has moved somewhere else. Suddenly people are talking about components, interfaces, architectural patterns and abstractions. The subject matter expert who actually knows the business may still be sitting in the room, but the conversation is no longer one in which they can meaningfully participate.
After this has happened often enough, distrust becomes part of the organisation. Engineers expect business to be vague. Business expects engineers not to listen. And rather than bringing both sides closer together, many organisations respond by inserting more people and more artefacts between them.
A business SME explains something to a business analyst. The analyst turns that understanding into requirements. Those requirements become features, stories or some other representation. A product owner refines them. An architect interprets them. Developers derive an implementation from them. Testers derive test cases from what they see, and eventually operations gets another representation of what has been built.
We have, in effect, industrialised the telephone game.
The problem is not only the number of handovers. At every handover we also translate. Each tribe has developed its own language, its own abstractions and its own way of describing reality. That language is useful inside the tribe because it compresses knowledge shared by its members, but from the outside it often looks like a black box. So what crosses the organisational seam is rarely the original understanding. It is somebody’s interpretation of that understanding, expressed in another language.
Then the next group translates it again.
With every translation, something can disappear. Why exactly was this rule important? Under which circumstances does an exception apply? What information was available when somebody made a decision? What had happened beforehand? What must never happen? Which apparently minor detail completely changes the outcome?
Usually nobody deliberately removes this information. It simply does not look important from the perspective of the person doing the translation. And when the next person encounters a gap, they do what competent people naturally do: they fill it using their own experience and assumptions.
This is how ambiguity gets introduced without anybody noticing.
By the time the misunderstanding becomes visible, it may have been turned into code, automated tests, documentation, dashboards and operational procedures. At that point the organisation has created a very precise implementation of something it never properly agreed on in the first place.
There is another form of translation that I think we engineers need to be particularly careful about: our instinct to abstract the business too early.
We often believe that understanding the domain means identifying its entities. We start talking about “the customer”, “the policy”, “the claim” or the order”, and from there we begin to construct models around these nouns. The model may look beautifully consistent from an engineering perspective, yet I have rarely heard a business person describe their work that way.
They talk about activities.
Cancel a policy.
Change the policy owner’s address.
Increase the sum assured.
Accept an application.
Refer a case for manual underwriting.
Collect a premium.
Refund a payment.
- Cancel a policy.
- Change the policy owner’s address.
- Increase the sum assured.
- Accept an application.
- Refer a case for manual underwriting.
- Collect a premium.
- Refund a payment.
The business is concerned with something happening, with the information required for it to happen, with the decision involved, and with what changes as a result. The important boundary is therefore often not “everything that belongs to the Policy entity”. It is the information that has to be consistent for this particular decision or activity.
This is one reason why the idea of dynamic context boundaries (CB) in aggregate-less Event Sourcing was such a relief for me. It allowed me to stop forcing the business into artificial entity-shaped containers and instead ask a much more useful question: What information has to come together here, at this moment, for this decision to be made correctly?
That is a very different way of looking at a system.
It also changes the conversation with business SMEs. Instead of asking them to validate an abstract model of a Policy” and all the things that supposedly belong to it, we can discuss what actually happens when somebody cancels a policy. What information is needed? Which previous facts matter? Who may initiate it? Which rules apply? What happens if the policy is already cancelled? What should become visible afterwards? Which other activities may now be triggered?
These are questions both sides can discuss without one side first having to learn the language of the other.
This is also why I keep coming back to Event Modeling. Not because coloured boxes on a wall somehow solve organisational problems, and certainly not because every business person should learn an engineering notation. Its value is that it gives people from different disciplines a shared surface on which they can discuss behaviour.
A business SME can point at something and say, No, that cannot happen yet. We first need this information.”
An engineer can ask where that information comes from.
A tester can ask what happens if it never arrives.
Operations can ask how we would recognise that the process has become stuck.
Security can ask who is allowed to initiate the activity and under which circumstances.
These are not five separate models handed from one group to another. They are different perspectives on the same piece of reality.
Something interesting tends to happen when people work this way for a while. Some of the stereotypes begin to disappear. Engineers discover that business people can be extraordinarily precise when the conversation is about the business they actually know rather than about writing pseudo-technical requirements. Business SMEs discover that engineers are often deeply interested in the domain when they are allowed to explore it with them rather than being handed a solution disguised as a requirement.
Trust does not return because someone ran a workshop about collaboration. It returns because people experience what collaboration actually feels like.
Of course engineers will eventually have to make technical decisions and introduce technical abstractions. But those abstractions should be derived from an understanding of the behaviour, not used as a shortcut to avoid acquiring that understanding. If we abstract too early, we compress something we have not yet understood, and whatever disappeared during that compression is difficult to recover later.
This matters even more now that AI is entering software delivery.
AI can generate requirements, stories, designs, code and tests astonishingly quickly. It can accelerate every step of the delivery process. But if the process is still based on one tribe translating its partial model of reality for the next tribe, AI may simply allow us to play the telephone game much faster.
I do not think the answer is another intermediary, another requirements template or a better way of translating between business and technology.
I think we need to reduce the amount of translation in the first place.
Put the people who understand the business together with the people who will build, test, secure and operate the system. Give them the same wall, the same model and enough time to understand what actually happens before anyone rushes to turn it into a technical abstraction.
Because many of the most expensive defects I have seen did not begin as coding mistakes.
They began as slightly different understandings of reality that nobody noticed until they had become software.
Originally published on LinkedIn (2026-08-31): https://www.linkedin.com/pulse/telephone-game-between-business-tech-gabriel-n-schenker-2xyre
