## 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.
* **Access to git history.** You will read commit patterns over the last quarter.
* **Visibility into the org chart.** You need to know which engineers belong to which teams.
* **Influence over team boundaries, or a stakeholder who has it.** The fixes below require organizational change, not technical work.

## Read the alignment

Conway's Law works both directions. Observe the code, and you can infer the organization. Use that to understand where the org is healthy and where it is broken.

Healthy alignment looks like:

* Modules owned by single teams.
* Rare cross-team edits to the same file.
* PRs approved quickly because the owner is always available.
* New features shipping without coordination meetings.

Broken alignment looks like:

* Modules touched by many teams.
* Frequent merge conflicts on core files.
* PRs waiting days for review from another team.
* Shipping a feature requiring meetings with three teams.

## Pick the right organizational change

When you see broken alignment, the org needs restructuring, not a technical fix. A new testing framework, refactoring pass, or architecture diagram will fail to fix communication problems.

Walk this decision in order:

1. **Name the misalignment shape.** Pick the dominant symptom: chronic co-editing of one file (co-editing), one team owning unrelated modules (overload), several teams depending on shared infra (platform gap), or a module owned by a team that does not know the domain (mismatch).
2. **Match symptom to fix.** Co-editing means *merge* the two teams. Overload means *split* the stretched team along domain lines. Platform gap means *carve out* a platform team. Mismatch means *move* the module to the team with the domain knowledge.
3. **Check for multiple symptoms.** If two shapes apply, fix the one with the higher cost first. Cost is hours wasted per quarter, measured the same way as in the troubleshooting section below.
4. **Confirm leadership buy-in.** No organizational change holds without leadership willingness to defend the new boundaries. If leadership cannot commit, the reorg will revert within two quarters.
5. **Announce the change with the reason.** People absorb reorganizations better when they understand which friction the change targets. Cite the specific module, the specific friction count, and the expected outcome.

## Verify

Track these changes. After three months, check whether the code graph has simplified. If not, the organizational change was cosmetic. Teams are still coordinating the old way.

You'll know it worked when the commit graph visibly thins over a quarter: fewer teams touching the same files, fewer modules with overlapping ownership.

## Troubleshooting

### The commit graph still shows congestion three months after the reorg

The organizational change was cosmetic. Look for who is still meeting whom. If two teams that "split" still attend each other's standups and review each other's PRs, the split exists on paper only. Commit to harder boundaries (different reporting lines, different priorities, different planning cycles) or merge the teams back and pick a different lever.

### 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.

### 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 for the reorganization writes itself.

## Where to go next

* Read [How Do I Diagnose Delivery Friction?][diagnose] for the commit-pattern analysis that surfaces broken alignment.
* Read [How Do I Pitch Org Design for Better Architecture?][pitch] for talking points when leadership pushes back.
* Review [Team Topologies][team-topologies] for team-structure patterns and the four fundamental team types.

## 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 surfacing misalignment.
* [How Do I Pitch Org Design for Better Architecture?][pitch], the companion guide for advocating 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/
[pitch]: https://jeffbailey.us/blog/2026/05/13/how-do-i-pitch-org-design-for-better-architecture/
[team-topologies]: https://teamtopologies.com/book