Description
A product manager asks for a feature. It touches payments, inventory, notifications and the core interface, so four teams have to coordinate and there are three handoffs. Before assistance this took six weeks: two of work and four of waiting. Everyone called that normal. Then each team's developers started producing twice as much, the manager expected three weeks, and it took eight. The parts got faster. The seams did not, and there was more to push through them.
Conway observed the underlying mechanism in 1968, and it has been tested since rather than merely repeated. Comparing matched commercial and open source products, loosely coupled organisations were found to produce markedly more modular software. Studying a large commercial system, organisational structure predicted where the defects would land more accurately than any code metric. Structure does not influence the architecture. It produces it. Generated code is then produced inside that architecture, which bounds how good it can be.
Conway is also widely misread. He described a problem to be solved and closed by calling for organisations to stay flexible enough to change shape. Treated instead as an unavoidable law, it becomes a reason to freeze teams against a fixed architecture, and under acceleration that is the expensive interpretation: the boundaries harden exactly when the volume of change most needs them to move.
The practical consequence is about where work waits. Fixed ownership means every change crossing a boundary queues behind the one team allowed to make it, and doubling what each team produces makes that queue grow rather than shrink. Ownership shared widely enough that anyone who understands the domain can review distributes the same load instead of concentrating it. That is what this dimension scores: not whether your org chart is fashionable, but whether anything watches the seams and whether the boundaries are allowed to move when it does.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nobody knows where the work waits. There is no count of how many teams a change needs, no measure of how long it sits between them, and the org chart is treated as a fact rather than as a design someone made. The waiting is real, and the only place it is ever visible is an estimate that was always going to be wrong.
The tellTake the last feature that crossed team boundaries and read its ticket history. Count the teams it passed through, then the days it sat still between them. If the history cannot give you the second number, you are here.
- 2
Tacit
Work crosses boundaries because particular people make it cross. A few long-serving engineers and managers know exactly who to ask, and a real part of their week goes on doing it. This works up to the volume those people can personally carry, and none of it is written anywhere the next person could read.
The tellName who gets things across your team boundaries. If everybody names the same one or two people, and neither of them holds a role that says so, the structure is living in them rather than in the organisation.
- 3
Visible but inert
Lead time, handoff counts and queue depth are computed and shown. Somebody presents them each quarter. Nothing moves as a result: the boundaries stay exactly where the last reorganisation put them, so the numbers record how much work is waiting instead of causing any of it to stop waiting.
The tellOpen your flow dashboard, then ask when a team boundary last moved because of something on it. If the last boundary change came out of a reorganisation instead, the number is decoration.
- 4
Acted on
Handoff and queue metrics are tracked on a cadence, and breaching the target triggers a topology review without waiting for anyone to notice. The structure is treated as something that can be wrong and corrected, and reviewing it is scheduled work rather than the response to a delivery crisis.
The tellFind the last time a queue between two teams breached its target. Something put a structural review on the calendar on its own, and it happened because the number crossed a line, not because a senior person happened to be looking that week.
- 5
Durable
Boundaries move when the architecture moves. Ownership is shared widely enough that a change can be reviewed by anyone who understands the domain, teams see the customer problem as well as the delivery of it, and none of that depends on the particular people who arranged it.
The tellLook at what happened the last time the architecture changed shape. If team boundaries moved with it, without waiting for an annual reorganisation, the flexibility is in the organisation rather than in someone's goodwill.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
MacCormack, Baldwin and Rusnak, Exploring the Duality between Product and Organizational Architectures (Research Policy, 2012)
Compared matched pairs of commercial and open source products and found that loosely coupled organisations produce markedly more modular software. Structure does not merely influence the architecture, it produces it.
Nagappan, Murphy and Basili, The Influence of Organizational Structure on Software Quality (ICSE 2008)
Studied a large commercial operating system release and found that organisational structure predicted where the defects would land more accurately than any code metric tested, including churn, complexity and coverage.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Organizational design →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.