The Gap Nobody Owns | Volodymyr Onishchenko

There’s a pattern you start noticing once you’ve worked on a few real products. Things rarely break inside a discipline. The design is thoughtful. The code is solid. Product decisions make sense in isolation.

But once everything comes together, something feels off. Not obviously broken. Just inconsistent, harder to use than it should be, full of small gaps that nobody quite owns.

That is what makes the problem so difficult. It rarely comes from lack of skill. More often, it comes from the way work moves between people — and from the fact that each role sees a different version of the product.

Where things actually break

The usual response to this problem is T-shaped thinking. The idea is reasonable: go deep in your own discipline, but learn enough about adjacent ones to communicate better and reduce friction. It helps. Teams collaborate more easily. Some gaps get smaller.

But it does not solve the deeper issue. T-shaped thinking is about how individuals grow. It does not guarantee that a team shares a common understanding of the system it is building together. That is where many products start to lose coherence.

Design sees structure, interaction, and flow. Engineering sees implementation, constraints, and failure modes. Product sees outcomes, trade-offs, and priorities.

These views overlap, but they are not the same. When they remain misaligned, the product degrades quietly as it moves from one stage to the next. No single decision looks catastrophic on its own. But together, they create friction, inconsistency, and a product that feels less resolved than the people who made it.

Other frameworks have addressed parts of this problem. Conway’s Law explains why systems tend to mirror the communication structures of the teams that build them. DevOps reduced friction by collapsing the handoff between development and operations. Team Topologies offers a way to structure teams around cognitive load and interaction patterns. Design systems create a shared language between design and implementation.

All of these move in the right direction. But none of them fully address the deeper issue: each role holds a different mental model of the product, and nobody truly owns the space between them.

What construction engineering gets right

I studied construction engineering for five years. The important thing was not only the specialization. It was the order.

The curriculum did not begin with a narrow role. It began with the system: general physics, higher mathematics, descriptive geometry, architectural drawing, strength of materials, theoretical mechanics, construction materials, soil mechanics, foundation design, structural systems, and construction organization. Some subjects were studied in depth. Others were taught just far enough to make their relationship to the rest of the process visible.

Only later did specialization come into focus. Mine was Technology of Construction Production — the part of the process concerned with how a building is actually delivered: sequencing, crews, materials, equipment, site logistics.

By that point, you already understood something essential: your work only made sense because it belonged to a larger sequence. You knew what came before it, what came after it, and how your decisions would affect the people downstream.

Before you go deep, you go wide. Before you specialize, you learn how the whole thing stands.

My diploma reflected that logic. It consisted of twelve A1 drawings and an explanatory note. Six drawings covered my specialization. The other six covered architecture, foundations, and structural calculations — disciplines I was not specializing in, but still had to understand well enough to complete the picture.

Not because I had to become an architect, a structural engineer, or a foundation expert, but because no part could be handled responsibly without understanding the others. That is the part digital product teams often miss.

In digital products, the order is reversed

In software, specialization usually comes first. You become a designer, engineer, PM, or marketer. You go deep into your own craft. What happens before your work starts, or after it leaves your hands, is something you pick up gradually — if you pick it up at all.

As a result, each role develops its own mental model of the product. A designer may think in layouts, states, and flows. An engineer may think in architecture, edge cases, and implementation trade-offs. A PM may think in scope, priorities, and measurable outcomes.

All of that is reasonable. None of it is enough. Products do not fail only when someone makes a bad decision. They also fail when reasonable decisions are made from incomplete models of the same system.

Construction makes this easier to see. Imagine if a structural engineer only learned calculations, and only discovered foundation work, sequencing, site logistics, or finishing constraints after joining a real project. Some would eventually fill in the gaps. Most would spend years learning dependencies that should have been visible from the start.

That is roughly how many digital teams operate. The difference is that software hides the consequences better. A building exposes a bad handoff quickly. In software, you can ship something that looks finished while the gaps quietly accumulate underneath.

The cost of the handoff

There is a construction joke that captures this well. Bricklayers build crooked walls and say the plasterers will fix it. Plasterers finish and say the fillers will even it out. The fillers say the wallpaper will cover it.

Each layer absorbs the mistakes of the one before. The problem is not only that a mistake was made. The deeper problem is that everyone assumes it becomes someone else’s responsibility downstream.

The same pattern shows up constantly in digital products. A designer hands over polished screens without thinking about what happens when the API returns nothing, when loading takes too long, or when an error breaks the happy path. Those states exist in the real product whether they were designed or not. If they are missing, someone else will invent them under pressure — or they ship broken.

At a meetup recently, an Android developer described receiving a design file full of unmerged, unstructured layers. For Android implementation, that matters. Asset organization affects how things are exported, mapped, and built. The designer had done the design work. But they had no model of what happened after the handoff.

And this is not just a design problem. A feature gets prioritized without understanding the architectural constraints it introduces, and two years later the system is harder to evolve because a short-term decision quietly closed off future options. Copy gets written after the interface is already structured, only to reveal that the navigation was built on assumptions that collapse once real language appears.

Each case seems small in isolation. Together, they describe the same failure: every part works locally while the system degrades globally.

From T-shaped to system-aware

T-shaped thinking is still useful. Depth matters. Breadth matters. Cross-functional empathy matters. But none of that automatically creates shared system understanding.

What teams actually need is something more operational: a common view of how the product works end to end, where decisions create downstream constraints, and what each discipline owes to the next one in the chain.

That does not mean turning specialists into generalists. Generalism means doing a bit of everything and owning nothing deeply. System awareness is different. It means understanding the process well enough to know where your work fits, what it enables, and what it constrains once it leaves your hands.

In practice, that looks concrete: not just a Figma file, but defined loading, empty, error, and edge states; not just a feature proposal, but visibility into the technical constraints it creates; not just interface copy, but awareness that language can reshape information architecture; not just shipping your part, but making your decisions legible to the people who build on top of them.

That is the real shift: not from specialist to generalist, but from isolated expertise to shared system awareness.

AI changes access, not responsibility

In construction engineering, building that broad foundation takes years. That model does not translate neatly to modern product teams. AI changes one part of the equation: access.

A designer can now explore implementation implications faster. An engineer can inspect interaction logic and UX intent more easily. A PM can test assumptions, simulate scenarios, and surface edge cases before development begins.

Used well, AI can act as a translator between disciplines. It can help people see the product from the other side of the handoff. That matters. But it does not remove the core problem.

AI only works from the context it is given. If the system itself is poorly understood, AI can still produce something that looks complete while quietly opening a gap somewhere else. The output may be faster. It may even be more polished. But polished is not the same as coherent.

That is why system awareness matters even more now. The better you understand the product as a connected system, the better you can use AI to explore it, challenge it, and pressure-test your own blind spots. Without that understanding, AI risks becoming another layer that optimizes parts while missing the whole.

The system has to be understood, not just executed

Better specialists will not fix broken connections between them.

A building stands because the project accounts for how every beam, wall, opening, and foundation decision interacts with the structure around it. No single discipline makes the building work. The system does.

Products follow the same logic. It is not enough to have strong designers, capable engineers, and thoughtful PMs. If each role only understands its own piece of the process, the gaps accumulate quietly until they show up in the product.

The goal is not to make everyone broader for the sake of breadth. The goal is to make the system visible.

Because products rarely fail when people neglect their role. They fail when no one fully sees the system they are building.