## 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 the deployed system.** You need to see the service list, runbooks, and on-call rotations.
* **Visibility into pipelines and release boundaries.** You need to know which services ship together and which ship separately.
* **A blank document or whiteboard.** You will sketch a map as you go.

## Walk the deployment

Treat deployed software like a fossil record. Every service boundary, API contract, and deployment pipeline carries the imprint of the people who shipped it. Walk the deployment in this order:

1. **Inventory the services.** List every deployable artifact (service, function, scheduled job). For each, note who is on-call and who owns the runbook section. A row might look like: `auth-service | on-call: identity team | runbook: identity/auth.md | last edited: 2026-03`. Gaps here are gaps in ownership, and they become outages during incidents because nobody is paged.
2. **Read the API contracts.** Tag each cross-service connection by style: shared library, REST or gRPC with versioning, direct database access, or shared message queue. Trust between teams predicts the style. Shared libraries mean the teams talk; versioned contracts mean they negotiate; direct database access means they bypass each other.
3. **Sketch the release boundaries.** Group services by which pipeline ships them, which on-call rotation pages for them, and which release cadence they follow. A whiteboard, a Miro board, or a Mermaid diagram all work; pick whichever you can share. Each cluster is the footprint of one team or one tightly coordinated group.
4. **Ask why each boundary exists.** For every service split, write one sentence about the organizational reason. Common patterns: "security was its own team," "mobile shipped on a different cadence," "the data team owned ETL but not the consumer." The architecture answered a question; the question was usually organizational.
5. **Predict change cost.** For any proposed consolidation or split, check whether the two teams already work well together. If they do not, the change will fight Conway's Law for months. If they do, the change will feel obvious. The deployed shape predicts the cost of changing it.

## Synthesize the four signals

The four observations above feed a single prediction: will a proposed change land cleanly or fight the org? The flow:

```mermaid
flowchart TB
    A["Service inventory<br/>who owns what, who is on-call"]
    B["API contract style<br/>shared libs, versioned, direct DB"]
    C["Release boundaries<br/>pipelines, on-call, cadence"]
    D["Runbook ownership<br/>who wrote each section"]
    E["Predicted change cost<br/>clean landing or org fight?"]
    A -->|reveals ownership gaps| E
    B -->|reveals trust between teams| E
    C -->|reveals coordination footprint| E
    D -->|reveals operational ownership| E
```

A consolidation across two clusters that share contract style, overlapping on-call, and joint pipeline ownership will land cleanly. A consolidation across clusters with versioned contracts, separate on-call, and divergent cadence will fight you for months.

## Verify

You'll know it worked when you can predict, before the planning meeting starts, whether a proposed merge or split will land cleanly or stall against the org for months.

## Troubleshooting

### Runbooks are missing for several services

Those services have no clear owner. During the next incident, nobody will be paged for them. Fix the runbook gap before the incident finds it. The lack of a runbook is itself a Conway's Law signal: nobody on any team thinks of those services as theirs.

### The service map has services with no team

Either the team was reorganized away and the services were orphaned, or the service was built by a contractor or rotated owner. Both cases are technical debt that masquerades as deployment shape. Assign them or sunset them.

### Conway's Law does not seem to apply

A few cases resist the law's predictions:

* External constraints forcing architecture (regulated industries, compliance audits, contractual integrations).
* Strong shared tooling that flattens boundaries (a monorepo with one pipeline shipping everything).
* Services inherited from acquisitions, where the original org no longer exists.

Confirm one of these applies before concluding the law is wrong.

## Where to go next

* Read [How Do I Pitch Org Design for Better Architecture?][pitch] to turn the deployment map into a conversation with leadership.
* Read [How Do I Serve Organizational Needs With Conway's Law?][serve] to pick the organizational change the deployment shape implies.
* Review [Team Topologies][team-topologies] for team-structure patterns that match common deployment shapes.

## References

* [What Is Conway's Law?][conways-law], the explanation article defining the pattern.
* [How Do I Pitch Org Design for Better Architecture?][pitch], the companion guide for advocating change based on what you found.
* [How Do I Serve Organizational Needs With Conway's Law?][serve], the companion guide for picking the right reorganization.
* [Team Topologies][team-topologies], Matthew Skelton and Manuel Pais on team-structure patterns.

[conways-law]: https://jeffbailey.us/what-is-conways-law/
[pitch]: https://jeffbailey.us/blog/2026/05/13/how-do-i-pitch-org-design-for-better-architecture/
[serve]: https://jeffbailey.us/blog/2026/05/13/how-do-i-serve-organizational-needs/
[team-topologies]: https://teamtopologies.com/book