## Prerequisites

This guide assumes:

* **Familiarity with Conway's Law.** Read [What Is Conway's Law?][conways-law] first if "communication structure shapes system structure" sounds new.
* **Concrete evidence from your own org.** A diagnosis from [How Do I Diagnose Delivery Friction?][diagnose] or a deployment decode from [How Do I Decode a Deployment?][decode] gives you the artifacts to point at. Without evidence, the pitch sounds like opinion. Start there if you have not yet.
* **An audience.** Architects, product leaders, your own team, an open-source community, or conference attendees. The pitch shifts with each.

## Bring both halves to every conversation

Most conversations about software architecture skip the organizational layer entirely. Engineers debate microservices versus monoliths. Leaders debate team structure in isolation. The two conversations rarely connect. Use Conway's Law to make the connection explicit.

In conversations about architecture, bring the org chart. In conversations about reorganization, bring code examples. They are the same conversation, viewed from two sides.

## Use the audience-specific scripts

Match the framing to who is in the room. Pick the one script for your audience and lift it directly.

1. **Architects and tech leads.** "This module is owned by four teams. That is why it is slow to change. If we want faster delivery, we need to assign it to one team, which means reorganizing here. Is that worth it?"
2. **Product and business leaders.** "We are slow shipping feature X. The reason is not the architecture. Three teams need to coordinate. If we consolidated ownership under one team, we would ship in half the time."
3. **Your own team.** "We are editing files that three other teams also edit. That is coordination overhead in every PR. We should either own that module cleanly, or use a clearer API so we stop editing their code."
4. **Open-source communities.** "Maintenance is bottlenecked on two reviewers. The project's velocity reflects how many people can credibly merge code. If we want faster releases, we need more maintainers, or smaller modules with clearer ownership."
5. **Conferences and writing.** Share specific examples. Show the git history. The code graph reveals where communication is expensive. When you can point to merge conflicts, slow reviews, and shipping delays and say "that is because of who-owns-what," organizational conversations shift from ideology to pragmatism.

## Make the cost visible

A developer community that takes Conway's Law seriously produces software that serves its external users better. Coordination cost is a tax users pay through bugs, slow features, and missing integrations. Make that tax visible, and the case for organizing differently writes itself.

Use the numbers from the diagnosis: hours waiting for cross-team review, percentage of PRs blocked on someone outside the team, calendar minutes spent in alignment meetings. Numbers move conversations that abstractions cannot.

## Verify

You'll know it worked when at least one colleague brings the org chart to an architecture discussion without prompting, and when architecture-decision documents start naming team owners alongside services.

## After the yes

A successful pitch is the start, not the finish. Hand the audience the next action:

* If they own headcount or org structure, point them to [How Do I Serve Organizational Needs With Conway's Law?][serve] for the change menu.
* If they own a platform team, point them to [How Do I Smooth Platform Team Friction?][smooth] for the levers.
* If they want to see the friction themselves, point them to [How Do I Diagnose Delivery Friction?][diagnose] and offer to run the query together.

A pitch without a next step decays. The audience agrees, leaves the room, and the urgency evaporates by the next sprint.

## Troubleshooting

### Leaders agree with the diagnosis but block the reorganization

The cost of reorganizing scared them. Reframe the cost the other way. Count engineering hours wasted on coordination per quarter: merge-conflict resolution, cross-team PR review waits, alignment meetings. Coordination overhead is invisible until you count it. Once counted, the reorganization usually becomes the cheaper option.

### The audience treats Conway's Law as deterministic fate

The law is descriptive, not prescriptive. You can change the communication structure (the inverse Conway maneuver), and the architecture will follow. Lead with examples of teams that have done it: a platform team carve-out, a domain-aligned team split, a merger of two co-editing teams.

### You see misalignment but cannot point to specific costs

Measure three things over a single sprint:

* Median PR review wait time, grouped by reviewing team.
* Merge-conflict frequency on the top ten most-edited files.
* Calendar minutes per engineer tagged "sync," "alignment," or "coordination."

When you can attach hours per quarter to misalignment, the case writes itself.

## Where to go next

* Read [How Do I Serve Organizational Needs With Conway's Law?][serve] to pair the pitch with a concrete organizational change.
* Review [Team Topologies][team-topologies] for the vocabulary that helps leaders engage with team-structure conversations.

## References

* [What Is Conway's Law?][conways-law], the explanation article defining the pattern.
* [How Do I Diagnose Delivery Friction?][diagnose], the companion guide for collecting evidence.
* [How Do I Decode a Deployment?][decode], the companion guide for reading existing deployment shape.
* [How Do I Serve Organizational Needs With Conway's Law?][serve], the companion guide for picking the change.
* [Team Topologies][team-topologies], Matthew Skelton and Manuel Pais on team-structure patterns.

[conways-law]: https://jeffbailey.us/what-is-conways-law/
[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/
[serve]: https://jeffbailey.us/blog/2026/05/13/how-do-i-serve-organizational-needs/
[team-topologies]: https://teamtopologies.com/book