Conway's Law was formulated in 1967. It says: any organization that designs a system will produce a design whose structure mirrors the organization's communication structure.
Fifty-eight years later, most engineering teams treat it as a useful metaphor. Something to quote in architecture reviews and then move on.
I've started treating it as a measurement problem.
The question isn't whether Conway's Law applies to your organization — it does, almost certainly. The question is whether you can see how it applies. And until recently, that required expensive org mapping exercises, workshops, and a lot of guesswork.
Your Git history already contains the answer.
Every commit records what changed, when, and alongside what else. Over thousands of commits, the pattern of what changes together — across which boundaries — is a direct artifact of how your teams coordinate. Not how they're supposed to coordinate. How they actually do.
The experiment
To make this concrete, I took the MongoDB open-source repository and assigned a simulated team structure to it.
⚠️ MongoDB has no official teams — it's an open-source project. This was a deliberate experiment to test whether Conway's Law shows up in Git metadata. The commit history is real. The team assignments are not.
What showed up was clear: coupling patterns that crossed team boundaries were visible directly in the commit log. Modules assigned to different teams changed together, consistently, over time. Not because someone designed it that way. Because the people doing the work were coordinating — and coordination leaves traces.
The asymmetry was particularly striking. Some dependencies were one-directional: module A consistently triggered changes in module B, but not the other way around. That's not coincidence. That's an architectural signal — a hidden dependency that no diagram captures, but that every engineer on the team implicitly knows about.
What this means in a real organization
In an open-source project, there are no formal teams — so the simulation is just that. But in an organization with real team structures, this analysis becomes a diagnostic tool.
Which modules are your teams creating invisible dependencies between? Where are coordination costs accumulating without anyone naming them? Does your architecture actually reflect how your teams work — or how you think they work?
These are questions your Git history can answer. The data has always been there. What was missing was a way to read it.
That's what we're building with Calyntro — a self-hosted repository intelligence tool that analyzes Git history to surface knowledge silos, coupling patterns, and Conway's Law violations. Nothing leaves your infrastructure.
The MongoDB analysis is live at demo.calyntro.com — no login required.
Originally published on the Calyntro blog.
Top comments (0)