Conway's Law: how it may be undermining your business today and how Agile can help

There is a silent contagion in many organisations that, once embedded, creates major delivery inefficiencies and quickly introduces unnecessary cost and delay.

It’s called Conway’s Law.

Key takeaways

• Conway’s Law means your systems often mirror your org structure (and its siloes).
• Fragmented communication creates fragmented products, slower delivery, and higher cost.
• Agile works best when it deliberately improves cross-team communication and integration.
• Cross-functional teams and tight feedback loops reduce handovers and rework.
• You can start small: pilots, team design tweaks, and leadership behaviours matter most.

Challenge / why this matters

Conway’s Law suggests that any system designed by an organisation will reflect its communication structure.

In plain terms: if your organisation is siloed, your products and processes tend to become siloed too.

That can show up as:

• Disjointed customer journeys (each department optimises its own bit)
• Integration problems (systems don’t “fit” together cleanly)
• Slow decision-making (too many handovers and approvals)
• Duplication of work (multiple teams solving the same problem)
• Delivery delays (late discovery of dependencies and misalignment)

If this sounds familiar, it often links to estimation pain too, where early confidence turns into late surprises.

You may also find it helpful to read why early estimates often create false confidence ↗.

Approach / how it works

Conway’s Law was formulated by computer scientist Melvin Conway in 1967.

It’s commonly summarised as: “organisations design systems that mirror their communication structures”.

To make this practical, it helps to understand three things:

• Where it came from
• Why it happens
• What it does to delivery performance

1) Background and establishment

Conway introduced the idea in his paper How Do Committees Invent?

He observed a repeating pattern: when teams were separated by communication barriers, the systems they produced were also fragmented.

Over time, organisations have repeatedly seen the same effect across:

• Software products
• Business processes
• Physical products and services
• Operating models and governance

2) How Conway’s Law occurs

Conway’s Law occurs because people naturally communicate along formal structures.

If the organisation is split into departments with limited day-to-day collaboration, the delivery work tends to follow those boundaries too.

Common drivers include:

• Communication barriers (hierarchy, departmental boundaries, physical separation)
• Over-specialisation (teams optimise locally, not end-to-end)
• Coordination challenges (misaligned goals, timelines, and priorities across groups)

3) Impacts on organisations

When siloes dominate, the product and delivery system often becomes harder and more expensive to run.

Typical impacts include:

• Fragmented systems that don’t integrate smoothly
• Increased complexity (harder maintenance, scaling, and change)
• Inefficiency through duplicated effort and rework
• Stifled innovation (less cross-pollination of ideas)
• Delayed delivery because integration and decision-making happen late
• Higher costs due to delay, churn, and heavyweight coordination

In the UAE and GCC, these effects can be amplified by:

• Multi-vendor dependencies
• Cross-functional handovers
• Hierarchical decision paths
• Risk aversion driving heavier governance rather than better flow

If you want a fast way to diagnose whether your team structures are creating delivery friction, this is a useful companion read.

Read Team Health Assessments in Dubai: diagnose delivery friction ↗.

Results / expected outcomes

Conway’s Law isn’t “good” or “bad” by itself.

It’s a mirror.

If you improve the way teams communicate, collaborate, and make decisions, the systems you build tend to improve too.

With a practical Agile approach, organisations typically see:

• Fewer handovers and less waiting (better flow)
• Earlier detection of integration and dependency issues
• Clearer ownership across end-to-end value streams
• Reduced rework due to tighter feedback loops
• More predictable delivery (less “late surprises”)

A helpful lens is to focus on smaller batches of work and faster feedback, rather than adding more approval steps.

You can explore that thinking here: Scrum: more faster cheaper delivery ↗.

Practical takeaways / what to do next

Here are practical steps that work well in real organisations (without a big-bang restructure).

1) Map communication before you redesign teams

Start by mapping how work actually flows:

• Which teams must collaborate to deliver a customer outcome?
• Where do handovers happen?
• Where do decisions get delayed?
• Where do you see repeated rework or “back-and-forth”?

Then align team boundaries to reduce unnecessary handovers.

2) Design around value streams, not departments

Where possible, organise delivery around end-to-end outcomes (a service, journey, product line).

That often means:

• Cross-functional teams with the skills to deliver
• Clear ownership of outcomes (not just tasks)
• Fewer dependencies on “other departments” to finish work

If your organisation is also tackling procurement and vendor dependencies, this can become a major lever for delivery speed.

Read how Lean-Agile Procurement accelerates value delivery ↗.

3) Use Scrum Events to reduce misalignment

Scrum Events (aka Ceremonies) can materially improve communication when done with discipline:

• Daily Scrum: surface blockers and re-plan quickly
• Sprint Review: align stakeholders on what’s working (and what’s not)
• Retrospective: improve the system of work, not just outputs

The goal is not “more meetings”.

The goal is faster feedback and fewer surprises.

4) Make leadership behaviours match the operating model

Agile fails fast when leaders still operate in command-and-control mode.

Practical leader shifts include:

• Ask “what’s the risk and dependency?” early, not late
• Empower teams to solve problems within clear boundaries
• Reward collaboration across siloes, not local optimisation
• Attend reviews and retrospectives to support learning and improvement

5) Start with a small pilot that proves the point

A safe approach is to pilot a value stream or product area where:

• Dependencies are visible
• Stakeholders are engaged
• You can show measurable improvements (lead time, rework, predictability)

Then scale based on evidence, not opinion.

If you want a more structured diagnostic starting point, explore Agile Maturity Assessment options ↗.

Conclusion

Conway’s Law is a warning and an opportunity.

If your communication structures are fragmented, your delivery outcomes often will be too.

Agile helps by:

• Improving communication and alignment through short feedback loops
• Reducing siloes with cross-functional teams
• Shifting focus from local optimisation to end-to-end outcomes

You don’t need a massive re-org to begin.

Small, deliberate changes to team design, leadership behaviours, and feedback loops can create outsized impact.

Contact us

If you’re seeing repeated delays, integration pain, and cross-team friction, we can help you diagnose the root causes and design practical next steps.

Book a 30-minute diagnostic call ↗

‍