Quick Navigation
- Start here — the law you are already obeying
- The org chart is a hypothesis
- Where the real boundaries show up
- Four signals that expose the boundary you actually have
- The two-layer map
- Redrawing a boundary on purpose
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Most leaders treat delivery friction as a people problem. The wrong engineers. Not enough of them. Low motivation. They hire, they reorganise, and six months later the same friction is back in a different shape.
Your teams will build a system that looks like your organisation. That is not a metaphor — it is a law. If you want a different architecture, you need a different team structure first.
That single idea moves delivery friction out of the performance category and into the design category. And design problems have solutions.
Keep it in mind.
1. Start here — the law you are already obeying
Conway's Law states it plainly: "Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations."
Read that again with the word constrained in mind. It is not advice. It is not a design pattern you can adopt. It is a description of what will happen regardless of what your architecture diagram says.
This is what it sounds like when the law is working against you:
- "That change needs three teams in a room."
- "We can't release until the other team's release goes out."
- "Every feature turns into an integration meeting."
- "The architecture says independent services, but nothing ships independently."
Consider organisations that spend a year trying to build independent microservices with teams that still share a database, a release process, and a weekly coordination meeting. The architecture said independent. The org structure said otherwise. The architecture lost. It always loses, because the architecture is downstream of the communication structure that produces it.
flowchart LR
ORG["🏢 Communication\nStructure"] -->|"constrains"| ARCH["🏗️ System\nArchitecture"]
ARCH -->|"generates"| WORK["📋 Coordination\nWork"]
WORK -->|"reinforces"| ORG
Notice the loop. The structure produces an architecture, the architecture produces coordination work, and that work hardens the structure that created it.
Try it yourself — The Conway's Law check
Draw your current team structure. Now draw your system architecture. Hold them side by side.
| Question | Your answer |
|---|---|
| Do the boundaries match, one team to one bounded piece of the system? | |
| Are your teams organised by technical layer — frontend, backend, data? | |
| How many services can be changed and released by exactly one team? | |
| Which architecture boundary has no team standing behind it? |
If your architecture has five services but your teams are organised by technical layer, your teams are producing integration meetings, not independent deployments. That gap is the whole subject of this module.
2. The org chart is a hypothesis — Team boundaries are the architectural decision
Every org chart is a hypothesis. It says: if we assign these people to these domains, ownership will work this way.
The hypothesis was reasonable when it was formed. Teams were smaller. Systems were newer. The failure modes were unknown. Six months later the systems have grown, teams have shifted, informal dependencies have calcified into operational necessity — and the hypothesis, never tested and never updated, has drifted away from operational truth.
Here is what follows from that. If team structure constrains architecture, then drawing a team boundary is an architectural act. It is not an HR exercise that happens to precede the technical work. It is the first and most consequential technical decision, made by people who often do not think of themselves as making one.
Which means a boundary deserves the same scrutiny you would give a service contract:
- What does this team own end to end? Not "contributes to" — owns.
- What can it change and release without asking anyone?
- What does it depend on that it does not control?
- If it changed tomorrow, what else would have to change with it?
Every unanswered question there becomes a coordination meeting later. Every recurring cross-team meeting that exists because two teams need to agree on something that should have been one team's decision alone is a tax on delivery speed — and a receipt for a boundary that was never properly drawn.
Team boundaries are not an input to architecture. They are architecture.
Try it yourself — The coordination cost audit
Count the recurring cross-team meetings your engineering organisation runs every week. For each one, answer:
| Meeting | What decision is it coordinating? | Should that decision belong to one team? |
|---|---|---|
Every meeting that exists to compensate for a structural gap is a standing charge on your delivery capacity. Write down the total hours per week. That number is what the current boundary design costs you.
3. Where the real boundaries show up — Read the log, not the chart
So the org chart is a hypothesis. What tests it?
On-call and incident data. Because on-call data does not drift.
Every incident is a data point. Every escalation is a signal. Every paged engineer is a vote on where load actually concentrates — regardless of what the org chart intended.
When an incident fires and an engineer gets paged, four things are recorded at once: where the load actually lands, who is trusted to resolve it, which team boundaries are being crossed to get it resolved, and which senior engineer holds it all together when everything else fails.
None of those appear in a headcount spreadsheet. None appear in a team charter. None survive an annual performance review. All of them are in the on-call log.
The org chart shows the organisation you designed. The on-call log shows the one you are running. Most engineering leaders redesign from the first document. Almost none redesign from the second.
Incident Ownership Architecture (IOA) is the structured method for reading that data as an org design signal. Its purpose is not to improve incident response. Its purpose is to surface the gap between the organisation that was designed and the organisation that is actually operating.
4. Four signals that expose the boundary you actually have
IOA maps four signal types. Each is a structural condition that on-call data will expose — if someone is looking for it.
Load Concentration. One engineer or one team consistently absorbs incidents spanning far beyond their documented ownership. The on-call schedule says they cover one domain; the incident log shows they resolve across three. This is not a capability problem. It is a place where the design created ownership on paper without building the redundancy or authority to sustain it. Load Concentration looks like a reliable team. It is a single point of structural failure.
Silent Dependency. A team is consistently paged for a system it does not officially own. Ownership is documented elsewhere, but the documented owner either cannot resolve incidents or does not respond fast enough, so another team absorbs the load — silently, without recognition, without authority. It does not appear in the RACI. It does not appear in the architecture diagram. Silent Dependencies are the informal contracts that keep engineering organisations running, and the structural crises that follow key departures.
Ownership Drift. Incidents are consistently resolved by someone other than the documented owner — not because that owner is absent, but because the operational reality of the system has moved away from an ownership model defined when the system was smaller. The team that owns the service on the diagram has not owned its production behaviour for months. Drift generates confusion in postmortems, because two teams hold different mental models of who is responsible, and risk at every restructure, because the chart does not show who actually holds the system.
Escalation Fossil. Every critical incident, whatever the domain, traces back to the same person. They are not the on-call engineer. They are not the service owner. They are the person called when everything else has stalled. The term is precise: the fossil is the remains of a structural decision that was never made — the decision to build the knowledge, authority and redundancy that would have made this person's informal role unnecessary. When an Escalation Fossil leaves, the organisation does not lose a team member. It loses a load-bearing element the design was never brave enough to name.
flowchart TD
LOG["📟 On-Call &\nIncident Data"] --> S1["Load Concentration\nOne team absorbing\nbeyond its ownership"]
LOG --> S2["Silent Dependency\nPaged for systems\nit does not own"]
LOG --> S3["Ownership Drift\nResolved by someone\nother than the owner"]
LOG --> S4["Escalation Fossil\nOne person is the\nlast resort everywhere"]
S1 --> FIND["🔎 Structural Findings\nThe boundary you\nactually have"]
S2 --> FIND
S3 --> FIND
S4 --> FIND
Try it yourself — The three questions
Answer these about your own organisation before reading on:
| Question | Your answer |
|---|---|
| In your last five severity-1 incidents — was the resolution owner the same as the documented service owner? | |
| Can you name every engineer whose informal escalation load is greater than their documented responsibility? | |
| If your most frequently paged engineer left tomorrow, how many systems would lose their informal load-bearing support? |
If these answers are unclear, your incident load map has never been read structurally — which means your boundaries have never been tested.
5. The two-layer map — Designed against running
The output of this reading is a two-layer view of the same organisation.
Top layer: the official org design. Documented owners, team charters, defined escalation paths, architecture diagrams.
Bottom layer: the incident load map. Who was paged, how often, for what system, what resolution path was actually taken, which names appear across multiple domains.
| Official Org Layer | Incident Load Layer |
|---|---|
| Team A owns Service X | Team B resolved 68% of Service X incidents in Q1 |
| Platform team is a shared service | One senior engineer resolved all P1 platform incidents |
| Service Y has a defined escalation path | Service Y's escalation path was bypassed in 9 of 11 incidents |
| Domain B has 4 engineers | Domain B's on-call burden equals 6 FTE of incident load |
| Three teams own the data layer | One person is paged for the data layer regardless of which team's system triggered the alert |
The gap between the two layers is not a performance issue. It is an org design issue. Every row where the official and actual pictures diverge is a structural finding.
Building this map is a data-access exercise more than a process change. Pull 90 days of on-call and incident data, recording for each incident the service that triggered the alert, the documented owner, the first responder, the resolution owner, the escalation path, and time to resolution. Then compare it team by team against the current design: documented load against actual load, systems resolved without documented ownership, and the names appearing as informal escalation points across domains.
Do not redesign yet. Understand what you are actually running before changing how it is structured.
6. Redrawing a boundary on purpose
Findings become decisions when each one gets a disposition. There are three.
Redesign now. Load Concentration and Ownership Drift cases where the gap can be closed within 30 days through explicit ownership reassignment, role formalisation, or team boundary adjustment.
Succession plan. Escalation Fossils and Silent Dependencies where the structural fix needs longer preparation — knowledge externalisation, cross-training, deliberate redundancy building. Assign a named owner and a 90-day timeline.
Accept and document. Gaps that are known, understood and consciously carried as temporary conditions. Document them explicitly, with a named risk owner and a review date.
What you are aiming at is a topology where the boundaries match the system you are trying to build: stream-aligned teams that own a flow of change end to end, a platform capability with a written charter for what it exists to do and what it does not, enabling teams, and complicated-subsystem teams where the domain genuinely requires them. How those teams then talk to each other — and how much any one of them can sustainably hold — is the subject of Cognitive Load & Team Interfaces. Who inside those boundaries is allowed to decide what is the subject of Decision Rights & Delegation.
Consider what happens when a boundary is redrawn from evidence rather than intent. In one telecommunications organisation, the org chart showed a platform team responsible for infrastructure. The on-call log showed the payments team handling infrastructure incidents — because the platform team's systems were unreliable and the payments team could not afford to wait. Six months of logs were mapped to actual resolvers. The map revealed three teams performing work the chart assigned elsewhere; the architecture had been silently reorganised by necessity. Boundaries were realigned to match the on-call reality, ownership changes were formalised, and incident resolution time dropped by half.
Structural decisions made without incident load evidence are hypotheses. Structural decisions made with it are interventions.
Putting it all together
flowchart TD
CHART["📄 Org Chart\nThe organisation\nyou designed"] --> GAP["Structural Gap"]
LOG["📟 On-Call Log\nThe organisation\nyou are running"] --> GAP
GAP --> D1["Redesign now\nClose within 30 days"]
GAP --> D2["Succession plan\nBuild redundancy, 90 days"]
GAP --> D3["Accept and document\nNamed risk owner, review date"]
D1 --> NEW["🏗️ Boundaries that match\nthe system being built"]
D2 --> NEW
D3 --> NEW
The foundation:
Conway's Law is a constraint, not a preference — your architecture will copy your communication structure whether or not anyone intended it. The org chart is a hypothesis about ownership, and it drifts. The on-call log is the test, because incident data records where load actually falls. The four signals — Load Concentration, Silent Dependency, Ownership Drift, Escalation Fossil — turn that data into named structural findings. And every finding gets a disposition, so a boundary is redrawn against evidence rather than against a job description.
Cheat Sheet — All the key terms
| Term | What it names | Where you see it |
|---|---|---|
| Conway's Law | Systems copy the communication structures that build them | Integration meetings where independent deployments should be |
| Org chart as hypothesis | An untested assumption about how ownership will work | Any structure that has not been checked against operational data |
| Load Concentration | One team absorbing incidents beyond its documented ownership | A "reliable" team that is a single point of failure |
| Silent Dependency | A team paged for a system it does not own | The informal contract that keeps delivery running |
| Ownership Drift | Actual resolver differs from documented owner | Postmortems where two teams disagree on responsibility |
| Escalation Fossil | One person is the last resort across domains | The name in seven of the last ten severity-1 incidents |
| Two-layer map | Official design set against incident load | The evidence base for any restructure |
How to know if this landed
You will know this has landed when someone proposes a new feature and the first question is "which team owns this end to end?" — and there is an answer. When a team can release independently because nothing inside its boundary requires coordination with another team's release cycle. When no restructure is proposed without the incident load picture being pulled first. And when the org chart and the architecture diagram finally look like they were designed by the same people.
What changes when the mental model clicks
Engineering leaders often arrive convinced their delivery problems come down to technical debt, bad tooling, or underperforming engineers. The moment they see their org structure mapped against their system architecture — and see exactly where the coordination overhead is being generated — the conversation changes completely.
Leaders stop reorganising in response to delivery pain and start designing team structure as a first-class architectural decision. They stop treating cross-team dependencies as inevitable and start treating them as design failures to be eliminated. Planning gets more honest. Commitments get more reliable. And "poor communication" stops being the diagnosis when the real problem was that the structure forced communication to compensate for boundaries nobody ever drew.
Where this comes from
This module develops the argument in Your On-Call Log Is Your Real Org Chart, and runs alongside the Team Topologies & Organisational Design Workshop.
Book a Workshop
Ready to redraw your team boundaries from operational evidence rather than intent?
or
1-day intensive workshop includes topology diagnosis, Conway's Law mapping, incident load analysis, two-layer org mapping, and a phased transition plan from current structure to target topology.