Conway's Law is the observation that systems mirror the communication structures of the teams that build them. Applying it in practice splits into five different tasks, each with its own evidence, levers, and audience. This page is the index. Pick the guide that matches the situation in front of you.

For the theory and why the law holds, read [What Is Conway's Law?][conways-law] first.

## Pick your guide

--card--
🛠️ **[Smooth platform team friction][smooth]**

Use this when a platform team is bottlenecked by too many product teams depending on it. Three communication-cost levers and measurable friction thresholds.
--card--
🧩 **[Serve the needs of an organization][serve]**

Use this when you can see broken team-to-code alignment and need to pick the right organizational change (merge, split, platform carve-out, or ownership move).
--card--
🔍 **[Diagnose delivery friction][diagnose]**

Use this first, when you suspect organizational friction is slowing delivery. A copyable git query ranks files by distinct-author count to surface congestion candidates.
--card--
🧬 **[Decode a software deployment][decode]**

Use this when you want to predict whether a proposed merge or split will land cleanly. Read services, contracts, pipelines, and runbooks as fossil records of the org that shipped them.
--card--
🗣️ **[Pitch org design for better architecture][pitch]**

Use this when the diagnosis is clear but the conversation is hard. Audience-specific scripts for architects, leaders, your own team, open-source communities, and conferences.
## How the guides relate

A typical sequence: [diagnose][diagnose] surfaces congested modules, [decode][decode] explains why the deployment shape produced them, [serve][serve] picks the organizational change, [smooth][smooth] handles the special case of a platform team, and [pitch][pitch] gets buy-in for the change. You will rarely run all five in one project; pick the entry points that match your role and current friction.

## Related reading

* [Fundamentals of Technical Leadership][fundamentals-leadership] for leaders who own headcount and want to treat team design as architecture.
* [Fundamentals of Software Architecture][fundamentals-architecture] for how Conway's Law sits alongside coupling, cohesion, and other architectural forces.
* [Wiring the Winning Organization (book review)][wiring] for the delivery-systems lens on org-driven software outcomes.
* [Fearless Change Patterns (book review)][fearless-change] for the patterns library that pairs with the pitch guide when you need to land an organizational change.

## References

* [What Is Conway's Law?][conways-law], the explanation article defining the pattern, its mechanisms, and its limits.
* [Team Topologies][team-topologies], Matthew Skelton and Manuel Pais on team-structure patterns that align with different software architectures.
* [CodeScene][codescene], Adam Tornhill's tool for visualizing organizational alignment in code and detecting congestion.

[conways-law]: https://jeffbailey.us/what-is-conways-law/
[smooth]: https://jeffbailey.us/blog/2026/05/13/how-do-i-smooth-platform-team-friction/
[serve]: https://jeffbailey.us/blog/2026/05/13/how-do-i-serve-organizational-needs/
[diagnose]: https://jeffbailey.us/blog/2026/05/13/how-do-i-diagnose-software-delivery-friction/
[decode]: https://jeffbailey.us/blog/2026/05/13/how-do-i-decode-software-deployments/
[pitch]: https://jeffbailey.us/blog/2026/05/13/how-do-i-pitch-org-design-for-better-architecture/
[fundamentals-leadership]: https://jeffbailey.us/fundamentals-of-technical-leadership/
[fundamentals-architecture]: https://jeffbailey.us/fundamentals-of-software-architecture/
[wiring]: https://jeffbailey.us/a-wiring-the-winning-organization-book-review/
[fearless-change]: https://jeffbailey.us/a-fearless-change-patterns-book-review/
[team-topologies]: https://teamtopologies.com/book
[codescene]: https://codescene.com/