The Cost of Misaligned Ownership

A familiar scenario plays out across many technology organisations: Product defines what, Engineering struggles with how, Business demands why. Everyone is busy, yet outcomes drift. Misalignment looks small at first: a missed deadline, a slightly different interpretation, an unclear requirement. But it compounds into systemic failure. What seems like friction in execution is often a structural flaw in ownership.

1. Where the split begins

Historically, craft and purpose were unified. The architect not only designed but also understood construction. The watchmaker both invented and assembled. Disciplines grew around the principle that intent and execution should not be separated too far. It is true that these domains did not operate with agility and were not forced to navigate market uncertainty, but they still offer a lesson in coherence and accountability.

In modern technology, however, we often fracture ownership into three neat boxes: Product “owns” requirements, Engineering “owns” delivery, and Business “owns” impact. The structure looks orderly on paper, yet in practice it fragments accountability. Each party optimises for its own local goals, but no one holds the whole.

2. The illusion of clarity

Frameworks that prescribe “Product defines the what, Engineering delivers the how” appear simple and rational. They are appealing in presentations, but can become dangerous in practice. The truth is that the boundary between what and how is porous.

What is feasible shapes what is desirable.

How something is built influences what value it can ultimately provide. To borrow from Christopher Alexander’s The Synthesis of Form, the surface between problems and solutions is never cleanly divisible.

When ownership is split too rigidly, miscommunication seeps into the cracks, and drift begins. It also becomes a difficult conversation, because no one wishes to fall on the other side of the spectrum where Product Managers dictate to engineers what they must do and engineers slide into donkey tasking. The challenge is to find the balance where ownership is shared without reducing engineering work to mere execution.

3. The cost of drift

The consequences of misaligned ownership accumulate in subtle but destructive ways:

• Rework: Teams deliver features that technically function but solve the wrong problem. Requirements are interpreted too literally or too loosely.
• Erosion of trust: Each group blames the other for missed outcomes. Product claims Engineering “did not execute,” while Engineering claims Product “did not specify.”
• Strategic drag: Leadership spends disproportionate time arbitrating disputes rather than driving progress.

The most damaging cost, however, is not time or money. It is the loss of organisational coherence. Once ownership drifts, the organisation no longer acts as a system but as a collection of competing silos.

4. How other industries solved it

Other industries long ago recognised that separating intent from execution is unsafe and unproductive.

• In civil engineering, no one separates “what” and “how” when building a bridge. Safety demands integration. The design of a span is inseparable from the methods of its construction.
• In medicine, the surgeon does not outsource “what to cut” and “how to cut” to different committees. The decision and the act are bound together, because the cost of misalignment is measured in lives.

Systems thrive when intent and implementation remain bound together. They collapse when divided by organisational charts.

5. Towards shared ownership

The alternative is not chaos but co-ownership at the right layer. This is where the model of scale in / scale out / communicate, developed in An Evolution for a Revolution, provides useful guidance.

• Scale in: Engineers do not only deliver the how but also own part of the what. They shape requirements through feasibility insights, technical constraints, and systemic awareness. Their contribution defines the solution space, not merely the implementation.
• Scale out: In its original form, scale out described how platform teams reach stakeholders on a sprintly cadence to balance tactical and strategic execution. In this adapted context, Product Managers shift away from being sole owners of the what. Instead, they become supporters, sponsors, and integrators. Their role is to ensure that perspectives converge, that customer needs remain central, and that cross-functional dialogue does not collapse. It is important to be clear that this is an adaptation, preserving the spirit of scale out while applying it to the ownership conversation.
• Communicate: Both Product and Engineering share responsibility for the surface where intent meets implementation. It is this surface, continuously negotiated through shared language and open communication, that prevents drift. Communication is not a handover but an ongoing process of alignment.

When this model is embraced, the fracture between “what” and “how” begins to heal. Teams learn to hold the whole together rather than defending their individual lanes. The shift is subtle but powerful: ownership becomes collective, and clarity emerges from collaboration rather than contract.

6. The leadership responsibility

Leadership must set the tone for this shift. It is not enough to encourage collaboration rhetorically. Leaders must design structures that incentivise shared ownership and punish siloed optimisation. Metrics should reflect collective success , predictability, leverage, and alignment, not narrow outputs. RACI charts, useful as they may appear, should not become barriers that prevent people from stepping into the whole.

Leaders in technology too often accept misaligned ownership as the cost of scale. Yet history shows otherwise. Disciplines that achieved true scale, from aerospace to railways, integrated responsibility rather than fragmenting it. They created environments where those designing systems understood deeply how they would be built and used. The result was resilience, not fragility.

Closing reflection

Misaligned ownership is seductive because it looks tidy. It allows leaders to draw neat diagrams and assign blame when things go wrong. But beneath the surface, it corrodes systems from within. Technology organisations will only scale when they recover what older disciplines never lost: the courage to hold the whole.

This is one of the central lessons explored in my upcoming book, where I argue that lasting success depends not on separating “what, how, why” but on aligning them into a coherent system. To achieve that, organisations must embrace shared ownership, scale in the technical insight, scale out the supportive role of Product, and communicate continuously at the surface where ideas meet execution.

It is also important to be transparent that the application of scale out here is an adaptation. In its original form, scale out described how platform teams reach stakeholders on a sprintly cadence to balance tactical and strategic execution. The spirit of the concept, however, applies equally to the ownership challenge: broadening responsibility and ensuring integration across perspectives. By adapting it with honesty, we preserve both rigour and relevance. Only then can drift be stopped, coherence restored, and progress sustained.