Cart 0
Share
Have you ever worked in an organisation where delivering something that should be simple requires five teams, three meetings, two approvals and several handovers?
We often blame the process, the technology or the people. But the real problem might be how the organisation itself is structured.
This is where Conway’s Law becomes very useful.
What is Conway’s Law?
In 1968, computer scientist Melvin Conway published a paper called How Do Committees Invent? in which he made an observation that has become increasingly relevant as organisations have become more digitally enabled.
Conway’s Law is commonly stated as:
“Any organization that designs a system … will produce a design whose structure is a copy of the organization’s communication structure.”
In simple terms: The systems we create tend to reflect the way our people and teams are organised and communicate.
Martin Fowler describes the same idea by pointing out that software architectures often look remarkably similar to the organisation of the teams that built them.
But Conway’s Law is not only interesting for software architects. It has significant implications for leaders, product managers and anyone thinking about organisational design and flow.
A simple example: imagine an organisation building an online shopping platform.
The organisation has separate departments:
Business → UX → Development → Testing → Operations
A new feature might therefore travel like this:
Business defines it → UX designs it → Developers build it → Testers test it → Operations deploys it
Notice what has happened. The structure of the organisation has started creating the structure of the delivery system. There are boundaries between departments. So there are boundaries in the work. There are handovers between departments. So there are handovers in the delivery process. There are communication gaps between departments. So misunderstandings and delays start appearing between different parts of the solution.
The system begins to mirror the organisation that created it. That is Conway’s Law in action.
Another example: building a mobile banking feature. Imagine a bank wants customers to be able to freeze their bank card from the mobile app. Sounds relatively simple.
But delivering it requires:
- the Mobile App team
- the Cards team
- the Integration team
- the Security team
- the Database team
- the Testing team
- the Infrastructure team
The customer experiences this as one feature: “Freeze my card.”
But inside the organisation it may be treated as work belonging to seven different teams. Suddenly the organisation needs coordination meetings, dependencies, handovers, approvals and prioritisation discussions. The problem isn’t necessarily that these teams are ineffective. The problem is that the organisational boundaries don’t match the flow of customer value.
Functional teams versus value-aligned teams
Consider two different ways of organising the same people.
Organisation A: Functional teams
UX Team → Front-End Team → Back-End Team → Testing Team → Operations
Each team specialises in one part of the solution.
Work moves between them.
The result is likely to be significant coordination and handovers.
Organisation B: Value-aligned teams
Instead, imagine multidisciplinary teams organised around products or value streams.
Customer Onboarding Team
Product + UX + Development + Testing + relevant technical capabilities
Payments Team
Product + UX + Development + Testing + relevant technical capabilities
Account Management Team
Product + UX + Development + Testing + relevant technical capabilities
Now many of the conversations required to deliver value happen inside the team rather than between teams.
This can reduce dependencies and allow teams to take greater end-to-end ownership.
This thinking is strongly reflected in modern approaches such as Team Topologies, where teams and their interaction patterns are deliberately designed to improve flow and reduce unnecessary dependencies.
The important part -> it is about communication, not just the org chart
There is an important nuance here.
Conway’s Law does not simply say:
“Your software looks like your org chart.”
It is really about communication structures.
Two teams may appear completely separate on an organisational chart but work together every day.
Conversely, two groups may report to the same executive yet barely communicate.
So when trying to understand how Conway’s Law is affecting your organisation, don’t only look at reporting lines.
Look at the real network of work.
- Who needs to speak to whom to get something delivered?
- Where do decisions happen?
- Where are the handovers?
- Where do teams wait for other teams?
- Where do dependencies repeatedly appear?
Those patterns tell you far more about the organisation than the boxes on an organisational chart.
Conway’s Law can also be used deliberately
Here is where the idea becomes powerful. If organisational structures influence the systems we create, perhaps we can deliberately design our teams and communication patterns around the systems and outcomes we want.
This idea is often called the Inverse Conway Maneuver.
Instead of accepting: Organisation structure → Communication patterns → System design
we ask: What system and flow do we want? → What communication needs to happen? → How should we organise our teams?
For example, if we want a team to own a customer experience from idea through to production, we should consider bringing together enough of the required capabilities for that team to operate with minimal external dependencies.
That does not mean every team needs every possible skill.
Nor does it mean specialist or platform teams are bad.
The goal is not zero communication between teams. Collaboration is essential.
The goal is to avoid creating an organisation where routine delivery requires excessive coordination across organisational boundaries.
A practical way to spot Conway’s Law in your organisation
Take one important piece of customer value. Perhaps opening an account, processing an order, launching a promotion or adding a new payment method.
Then follow that work from beginning to end.
Ask:
- How many teams does it touch?
- How many handovers occur?
- How many approvals are required?
- Where does the work wait?
- Which dependencies occur repeatedly?
- Which teams cannot deliver without another team?
You may discover that what initially looked like a delivery problem is actually an organisational design problem.
And adding another process, meeting, governance forum or coordination role may simply treat the symptom.
Sometimes the better question is: Have we organised ourselves in a way that makes delivering value unnecessarily difficult?
The takeaway
Conway’s Law gives us a powerful lens through which to view organisations. Your organisation is part of your architecture.
How you divide responsibilities, organise teams and enable people to communicate influences the systems, processes and customer experiences you create.
So if you want:
- faster flow,
- greater team autonomy,
- fewer dependencies,
- clearer ownership,
- faster decision-making, and
- better customer outcomes,
don’t only change the process. Don’t only change the technology. Don’t only train the teams. Look at how the organisation itself is designed.
Because sometimes the biggest constraint to agility isn’t the way people are working. It is the system we have designed around them.
