There is one observation that has followed me throughout my career, regardless of the company, the industry or the technology involved.
Whenever a software initiative began to struggle, the first explanations were almost always technical. People questioned the architecture, the quality of the implementation, the tooling or the delivery process. Those are all reasonable places to look, and sometimes they are indeed part of the problem. Yet, as I looked more closely over the years, I found that they were rarely the real cause. More often than not, the technical issues were merely symptoms of something much deeper.
Somewhere along the way, the shared understanding of the business problem had fractured.
What fascinated me was that everyone involved was usually competent. The architects understood architecture. The engineers understood software. Business analysts understood requirements. Product owners knew how to prioritize. QA engineers cared deeply about quality. Security specialists, compliance experts and operations teams all brought valuable perspectives to the table.
Individually, each person understood their own part remarkably well.
Collectively, however, very few understood the whole.
I do not say this as a criticism of individuals. In many organisations, people are simply working within the system they inherited. The structures, processes and responsibilities that surround them encourage specialization and handovers rather than shared understanding. Nobody intentionally designed these systems to fail. They evolved over many years, shaped by good intentions, local optimizations and practices that gradually became accepted as normal.
Over time, however, I have come to believe that we have mistaken familiarity for effectiveness.
The Telephone Game
One of the clearest examples can be found in the way many organisations still approach software delivery.
A business expert identifies an opportunity or explains a business process. That understanding is handed to a business analyst, who refines it before passing it to a product owner. The product owner translates it into work that engineering can plan and execute. Engineering managers discuss it with development teams. Developers implement the solution, after which QA validates the result.
Every step in this sequence has a purpose. Every participant contributes something valuable. None of the people involved are the problem.
The difficulty lies elsewhere.
Every handover changes the message, however slightly. Some details are omitted because they seem unimportant at the time. Others are interpreted through the experience of the person receiving them. New assumptions quietly replace old ones, often without anyone noticing.
Most of us played the telephone game as children. We laughed because the final sentence barely resembled the one that started the game. Somehow, as professionals, we have become remarkably comfortable applying the same principle to software delivery.
Information does not remain intact simply because everybody involved is intelligent and conscientious. Every handover is inherently lossy. It cannot be otherwise.
By the time software reaches production, what began as a business idea has often become a chain of interpretations rather than a shared understanding.
The Cost We Rarely Measure
The consequences of this fragmentation are familiar to anyone who has spent time in software delivery, although we rarely connect them back to their original cause.
Projects require more refinement sessions than expected. Coordination meetings multiply. Teams repeatedly synchronize their work. Requirements are revisited, clarified and reinterpreted. Features are reworked because someone discovers that an important detail was lost several conversations earlier. Defects appear that are not really implementation defects at all, but misunderstandings that survived all the way into production.
Quality assurance eventually becomes the final safety net for problems that should never have existed. Sometimes even our customers inherit that responsibility.
We have become remarkably good at measuring the cost of fixing defects. We invest far less effort in understanding the cost of creating them in the first place. How much time do we spend rediscovering knowledge that already existed somewhere else? How many meetings exist solely because understanding has become fragmented? How much coordination is needed simply because nobody shares the same mental model?
These costs rarely appear on a project plan, yet they shape almost every software initiative.
Our Largest Silos Are Invisible
When organisations discuss silos, the conversation usually turns to departments, reporting structures or organisational charts.
I have increasingly come to believe that the more significant silos exist inside our heads.
As professionals, we naturally develop deep expertise in our own disciplines, and that expertise is essential. The difficulty begins when the boundaries of our profession become the boundaries of our curiosity.
Architects focus on architecture.
Developers focus on implementation.
Security focuses on controls.
Operations focuses on reliability.
Compliance focuses on regulation.
QA focuses on validation.
Business focuses on business outcomes.
Each perspective is necessary. None is sufficient.
When everyone optimizes their own part of the system, who is responsible for understanding the system as a whole?
It is surprisingly easy for conversations to become territorial. Business is expected to stay away from technical discussions. Engineers are discouraged from speaking directly with business experts. Security joins towards the end. Operations reviews the solution before deployment. Compliance is consulted once the implementation is largely complete.
Everyone protects their own domain, while the business problem itself quietly crosses all of them.
One Conversation Instead of Many Translations
For years I have heard the argument that bringing all relevant people together is too expensive.
Experience has led me to the opposite conclusion.
Misunderstandings are expensive.
Repeated coordination is expensive.
Building the wrong solution is expensive.
Correcting it after deployment is even more so.
The most productive workshops I have participated in looked remarkably different from the traditional sequence of handovers. Business experts, architects, developers, QA engineers, security specialists and operations teams all explored the same business process together. Every participant asked different questions. Every answer revealed another piece of the puzzle. Assumptions became visible while there was still time to challenge them.
Those sessions were not expensive.
They were investments in shared understanding.
The engineer was not there to replace the subject matter expert.
The business expert was not there to design the software.
Each person contributed a different perspective towards the same objective: understanding the business problem completely before attempting to solve it.
A Language That Belongs to Everyone
Another observation has stayed with me over the years.
We seem remarkably good at creating languages that separate us.
Business has its terminology.
Engineering develops another.
Security introduces its own vocabulary.
Compliance adds yet another.
Architecture contributes its own concepts and abstractions.
None of these languages are wrong. Every discipline needs precision.
The problem arises when precision becomes exclusion.
Most software that we build—particularly line-of-business applications—exists for one simple reason. It automates business processes that people would otherwise perform manually. Without the business process, there is no reason for the software to exist.
That may sound obvious, but I sometimes wonder whether we truly behave as though we believe it.
If software exists to serve the business, then business should provide the common language around which every discipline collaborates. Not because technology is secondary, but because a shared language allows specialists from every discipline to contribute without constantly translating between different worlds.
Personally, I have never been particularly fond of giving this idea another sophisticated name. We do not need another term that only insiders recognize.
It is simply a shared language.
Listening Before Designing
There is one sentence I have heard countless times throughout my career.
“The business doesn’t know what it wants.”
I have rarely found that statement to be fair.
Subject matter experts know their business extraordinarily well. They perform these processes every day. They understand the exceptions, the workarounds and the situations that rarely appear in process documentation.
What they often do not do is tell the complete story in perfect sequence during a single conversation.
That is entirely normal.
The responsibility of architects, analysts, engineers and all the other participants is therefore not to replace the expertise of the business. It is to ask thoughtful questions, explore alternative scenarios, uncover assumptions and gradually complete the picture together.
The objective is not to demonstrate who knows the most.
It is to leave the room with a shared understanding that nobody possessed when they entered.
The Blueprint Before the Build
Over the past months I have written extensively about Business Solution Design. This chapter explains why I believe it deserves far more attention than it typically receives.
Before we discuss architectures, frameworks, cloud platforms, security controls or AI-assisted software development, we must first develop a complete understanding of the business problem itself. Without that foundation, everything that follows becomes an optimisation of assumptions.
What we ultimately need is a blueprint: a representation of the intended business solution that every stakeholder can understand, question and refine together. It should be equally meaningful to the subject matter expert explaining the business process, the architect shaping the solution, the engineer implementing it, the QA engineer validating it and the operations team responsible for running it.
Only then does implementation become an engineering exercise rather than an exercise in interpretation.
Over the years I have explored several approaches that attempt to create this kind of shared understanding. Personally, I have found #EventModeling to be one of the most effective. Its strength lies not in making complex business problems simple, but in making complexity visible. Simplicity of notation does not eliminate complexity. It merely allows everyone to see it, discuss it and understand it together.
Perhaps that is the real challenge our industry faces.
For decades we have invested enormous energy in improving the way we build software. We have developed better programming languages, more sophisticated architectures, powerful cloud platforms and, most recently, extraordinarily capable AI systems.
Yet none of these advances can compensate for a fragmented understanding of the problem we are trying to solve.
The more I reflect on my own career, the more convinced I become that our greatest challenge is not one of technology.
It is one of understanding.
Until we learn to create that understanding together, we will continue building software from fragmented knowledge, hoping that somewhere during implementation those fragments will somehow assemble themselves into a coherent whole.
Originally published on LinkedIn (2026-07-08): https://www.linkedin.com/pulse/fragmented-understanding-gabriel-n-schenker-1zide
