Most engineering leaders have heard of Conway’s Law. Far fewer have heard of Conway Drift, and that gap is precisely where a lot of organizations quietly lose their velocity.
Conway’s Law is one of those observations that sounds almost too simple to be useful, right up until you watch it govern the fate of a multi-year product program. Conway Drift is its slow-motion sequel: what happens after you’ve gotten the structure right, when nobody is watching the alignment erode. The first is a snapshot. The second is a trajectory.
This article walks through four things: what Conway’s Law actually claims, why Conway Drift is the more dangerous failure mode, how to diagnose it in your own organization, and what to do once you’ve found it.
Webinar Recording (German)
Webinar Slides
What Conway’s Law Actually Says
In 1968, Melvin Conway made a structural observation that has aged remarkably well:
Organizations design systems that mirror their own communication structures.
That’s it. The architecture you ship will resemble the org chart that built it, whether or not anyone intended that. If three teams build a compiler, you get a three-pass compiler. If your firmware, cloud, and mechanical groups never talk, you get three subsystems with a no-man’s-land between them where the integration bugs live.
Importantly, the law is not a metaphor about culture. It’s a claim about coupling. Every architectural boundary implies a coordination boundary during development. An interface between two subsystems becomes an interface between two teams. A dependency that crosses a team boundary becomes a meeting, a ticket, a handoff, a negotiation. The system’s interaction structure and the organization’s communication structure are not two separate things you can manage independently: they are two views of the same object.
For most of its life, Conway’s Law gets treated as a constraint: a fact you have to work around. The more interesting move is to treat it as a lever. Applied deliberately, the relationship runs in reverse: you can choose the architecture you want and then shape teams to produce it. This is the inverse Conway maneuver, and we’ll come back to it. For now, the point is that architecture and organization co-evolve, deliberately or not. If you only manage one, the other is managing you.
Alignment Naturally Fades
Here’s the problem. A young company usually has a clear picture of its product architecture, and the organization’s structure follows from it. But over time the architecture evolves: a subsystem gets extracted, a new platform capability emerges, a market pivot changes what the product even needs to do.
The organization evolves too, on its own schedule: people leave, teams merge for budget reasons, a reorg chases a headcount target instead of an architectural one. The two structures were aligned once. Now they diverge a few degrees at a time, and no single decision ever felt like the wrong one.
An established organization can, of course, run a reorg to correct the misalignment. When it works, things genuinely move faster — for a quarter or two, until the two structures pull apart again. More often, though, parts of the organization quietly reject the change. The boxes move on the chart, but the old communication paths persist. Some alignment is better than none, but the efficiency the reorg promised never quite materializes.
Why “Drift” Is the Part That Hurts
That is Conway Drift: architecture and organization gradually decouple after an initial alignment. Boundaries that once matched diverge as one side evolves faster than the other. And because it’s gradual, it never trips an alarm. There’s no incident, no outage, no board-level moment. There’s just a steady rise in coordination cost that everyone learns to live with.
The damage is subtle but compounding. When the mismatch goes uncorrected, system-level coherence erodes. Conflicting perspectives stop getting resolved by design and start getting resolved by compromise. For instance, the integration meeting where two teams split the difference because neither owns the whole. The predictable result is a product that lacks conceptual integrity and satisfies no stakeholder particularly well. Modular on the diagram; tangled in practice.
The automotive industry has been living this out in public. Through the 2020s, established carmakers have struggled to realign their organizations around the architecture of electric and software-defined vehicles. The mechanical-first org structure that built combustion cars for a century doesn’t map onto a vehicle whose value increasingly lives in software and centralized compute. The architecture moved. The organization didn’t move with it. Conway Drift, at industrial scale! And it reintroduces exactly the coordination problems the new architecture was supposed to dissolve.
That’s the cruel part. You can do the architectural work correctly and still inherit the old coordination tax, simply because the human system didn’t follow the technical one.
How to Diagnose It
Conway Drift hides because it never announces itself. So you have to go looking. A few diagnostic moves, from cheapest to most involved:
Map team boundaries against architectural boundaries
Take your current architecture’s decomposition and your current org chart and overlay them. Mark where a team owns a clean, well-bounded component — and where ownership cuts across an architectural boundary. Every place ownership and architecture disagree is a candidate drift site. If a single subsystem is owned by two teams, or one team owns three loosely related things, that’s where coordination is leaking.
Watch where coordination actually happens.
If your product looks modular but integration keeps reappearing in meetings, handoffs, and end-of-quarter integration crunches, the modularity is on the slide deck, not in the system. Recurring integration failures that track specific team seams are a strong tell. So is “we need everyone in a room to ship this” for something the architecture says should be independent.
“We need everybody in the room” is a sign of Conway Drift.
Trace your last reorg back to its trigger.
For a recent organizational change, ask: was it triggered by a concrete architectural or strategic shift, or by something else, like a budget cycle or a manager’s span of control? Reorgs that aren’t anchored to architecture are how drift gets introduced, not corrected.
Many reorgs introduce Conway Drift, instead of removing it.
Check whether the incentives still match the structure.
Drift isn’t only about boxes on a chart. Metrics and incentives calibrated to a previous organizational shape will quietly pull teams back toward the old boundaries no matter how you redraw them. Behavior follows the incentive, not the declared priority.
If you want a faster, structured starting point, run your situation through the Anti-Pattern Finder. Conway Drift is one of a family of organizational-evolution anti-patterns, alongside Frozen Structure (the org never changes while the product does) and Reorganization Theater (the org changes constantly but without architectural intent). The finder helps you name which one you’re actually looking at. Naming it precisely matters, because the three failures look superficially similar but call for opposite responses: Frozen Structure needs you to move, Reorganization Theater needs you to stop moving randomly, and Conway Drift needs you to move with intent toward a defined target.
What to Do About It
Diagnosis without a response is just anxiety. Once you’ve located the drift, there are three complementary moves.
1. Use the inverse Conway maneuver
Instead of accepting whatever structure the current organization implies, shape team boundaries to produce the architecture you want. When a product needs a clean separation between, say, a sensing subsystem and a cloud backend, forming two teams with a defined interface between them is an architectural decision as much as an organizational one. This is how SpaceX runs major development: groups tied to physical and functional modules — Starship, the booster, barrel sections, the launch tower — each carrying its own software, mechanical engineering, procurement, and quality, integrating through stable, explicit interfaces. Teams pull from each other as customer and supplier rather than queuing behind a central program office. The org chart is the architecture, on purpose.
2. Refactor the organization deliberately
Conway Drift tempts two equal and opposite mistakes. One is to freeze the structure to avoid disruption, letting the gap widen. The other is to reorganize constantly, which destroys the accumulated domain knowledge that gives long-lived teams their edge. Neither serves the product. A practical heuristic: refactor when the coordination cost of the current structure visibly exceeds the transition cost of changing it, and only when the architectural or strategic trigger is concrete enough to define the target state. Refactor without a clear target and you get reorganization theater; wait past the point of obvious friction and you accumulate organizational debt that compounds fast. When you do move, define the target state before you move people, move people with the components they know, and fund the knowledge transfer explicitly. Reorganization that disperses hard-won domain context destroys exactly the asset that makes velocity compound.
3. Give stewardship the authority to hold the line
Drift is what happens in the absence of anyone whose job is coherence. Someone has to own the intent and constraints of the system across transitions: Not the implementation, but the alignment between structure and architecture. That’s the role of system stewardship, and it only works if it has real authority. A steward with responsibility for coherence but no power to enforce it just watches the drift happen with a better vocabulary. Pair that authority with metrics that surface trade-offs honestly and escalation paths that resolve conflicts by design rather than by whoever pushes hardest in the meeting.
The Takeaway
Conway’s Law tells you that your architecture and your organization are the same system viewed two ways. Getting them aligned once is an achievement. But alignment is not a state you reach: it’s a state you maintain, because both halves keep moving and they rarely move at the same speed.
Conway Drift is the default outcome of doing nothing. It’s gradual, it’s invisible, and it’s expensive precisely because nobody decides to let it happen. The organizations that sustain velocity aren’t the ones that nailed the perfect structure on day one. They’re the ones that keep checking whether the structure still matches the system, and have the authority, and the discipline, to realign before the drift becomes the bottleneck.
Start by overlaying your two org charts: the one HR maintains, and the one your architecture implies. Wherever they disagree, that’s where your next slowdown is already forming.
English
German