Conway's Law and your knowledge architecture

In 1967, Melvin Conway observed that organisations design systems that mirror their own communication structure. A company with four development groups will produce a product with four major components, regardless of whether four is the right number. The teams build what they can coordinate, and the coordination boundaries become the system boundaries.

Conway's Law has been validated repeatedly in software engineering, to the point where many organisations now practise "reverse Conway" deliberately: structuring teams to match the desired system architecture rather than letting the system architecture emerge from the existing team structure. If you want a microservices architecture, organise into small, service-owning teams. If you want a monolithic product, keep the team unified.

The less-discussed corollary is that Conway's Law doesn't just apply to team structure. It applies to knowledge structure. The way knowledge is organised, documented, and accessible within an organisation shapes what that organisation can build, just as the team structure does.

Knowledge architecture as system architecture

If engineering knowledge is siloed by team, the systems those teams build will be siloed too, not because the architects intended it but because the teams lack the cross-team context to build integrated systems. Team A builds their component based on their understanding of Team B's system, and that understanding is incomplete because Team B's knowledge is locked in Team B's heads and tools.

If knowledge flows across teams through shared documentation, the systems can be integrated more naturally, because the teams building them have access to each other's context, constraints, and reasoning. The integration quality of the system reflects the integration quality of the knowledge.

This suggests that investing in knowledge infrastructure is, indirectly, investing in system architecture. A unified knowledge layer where every team's documentation is searchable by every other team produces better integrated systems than a fragmented landscape where each team's knowledge is isolated in their own tools.

The practical implications

When you restructure teams, restructure knowledge access. If two teams are merging, their knowledge needs to merge too: shared documentation, unified search, connected tools. If a team is splitting, each new team needs access to the full historical context, not just the parts they're taking ownership of.

When you plan an integration project, check the knowledge first. Can each team access the other team's documentation, decision records, and system context? If not, the integration will be harder than it needs to be because the teams are working with incomplete understanding of each other's systems.

When you diagnose a system architecture problem, check the knowledge architecture. If two systems that should be integrated aren't, ask whether the teams that own them have access to each other's context. The architecture follows the knowledge, and fixing the knowledge flow often fixes the architectural issues downstream.

When you adopt AI tools, feed them the full picture. AI agents that can search across all teams' knowledge through MCP can suggest integrations and identify conflicts that agents limited to a single team's context would miss. The AI's output reflects the knowledge it can access, which is Conway's Law applied to artificial intelligence.

The knowledge layer as the real org chart

There's a useful provocation here: the knowledge layer might be more important than the org chart.

The org chart defines reporting relationships and authority. The knowledge layer defines what people can actually know and therefore what they can effectively do. An engineer who reports to Team A but has full access to Team B's documentation and decision history can coordinate with Team B as effectively as someone who sits in Team B's standups. An engineer who reports to Team A and has no access to Team B's knowledge cannot coordinate effectively regardless of what the org chart says.

This is why organisations where knowledge flows freely across teams tend to outperform organisations where knowledge is locked in team silos, even when the siloed organisation has better individual talent. The knowledge architecture amplifies or constrains what the talent can produce, and the architecture is more modifiable than the talent.

Investing in connected, searchable, self-maintaining documentation isn't a documentation project. It's an architectural project that shapes what your organisation can build.

Frequently asked questions

How do we apply reverse Conway to knowledge? If you want integrated systems, ensure your knowledge is integrated: shared documentation, cross-team search, connected tools. If you want modular systems, ensure each module's knowledge is self-contained and well-documented at its boundaries. Design the knowledge architecture to match the desired system architecture.

Does this only apply to engineering? Conway's Law applies wherever teams build interconnected outputs. Product teams, design teams, and operational teams all produce work that needs to integrate, and the quality of that integration depends on the knowledge flowing between them.

What's the first step? Audit whether teams can access each other's documentation. If Team A can't search Team B's knowledge, you have a knowledge silo that will produce a system silo. Connect the sources and make the knowledge searchable across boundaries.

Related reading: The two-pizza team needs a wiki, The knowledge scaling problem, How to break down information silos. Related pages: Self-writing docs, One search, Connections.