Conway's Law in Talent Architecture: Designing Teams to Match the Software You Want

60-Second Summary

Conway's Law (1968): your software architecture will mirror your team's communication structure — whether you like it or not.
If 3 teams own a compiler, you will ship a 3-pass compiler. If 6 teams own a payment flow, you will ship 6 layers of payment middleware.
Inverse Conway Maneuver: design teams to mirror the architecture you WANT, then let the system follow.
Used at scale by Amazon ('two-pizza teams'), Spotify ('squads'), and the UK Government Digital Service (GDS).
HR sits at the centre of this — team design is now an architectural decision, not just a people decision.

If you walk into a tech company and read their codebase before meeting anyone, you can sketch the org chart with surprising accuracy. Conway proved this in 1968 and the pattern has not weakened in 58 years. The org IS the architecture. Which means HR is, quietly, an architect.

Conway's Law in one sentence

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
— Melvin Conway, 1968

Translation: every interface between two teams becomes an interface in the code. Every approval chain becomes a coupling. Every Slack channel that does not exist becomes a missing API.

1968

Conway publishes the paper

Datamation — rejected by Harvard Business Review first

100%

of organisations tested still match the pattern

MIT/Harvard replication studies, 2008–2022

deployment frequency for companies using Inverse Conway

DORA / Accelerate State of DevOps, 2023

The Inverse Conway Maneuver

If team structure dictates architecture, then to change the architecture, change the teams first. This is the Inverse Conway Maneuver — popularised by Skelton & Pais in Team Topologies (2019).

Conway-default vs Inverse Conway

Conway-default (most companies)

Reorgs follow business unit politics
Architecture is whatever the orgs produce
Microservices end up as 'distributed monolith'
Cross-team handoffs everywhere = latency, bugs, finger-pointing

Inverse Conway

Architect the target system first (e.g. 6 bounded contexts)
Then design 6 stream-aligned teams to own them
Each team has full ownership: build, deploy, on-call
Interfaces are intentional — APIs and contracts, not Slack DMs

Team Topologies — four team types

Skelton & Pais, 2019 — the canonical four. Most engineering orgs need ~70% stream-aligned, 20% platform, 10% enabling/subsystem.

Team type	Purpose	Example
Stream-aligned	Owns a slice of the product end-to-end	Checkout team, Onboarding team
Platform	Provides internal services to stream teams	Developer platform, Data platform
Enabling	Coaches stream teams on a new capability	AI enablement team, SRE coaches
Complicated-subsystem	Owns deeply specialised tech	Search ranking, ML inference

How HR runs an Inverse Conway redesign

Sit with the CTO/Chief Architect. Sketch the target architecture on a whiteboard — bounded contexts, services, data flows.
Draw the IDEAL team map — one stream-aligned team per bounded context, supported by platform teams.
Compare to today's org chart. The deltas are the reorg.
Move people in waves, not in one Big Bang. Three quarters is normal.
Update the operating model: each new team owns hiring, on-call, and roadmap for its slice. No more 'central architecture committee' bottlenecks.
Measure: DORA metrics (deployment frequency, lead time, change failure rate, MTTR) should improve within 2 quarters.

From hierarchy to stream-aligned mesh

Step 1 — Architecture diagram
What system do we want to operate?
Step 2 — Team boundaries
One team per bounded context. End-to-end ownership.
Step 3 — Platform layer
Internal services so stream teams move fast
Step 4 — Enabling coaches
Teach new capabilities without becoming a dependency

Real-world signal

Amazon's 'two-pizza team' rule is Inverse Conway applied at scale: any team must be small enough to feed with two pizzas. That constraint cascaded into SOA and eventually AWS. The team design produced the architecture, not the other way around.

Takeaways

Your codebase already looks like your org chart. The only question is whether you chose it.
HR is an architectural function in any tech company over 50 engineers.
Reorgs without an Inverse Conway lens regenerate the same problems with different names.

References

Conway, M.E. — How Do Committees Invent? — Datamation, 1968
Skelton & Pais — Team Topologies — IT Revolution Press, 2019
DORA — Accelerate State of DevOps 2023 — Google Cloud DORA
MacCormack, Baldwin, Rusnak — Exploring the Duality Between Product and Organizational Architectures — Harvard Business School, 2008

Written by Pawan Joshi. Sources cited inline. Last updated 2026-05-21.