Conway’s Law: The invisible hand that shapes your Product

When your organisation’s structure doesn’t match its goals, your products will quietly expose the gap — welcome to Conway’s Law.

Conway’s Law: The invisible hand that shapes your Product

Melvin Conway, a computer scientist, observed in 1967:

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

In other words: the way we talk is the way we build.

This is not a conscious choice. It’s the result of human nature and organisational dynamics:

• We talk most to people in our own team.

• We design around our own responsibilities.

• We optimise for our own KPIs.

• We avoid complex cross-team communication if we can.

I have witnessed that this is not only true for products, but Conway's law is also true in organisations offering a service. Replace product by service and you will recognize that the quality or the efficiency of the service is often compromised by organisational boundaries. When different departments work together to offer an end2end service every department tends to optimize for their own part of the service without having the end2end service in mind.

Why You Can’t Ignore Conway’s Law

If you keep your organisation as it is, Conway’s Law will lock in its structure into your products and processes. That means you can’t just “redesign the system” without also looking at the org setup.

In fact, organisations arhitects sometimes use Inverse Conway Manoeuvre: 'design your organisation to fit the architecture you actually want'.

But here’s the tricky part:

Many organisations today want both hierarchical clarity and network agility. And that’s where the question always comes:

Do we place the hierarchy on the competence axis, or the delivery axis?

Competence Axis vs. Delivery Axis

• Competence axis = hierarchy groups people by expertise (e.g., UX, backend, logistics).

• Delivery axis = hierarchy groups people by end-to-end delivery value stream (e.g., “Customer Onboarding”, “Cargo Handling”).

  

  Delivery axis vs Competence axis

Delivery is often the result of an end-to-end process, which usually cuts across competence silos.

Why Not Both?

I advocate a dual model:

• A delivery-oriented organisation → to focus on value streams, end-to-end accountability, and speed to market.

• A competence-oriented organisation → to grow expertise, maintain standards, and enable career development.

Designing a dual model can be resolved using two structures that exists next to each other and are complementary to each other :

1. Hierarchical structure (formal reporting lines, budgets, performance reviews).

2. Network structure (communities of practice, cross-functional collaboration, knowledge sharing).

The Big Decision: Which Gets the Hierarchy?

Option 1 – Hierarchy on Delivery

• Pros

  • Clear accountability for business outcomes.

  • Easier to align priorities with strategy.

  • Teams own the full flow from idea to delivery.

  
  

• Cons

  • Risk of knowledge fragmentation.

  • Skills development can be inconsistent.

  • Experts may feel isolated in delivery teams.

Best when speed of delivery, customer focus, and end-to-end ownership are top priorities.

Option 2 – Hierarchy on Competence

• Pros

  • Strong skill development and knowledge depth.

  • Easier to manage shared standards and best practices.

  • Flexibility to move people between projects.

  
  

• Cons

  • Risk of delivery handovers and silos.

  • End-to-end accountability can blur.

  • Priorities may become skill-centric, not value-centric.

  
  

Best when high technical complexity or regulated domains demand deep, consistent expertise.

Guidance on Choosing

1. Start with the value streams, know your end-to-end delivery flows before making the call.

2. Identify your biggest pain, is it speed and customer responsiveness, or consistency and skill depth?

3. Consider scale and stability, fast-changing products benefit from delivery hierarchy; stable, complex systems may need competence hierarchy.

4. Be ready to evolve, Conway’s Law means the structure will “leak” into the work, so revisit your setup as strategy and architecture shift.

I have observed organizations where the hierarchy was structured around the delivery axis. This approach ensured a strong emphasis on delivery at all levels, contributing to successful outcomes. However, the downside was that management often engaged in micromanaging the delivery process, with even senior management dedicating most of their time to operations rather than focusing on strategy and future preparedness. I believe this is a natural tendency for management on the delivery axis. Therefore, I prefer to establish hierarchy based on the competence axis, as this encourages a shift towards being less operational and more strategic, facilitating the overall operation.

Final Thought

Conway’s Law isn’t a fixed rule to obey or break — it’s a reminder that structure and outcomes are always linked.

There is no single “correct” answer to where hierarchy should sit. The goal is to find the best fit for your current context, knowing that context will change.

The optimum balance between delivery and competence will shift as your market, technology, and strategy evolve.

The key is to make a deliberate choice today, monitor its impact, and be ready to adjust tomorrow.

Don’t leave it to chance — keep designing your organisation as carefully as you design your products or services.

We always welcome your experiences and feedback.