Conway's Law and Organizational Debt
Some technical debt was never written by an engineer. It was created by a reporting line. When the shape of your teams and the shape of your system disagree, the teams win -- every time, in every organization, since at least 1968.
This page covers Conway's Law as actually written, the inverse maneuver, Team Topologies and cognitive load, the debt a reorganization leaves behind, ownership and bus factor, ramp time as a complexity readout, and the SPACE framework as the complement to DORA.
Conway's Law, As Actually Written in 1968
Melvin E. Conway published "How Do Committees Invent?" in Datamation in April 1968. It is worth reading the thesis in the author's own words rather than in the paraphrase that circulates on slide decks, because the paraphrase softens it into a metaphor and the original is a claim about constraint.
"organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations"
Source: Melvin E. Conway, Datamation (F. D. Thompson Publications), "How Do Committees Invent?", 1968.
Note the word constrained. Conway is not saying organizations tend to do this, or often do this under stress. He is arguing that they cannot do otherwise, and he supports it with a structural argument rather than an anecdote: he observes that the graph of a system's design maps onto the graph of the organization that designed it, and names the relationship a homomorphism. The design is a structure-preserving image of the communication structure. Fred Brooks cited the paper in The Mythical Man-Month and called it Conway's Law, and the name stuck.
The mechanism sentence is the one that matters for technical debt:
"To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces."
Source: Melvin E. Conway, Datamation (F. D. Thompson Publications), "How Do Committees Invent?", 1968.
Conway also observed that the larger the organization, the less flexible it is, and the more pronounced the effect. That is a prediction, and it is testable. It predicts that a system built by three teams will have three major parts with interfaces at the team boundaries. It predicts that two teams who sit together and talk daily will produce tightly coupled code, and two teams in different time zones with a ticket queue between them will produce a hardened, over-formalized interface whether or not that interface makes technical sense. It predicts that a component owned by nobody will end up with the structure of the last committee that touched it.
And it predicts something uncomfortable about remediation. If the architecture is an image of the organization, then a refactor that does not change the organization will be undone. The structure will grow back, because the same communication paths are still producing the same design pressure every day.
Why the Architecture Diagram Always Loses to the Org Chart
Every organization has two architectures: the one on the wiki and the one implied by who talks to whom. When they disagree, the second one wins. Here is the day-by-day mechanism that makes it win.
Cross-Boundary Changes Cost More Than In-Boundary Changes
Changing code your team owns takes a pull request. Changing code another team owns takes a conversation, a ticket in their backlog, a prioritization argument, a wait, and a review by someone with different context. That difference is not small, and it is paid on every single change. Engineers are rational: given a choice between the correct change on the other side of the boundary and a workable change on their own side, they take the one they can ship today. Nobody decides to create architectural debt. They decide, forty times, to avoid a two-week negotiation.
The Symptoms Are Recognizable
Duplicated business logic that exists once per team rather than once per concept. A "shim" or "adapter" service whose only real purpose is to avoid asking another team to change something. Two systems writing to the same database table because the teams could not agree on an API contract. An integration layer that is not a technical design at all but a diplomatic one. A module whose interface is unusually formal and unusually stable, because it sits on an organizational fault line where negotiation is expensive.
The Overlay Test
Print the architecture diagram. Print the org chart. Colour each box in the architecture by the team that owns it. Three findings show up almost immediately: components with two or more colours, which are the coupling points that generate the most cross-team argument; components with no colour, which are orphans and covered further down this page; and clusters of same-coloured components with no clean seam between them, which is where the organization has been quietly merging things it should have kept apart. This exercise takes an hour and produces a better architectural review than most quarterly planning cycles.
Why the Refactor Grows Back
A team spends a quarter decomposing a monolith into four clean services. Eighteen months later there are four services that cannot be deployed independently and share a database. Nothing went wrong technically. The organization never changed, so the same communication structure kept stamping out the same design, one pragmatic shortcut at a time. Any architectural remediation plan that does not include a corresponding change to team boundaries is a plan with a known expiry date. Record that reasoning in an architecture decision record so the next team understands why the seam is where it is.
The Inverse Conway Maneuver
If organizations are constrained to produce designs that copy their communication structures, the constraint runs in a usable direction. Decide the architecture you want, then build the communication structure whose image is that architecture. This is the inverse Conway maneuver, and Conway himself supplied the management corollary that justifies it: because the first design is almost never the best possible, the system concept will need to change, and therefore flexibility of organization is important to effective design.
Doing It Well
- Draw the target architecture first, at the level of independently deployable pieces.
- Assign each piece exactly one owning team, with no piece owned by two and no team owning more than it can hold in its head.
- Move the code and the on-call rotation at the same time as the people. Ownership that exists only in a spreadsheet is not ownership.
- Give each boundary a real interface contract before you move anybody, so the first cross-team change is not also the first API design.
- Expect a productivity dip for a quarter and say so in advance, so the dip is not read as evidence the change failed.
How It Goes Wrong
- The teams are reshaped and the code is not, so you now carry both the old mismatch and a new one.
- Boundaries are drawn on the org chart's convenience rather than on the domain, producing services that must always change together.
- The maneuver is used as post-hoc justification for a reorg that was already decided for headcount reasons.
- Teams are split faster than interfaces can be defined, so the first six months are spent inventing contracts under delivery pressure.
- Nobody owns the seams. The pieces get owners; the integration between them does not.
Team Topologies: Four Team Types, Three Interaction Modes
Matthew Skelton and Manuel Pais published Team Topologies: Organizing Business and Technology Teams for Fast Flow with IT Revolution Press in 2019. Its value here is that it gives you a small, finite vocabulary for team shape, which is exactly what you need to argue about organizational debt without it turning into a personality discussion.
Stream-Aligned
Aligned to a flow of work from a segment of the business domain. This is the default team type and every other type exists to make these teams faster. The debt signal here is a stream-aligned team that cannot ship without waiting on someone else: that is a boundary in the wrong place, not a motivation problem.
Platform
A grouping of other team types providing a compelling internal product that accelerates delivery by stream-aligned teams. The word "compelling" is load-bearing. A platform teams are forced to use is a tax; a platform they choose to use is leverage. Mandated adoption is how platform work turns into platform debt.
Enabling
Helps a stream-aligned team overcome obstacles, and detects missing capabilities. Enabling teams are the correct answer to a class of debt that is really a skills gap. The failure mode is an enabling team that never leaves, at which point it has become a permanent dependency rather than a temporary one.
Complicated Subsystem
Where significant mathematics, calculation, or technical expertise is needed. Used correctly it isolates genuine specialist complexity. Used as an excuse it becomes a permanent knowledge silo with a bus factor of one, which is ownership debt wearing a respectable label.
Source: Matthew Skelton and Manuel Pais (Team Topologies, IT Revolution Press), "Team Topologies Key Concepts" -- "Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain".
Only Three Ways Teams Should Interact
The interaction modes matter more than the team types for debt purposes, because an undefined interaction is where coordination cost hides. Team Topologies allows exactly three, and the discipline of naming which one applies is most of the value.
Collaboration
Working together for a defined period to discover new things. High bandwidth, high cost, and deliberately temporary. A collaboration with no end date has become an undocumented merger of two teams.
X-as-a-Service
One team provides, one consumes, through a clear interface. Low bandwidth by design. If consumers routinely need a conversation to use the service, the interface is the debt.
Facilitation
One team helps and mentors another. The intended output is that the helped team no longer needs help. Measure it by whether the facilitation ends.
Cognitive Load Is a Debt Quantity
Skelton and Pais frame team capacity in terms of cognitive load, which the psychologist John Sweller characterized in 1988 as the total amount of mental effort being used in working memory. They use Sweller's three categories, and the distinction between them is what turns a vague complaint into a debt argument.
Source: Matthew Skelton and Manuel Pais, IT Revolution, "Team Cognitive Load" -- "the total amount of mental effort being used in the working memory".
Intrinsic
Aspects of the task fundamental to the problem space. Knowing the language, knowing the domain. Reduce it with training and hiring, not with tooling. This is the load you want your team spending its capacity on.
Extraneous
Aspects relating to the environment the task is done in. How do I deploy this? Which of the four config systems applies? Why does the local build need that undocumented environment variable? This is where technical debt lives, and every unit of it displaces a unit of intrinsic capacity.
Germane
Aspects needing special attention for learning or high performance. The valuable thinking. It is the first thing to disappear when extraneous load rises, which is why a team drowning in operational overhead stops producing good design work long before it stops producing code.
This gives you a way to say something precise instead of "the team is overloaded". Extraneous cognitive load is technical debt measured in human attention, and unlike most debt measures it is legible to a non-engineer. Nobody outside engineering understands cyclomatic complexity; everybody understands "our people spend a third of their thinking capacity remembering how to deploy."
Three Cheap Ways to Estimate It
- Count the surface. How many repositories, deployable services, runtimes, datastores, and third-party integrations does this team own? Not weighted, just counted. Teams that own more than a handful of genuinely distinct things are carrying load nobody budgeted for.
- The whiteboard test. Ask three members of the team, separately, to draw the system they own. If the drawings disagree materially, the system exceeds the team's shared working memory. That is the definition of the problem, drawn on a whiteboard.
- Ask directly, on a scale. A recurring one-question survey -- "how much of your effort this week went to fighting the environment rather than solving the problem?" -- trends usefully even though the absolute number means nothing. Pair it with the team health signals in our team health guide.
Reorg Debt: What a Reorganization Leaves in the Codebase
A reorganization moves people. It does not move code, on-call rotations, CODEOWNERS files, runbooks, dashboards, alert routes, or the informal knowledge of who to ask. Every one of those is a mapping from the old org chart to the system, and after a reorg every one of them is stale. That gap is reorg debt, and it is created on a specific date by a specific decision, which makes it unusually easy to detect if you look within the first quarter.
The damage compounds quietly. A service that formally belongs to a team nobody told still gets deployed, still gets vulnerabilities, and still pages someone at 3am -- but it is no longer on any team's roadmap, so it receives maintenance only when it fails. Two years and two more reorgs later it is the system everyone is afraid of.
| Signal | How to detect it | What it means |
|---|---|---|
| Commit drift | For each repository, list committers in the last 90 days and compare against the team that formally owns it | Zero overlap means the owner is fictional; partial overlap means ownership has silently migrated |
| Review latency | Median time from pull request opened to first review, per repository, before and after the reorg date | A step change means the required reviewers moved and the CODEOWNERS file did not |
| On-call ambiguity | Count incidents reassigned at least once before someone accepted them | Reassignment rate is the single most honest ownership metric you have, because it is measured under pressure |
| Orphaned repositories | Repositories deployed to production with no commit, no dependency update, and no open issue in six months | Running, load-bearing, and unmaintained. This is where the next supply-chain incident starts |
| Documentation rot | Grep runbooks and wiki pages for team names, distribution lists, and channels that no longer exist | Every hit is an instruction that will fail during an incident, when it is least affordable |
How to Repay It
- Run an ownership census within 30 days of any reorg. Every production artifact gets a named owning team and a named human. Not a manager, not a group alias -- a person who will answer.
- Publish the unclaimed list. Anything with no owner after the census goes on a visible list with a decision date: adopt it, archive it, or decommission it. Unclaimed and unlisted is the state that kills you.
- Make ownership machine-checkable. A service catalogue entry, a CODEOWNERS file, and an alert route that all agree, verified in CI. Ownership recorded only in a slide deck decays by the next reorg.
- Budget the handover. A real transfer is a few weeks of shadowing, a walkthrough of the last three incidents, and a documented failure mode list. A calendar invite titled "handover" is not a transfer.
- Treat the census as recurring. Reorgs are not rare events. Run it quarterly and the debt never accumulates past one quarter's worth.
Ownership Debt: Bus Factor and the Only Expert
Ownership debt is the gap between the knowledge a system requires and the number of people who hold it. It has a well-studied proxy, and the published numbers are not reassuring.
The truck factor, sometimes called bus factor, is the minimum number of developers who would have to leave before a project is incapacitated. Avelino, Passos, Hora, and Valente built an estimator for it and applied it to a corpus of 133 popular GitHub projects. They found that the majority of those systems -- 65 percent -- had a truck factor of two or less.
Source: Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente; 24th International Conference on Program Comprehension (ICPC 2016), arXiv:1604.06766, "A Novel Approach for Estimating Truck Factors" -- "Among others, we find that the majority of our target systems (65%) have TF <= 2."
That was a 2016 study of open-source projects, not a claim about your company. But it is a useful calibration: concentration of knowledge is the normal state, not an aberration, and if you have never measured yours you should assume it is worse than you think.
Symptoms
- One name appears on every pull request touching a module, as author or as sole reviewer.
- A service whose entire commit history has one or two authors.
- Answers that exist only in direct messages and never make it into a document.
- Estimates that change by a factor of three depending on who is available.
- A person who cannot take two consecutive weeks of leave without a release being rescheduled.
Repayment
- Require a second author, not a second reviewer, on any system with a truck factor of one. Reviewing teaches far less than writing.
- Rotate the on-call for a system before you need to, while the expert is still there to answer questions.
- Capture decisions, not descriptions. An ADR explaining why survives longer than a wiki page explaining what.
- Run a deliberate absence drill: the expert stays silent for one week while someone else handles the system, and every question they could not answer becomes a documentation task.
- Make knowledge sharing a standing practice rather than a heroic act, as covered in training and culture.
Hiring and Onboarding Debt: Ramp Time Is a Direct Readout
Every new engineer is an unbiased instrument. They have no context, no scar tissue, and no habit of routing around the broken parts. However long it takes them to become productive is a measurement of exactly how much accumulated complexity stands between a competent person and a working change. Nothing else you can measure is as honest, and nothing else is as easy to explain to someone outside engineering.
Time to first commit
Measures environment setup debt specifically. If it takes more than a day, the problem is the local development experience: undocumented dependencies, manual steps, credentials nobody can grant.
Time to first production change
Measures the whole delivery pipeline plus the confidence the tests give. Long ramp here means the system cannot be changed safely by someone who does not already know its history.
Time to first on-call shift
Measures observability and runbook quality. If new engineers cannot be trusted on the rotation for six months, the system is only operable by memory, which is ownership debt with a pager attached.
Instrument all three per hire and chart the trend across hires rather than obsessing over any individual. A rising trend is compounding debt, visible months before it shows up in delivery metrics. A falling trend is the cleanest evidence you will ever get that a platform investment worked.
Two practices keep the measurement honest. First, make the most recent hire the owner of the onboarding documentation, because they are the only person who can still see what is missing -- and hand it to the next hire when they arrive. Second, interview leavers about what took them longest to learn. The gap between what onboarding covers and what people actually needed is a precise, free list of undocumented complexity.
The SPACE Framework: What DORA Alone Cannot See
DORA's software delivery metrics are the standard instrument for pipeline health, and DORA's current guidance names five of them rather than the historical four keys. They are excellent at what they do. What they do is measure the pipeline -- and organizational debt is not primarily a pipeline problem. A team can hold change lead time and deployment frequency steady for a year while its cognitive load doubles, its truck factor falls to one, and two of its senior engineers quietly start interviewing. Delivery metrics stay green right up until the day the people leave.
Source: DORA (Google Cloud), "DORA's software delivery performance metrics" -- "DORA has identified five software delivery performance metrics that provide an effective way of measuring the outcomes of the software delivery process."
SPACE is the complement. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler published it in ACM Queue in 2021, and its central argument is that developer productivity is multidimensional and cannot be captured by any single metric.
Source: Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler; ACM Queue vol. 19 no. 1, pp. 20-48, "The SPACE of Developer Productivity: There's more to it than you think", 2021.
| SPACE dimension | What organizational debt does to it | A signal you can actually collect |
|---|---|---|
| Satisfaction and well-being | Fighting the environment instead of the problem is corrosive, and the best people leave first because they have options | A recurring short survey, plus voluntary attrition among people with more than two years of tenure |
| Performance | Outcomes degrade last, which is exactly why performance alone is a lagging indicator of organizational debt | Change fail rate and escaped defects, read as a trend not a snapshot |
| Activity | Activity often rises as debt grows, because more effort is needed per unit of outcome. Never read it alone | Ratio of maintenance and toil work to new capability, tracked over quarters |
| Communication and collaboration | This is the dimension Conway's Law acts through, so it is the earliest and most specific warning you get | Number of teams that must be involved to ship a typical change; review latency across team boundaries |
| Efficiency and flow | Boundary debt shows up as waiting and interruption rather than as slow work | Uninterrupted focus time, and wait time at cross-team handoffs |
The Rule That Makes It Work
Pick metrics from at least three of the five dimensions, and never report one in isolation. The reason is not academic tidiness -- it is that any single dimension is trivially gameable and actively misleading. Activity alone rewards busywork. Performance alone hides the human cost until it is irreversible. Satisfaction alone can stay high on a team that is comfortable and shipping nothing. Reported together the dimensions constrain each other, and the pattern across them is what tells you whether you are looking at a technical problem or an organizational one. For the code-level side of the picture, see measuring technical debt.
Arguing for a Team-Shape Change in Debt Language
Here is the hard part. Reorganizations are decided far above engineering, on timelines engineering does not control, for reasons that are often not technical at all. An engineer who walks into that conversation asking for a reorg will lose, and will be remembered as someone who wanted to redraw the org chart. So do not ask for a reorg. Ask for a boundary change, priced.
Name the coupling concretely
Not "we have organizational problems". Instead: "Checkout changes require sign-off from Payments, and in the last quarter that added a median of nine days to eleven of our fourteen releases." A specific, countable, verifiable coupling.
Put a recurring cost on it
Convert wait time into something the business already tracks: delayed launches, engineering hours, incident duration, or the escalations the coupling generates. A cost per quarter is far more persuasive than a total, because it makes inaction visibly expensive.
Propose the smallest possible change
Move two people, or transfer ownership of one module, or change one interaction from collaboration to X-as-a-Service. Small boundary changes get approved because they are reversible. Reorgs get deferred because they are not.
Commit to the metric in advance
Say which number will move and by when, before the change. "Cross-team review latency on checkout drops below two days within one quarter." Naming the metric first is what separates a proposal from an opinion, and it is what buys you the next one.
What It Sounds Like Assembled
"Eleven of our last fourteen checkout releases waited on a Payments sign-off, adding a median of nine days each. That is roughly a quarter of our delivery capacity spent waiting rather than building, and it is the reason the pricing experiment slipped twice. We are not proposing a reorganization. We are proposing that the two engineers who already do all the payments work for checkout move onto the checkout team, and that Payments publishes a versioned interface instead of reviewing each change. We expect cross-team review latency on checkout to drop below two days within a quarter, and we will report it either way."
That is the same argument an engineer would make about a slow test suite, told about a reporting line. It works for the same reason: it is specific, it is priced, it is small, and it is falsifiable.
Related Resources
Architectural Decisions
Recording why a boundary is where it is, so the next reorganization does not erase the reasoning along with the team.
Training & Culture
Turning knowledge sharing into a standing practice, which is the only durable repayment for ownership and tribal-knowledge debt.
Team Health
The human-side signals that move before delivery metrics do, and how to read cognitive load without turning it into surveillance.
Measuring Tech Debt
Code-level measurement to pair with SPACE, so the organizational story and the repository story are told with the same evidence.
Frequently Asked Questions
Melvin Conway published it in Datamation in April 1968: organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations. The word constrained is the important one. It matters for technical debt because it predicts that a refactor which does not change the organization will be undone. If four teams share a communication structure that produces a coupled design, decomposing that design without changing the teams leaves the same daily pressure in place, and the structure grows back one pragmatic shortcut at a time.
It is deliberately reshaping teams to produce the architecture you want, running Conway's Law in the useful direction. Use it when you have a target architecture you can draw at the level of independently deployable pieces, when you can assign each piece exactly one owning team, and when you can move the code, the on-call rotation and the interface contracts along with the people. It fails when teams are reshaped and the code is not, because you then carry both the old mismatch and a new one, and it fails when it is used as after-the-fact justification for a reorganization that was already decided for headcount reasons.
Skelton and Pais use John Sweller's 1988 categories: intrinsic load is inherent to the problem, extraneous load comes from the environment the work is done in, and germane load is the valuable thinking. Technical debt is almost entirely extraneous load: undocumented deployment steps, four config systems, a build that needs an environment variable nobody wrote down. Because total capacity is finite, every unit of extraneous load displaces a unit of the other two, and germane load goes first. That is why an overloaded team stops producing good design work long before it stops producing code. Estimate it by counting the distinct services, runtimes and datastores a team owns, and by asking three members separately to draw the system they own.
Five signals, all cheap to gather. Commit drift: compare the last 90 days of committers per repository against the team that formally owns it, and treat zero overlap as fictional ownership. Review latency: chart median time to first review per repository before and after the reorg date, where a step change means the required reviewers moved and CODEOWNERS did not. On-call ambiguity: count incidents reassigned at least once before someone accepted them, which is the most honest ownership metric you have because it is measured under pressure. Orphaned repositories: anything deployed to production with no commit, no dependency update and no open issue in six months. And documentation rot: grep runbooks for team names, aliases and channels that no longer exist.
DORA measures the delivery pipeline, and its current guidance names five delivery metrics rather than the historical four keys. Those metrics are excellent and they are also blind to the human cost of debt: a team can hold lead time and deployment frequency steady for a year while cognitive load doubles, truck factor falls to one, and its senior engineers start interviewing. SPACE, published in ACM Queue in 2021 by Forsgren, Storey, Maddila, Zimmermann, Houck and Butler, adds satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. The practical rule is to pick metrics from at least three of the five dimensions and never report one in isolation, because any single dimension is trivially gameable.
Do not ask for a reorganization. Ask for a boundary change, priced. Name the coupling concretely and countably rather than describing it in general terms. Put a recurring cost on it, per quarter, in something the business already tracks. Propose the smallest reversible change that removes the coupling: moving two people, transferring one module, or converting one interaction from collaboration to a versioned interface. Then commit in advance to the metric that will move and by when, and report it either way. Small, priced, reversible and falsifiable proposals get approved; requests to redraw the org chart get deferred.
Fix the Structure, Not Just the Code
Overlay your org chart on your architecture this week. The components with two colours and the components with none are your next quarter of work.