The Split That Breaks Teams: When 'How' Is Disconnected from 'What' and 'Why'

In many organisations, engineering and product roles are defined by a deceptively simple split:

• Product owns the what and the why
• Engineering owns the how

At first glance, this seems logical. It suggests a division of labour that preserves clarity and specialisation. However, when this split is not actively managed with mutual understanding, shared context, and clearly defined boundaries, it creates misalignment that damages the quality of decisions, the clarity of communication, and the cohesion of the product itself.

The resulting tension is subtle, but it is pervasive. Engineers begin to feel like implementers of decisions they did not shape. Product managers feel isolated, expected to drive outcomes with limited insight into feasibility or constraints. Communication becomes theatrical, not strategic.

The Surface and the Substance

Christopher Alexander, in The Synthesis of Form, draws a critical distinction between the surface of a system, what it exposes to the world, and the structure beneath it, which gives the system integrity.

When these elements become decoupled, when surface evolves without regard for internal structure, the result is dysfunction. The system becomes brittle, incoherent, and fragile.

The same applies to teams. Product defines the surface: what the system promises, how it behaves, what outcomes it intends. Engineering gives that system its internal strength: constraints, implementation details, performance boundaries.

If those elements are shaped in isolation, the system loses integrity. The team begins to overpromise and underdeliver, not due to incompetence, but due to structural drift.

Shared Ownership Does Not Mean Overstepping

Misalignment does not only flow one way. While product and design may inadvertently overstep into architecture, the inverse is equally corrosive: engineering overstepping into product ownership.

This often takes the form of engineers assuming accountability for prioritisation, typically in response to gaps in upstream clarity or in an effort to move things forward. But without full context of business constraints, customer insights, or commercial pressures, engineering-led prioritisation tends to optimise for local certainty, not strategic value.

It feels responsible. It looks efficient. But the result is misaligned effort, missed opportunities, and eventual finger-pointing when delivery does not meet expectations.

A team that builds in isolation cannot claim surprise when its outputs fail to resonate.

Healthy collaboration is not about territory and more about shared framing.

The reality is simple:

• Product must never run technology : doing so breaks trust, undermines architecture, and often leads to brittle systems optimised for demos rather than durability.
• Engineering must never define product strategy : doing so bypasses market context, misreads opportunity, and isolates the team from customer insight.

Other common forms of overreach include:

• Product teams redefining architectural constraints to suit a timeline
• Engineering teams deprecating or delaying roadmap items without consultation
• Designers bypassing feasibility conversations and shipping concepts no team can sustain

These are not acts of sabotage. They often stem from good intent. But without structure and trust, good intent does not prevent systemic failure.

Engineers must have influence over feasibility and trade-offs. Product must steer based on impact and customer context. Each side brings critical information the other lacks.

Strong teams accept that overlap is not a flaw, mostly a feature. They establish shared rituals for framing work, such as shaping sessions, early technical reviews, and collaborative roadmap alignment.

Collaboration does not require identical roles. It requires mutual respect and synchronised intent.

What Happens When We Let the Organisation Design the System

Without shared framing and deliberate boundaries, Conway's Law stops being a warning and becomes a self-fulfilling failure mode:

“Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure.”

This is Conway's Law in action where the organisational structure, rather than sound architecture, dictates design. Teams build around themselves instead of building around the system’s purpose.

Consider a typical scenario: an engineering team, operating with limited product direction, begins to prioritise based on perceived urgency and available capacity. At the same time, a product function, pressured by stakeholders, commits to timelines tied to roadmap optics, not delivery reality.

On the surface, progress continues. Tickets move. Demos appear on time. But no one owns the architecture, no one owns the trade-offs, and no one reconciles intent with execution.

Scalability suffers. Technical debt grows. No one notices until it is too late.

In these environments:

• Tooling decisions are made for convenience, not longevity
• Codebases reflect political boundaries, not functional cohesion
• Platform leverage erodes, replaced by duplicated effort

The system may appear functional—but its long-term viability becomes fragile. The team has lost the opportunity to design for scale. It builds for short-term coordination rather than enduring structure.

A More Coherent Model

To move beyond dysfunction, teams must not only adopt shared responsibilities. They must also establish clear protocols for alignment. These are not rituals for form’s sake, but high-leverage contact points where roles meet, information flows, and trust is reinforced.

A sound protocol might include:

• A single source of truth for priorities, shared by product and engineering
• Architecture decisions explicitly paired with business value outcomes
• Regular alignment points during planning, where roadmap intent and feasibility meet
• Feedback loops through retrospectives, focused not only on delivery but on decision quality
• Continuous synchronisation through shared roadmapping, to reduce divergence over time

These contact points are not optional. They form the interface between teams—the human equivalent of API boundaries. Their absence guarantees drift.

Instead of rigidly dividing ownership of how, what, and why, mature teams treat these as shared responsibilities with different centres of gravity:

• Framing the problem: Product and engineering shape the framing together, based on insight and context
• Understanding constraints: Engineering leads, but product is expected to understand and reflect them
• Shaping delivery: Engineering owns execution, but product collaborates on trade-offs
• Communicating intent: Everyone contributes to clarity, narrative, and context

This model avoids collapse into command-and-control or vague consensus. It also mitigates the impact of Conway’s Law by ensuring architectural decisions are not shaped by organisational silos, but by system integrity and shared understanding. It preserves ownership while encouraging strategic tension and creative disagreement that strengthens design.

A Final Reflection

Strong products follow coherent systems. Coherent systems follow teams that align on more than just intent. They align on responsibility.

When the surface lies about the system, trust decays. When engineering is sidelined during framing, the result is not delivery. It is disconnect.

Teams must resist the false clarity of cleanly split roles. A strong product surface must reflect what the system can truly support. That requires overlapping understanding, structured collaboration, and shared accountability.

You cannot ship alignment. You must build it.