How your org chart secretly shapes your systems

Look at most organisations and the pattern is the same. Marketing has its marketing technology, sales runs a CRM, pricing lives in spreadsheets. On a recent programme, every department expected the new system to mirror its own way of working, which led the sponsors to a sharper question: should we change the organisation rather than bend the system to fit it? That tension has a name.

Conway’s Law

In 1968 the computer scientist Melvin Conway put it plainly:

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

Conway had noticed the same thing across project after project: how teams were split, and how they talked to each other, showed up in the shape of the software. The Harvard Business Review rejected his paper at the time. Fred Brooks later gave the idea a wider audience in The Mythical Man-Month, and with microservices and agile delivery it is more relevant now than ever.

What it looks like

Take an energy supplier with four teams: Sales, Sales Operations, Pricing and Billing. Conway’s Law predicts a system in four matching parts. Where two teams talk often, their modules integrate well. Where they do not, you get separate databases, duplicated data and inconsistencies.

The customer feels the seams. Each team handles something like custom pricing in its own way, so a single customer ends up moving between several interfaces for tasks that should feel like one. The system has quietly published the org chart.

I have watched it happen

On a recent transformation, a well-meaning effort to mirror the organisation did exactly that. The design meant to streamline operations hard-coded the existing silos instead. Each team built components that fit its immediate needs, and those components then resisted joining up with everything around them.

Designing against it

The fix is to align structure and architecture on purpose rather than by default:

• Form teams around products and outcomes, not departments, so people own the whole flow.
• Choose flexible, modular architecture so the system can evolve as the business does.
• Invest in clear interfaces and integration layers (APIs) so components talk regardless of team boundaries.
• Review the architecture regularly against business goals, not the org chart, with stakeholders from across the business.
• Make sure leadership understands the law. Better decisions about structure and design start at the top.

The reverse manoeuvre

The arrow can point the other way. If you design the system deliberately, you can reshape the organisation. A single, unified customer-management system forces sales and customer service to work as one, and the silo between them starts to dissolve.

It is powerful and it is hard. It needs a clear picture of the operating model you want, systems designed to require those interactions, real support for people learning new ways of working, and the patience to iterate on both the system and the structure.

Watch the vendors

On large programmes, different teams bring different suppliers. Without someone accountable for overall coherence, you get fragmented, poorly integrated products that mirror the fragmented organisation that bought them.

The takeaway

Organisational structure and system design are two sides of one decision. Recognise that, design them together, and Conway’s Law turns from a trap into a tool. Ignore it, and your next system will simply publish your org chart again.

References

• Conway, M. E. (1968). “How do Committees Invent?” Datamation, 14(4), 28–31.
• Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press.
• Brooks, F. P. (1995). The Mythical Man-Month. Addison-Wesley.

---

Originally published on Medium.  ← All insights