What Your Git History Reveals About Team Alignment
Your org chart says one thing. Your Git history says another. They're rarely the same.
Last week I wrote about Conway's Law as a measurement problem — the idea that every commit records not just what changed, but how your teams coordinate. That the co-change pattern across thousands of commits is a structural artifact of who talks to whom, day by day, pull request by pull request.
This week: what it actually looks like when you read that pattern.
The Two Answers to "Who Owns This Module?"
Every team has modules they officially own. Usually documented in a wiki, a Notion doc, a team channel description — or, more commonly, in everyone's heads. That's the first answer.
The Git history has a second answer: who actually commits there, how often, and how recently.
These two answers diverge more than most engineering leaders expect. Some modules are touched by everyone regardless of who "owns" them. Some are effectively maintained by a single person who moved to a different team two years ago but never handed off their tacit knowledge. Some have cross-team coupling so strong that the team boundary exists in name only — two teams coordinating constantly on a module pair that the architecture diagram shows as independent.
None of this appears in your architecture diagram. All of it appears in your commit log.
Three Patterns That Show Up
When you map team ownership onto co-change history systematically, three patterns emerge with enough consistency to be structurally meaningful:
1. De facto ownership drift
Modules formally assigned to one team are predominantly committed by contributors assigned elsewhere. The official owner and the practical owner have diverged — not through any explicit decision, but through accumulated pull requests and the organic drift of where work actually lands.
This is invisible in the org chart. It's unmistakable in the commit history.
The risk isn't just process messiness. When ownership drifts, so does the knowledge. The person with the deepest understanding of a module may no longer appear on the team's roster. If they leave, that knowledge leaves with them. This is how knowledge silos form — not through negligence, but through momentum.
2. Cross-team coupling
Changes in certain modules are consistently followed by changes in modules assigned to a different team. Not occasionally — consistently. Commit after commit, over weeks or months, one module's changes trigger follow-on work in another team's module.
This is a coordination dependency that exists in practice but has no formal representation. It doesn't show up in the dependency graph. It doesn't appear in the sprint board. It surfaces only as recurring synchronization meetings, Slack threads that say "did you already update X for this?", and the ambient friction that slows down work without ever having a clear name.
The co-change pattern makes it visible and measurable.
3. Asymmetric dependencies
In the strongest coupling pairs, the dependency runs in one direction. Module A consistently drives changes in Module B — but changes in B rarely require changes in A.
Symmetric coupling can be coincidental: two modules that happen to appear in the same large refactors. Asymmetric coupling is a structural signal. When A always drives B but not the reverse, there is an implicit architectural dependency that was never formally designed — it just accumulated. And whoever maintains A has to think about B every time, whether they're supposed to or not.
At scale, asymmetric cross-team coupling is one of the clearest indicators that a formal API boundary needs to be drawn. Not as a bureaucratic constraint, but because the coupling already exists and making it explicit would reduce the coordination cost rather than add to it.
The MongoDB Experiment
To illustrate what this analysis actually surfaces, we ran it on the MongoDB open-source repository with a simulated team structure.
⚠️ Important disclaimer: MongoDB is an open-source project with no official team structure. The team assignments used in this analysis are constructed for demonstration purposes — not derived from any real organizational data. The Git history and co-change patterns are real. The team boundaries are not.
This was a deliberate choice: a codebase large enough to produce statistically meaningful patterns, without misrepresenting any real organization.
What emerged:
- 492 coupled module pairs detected across the repository
- 167 of those (34%) crossed simulated team boundaries — Conway's Law violations relative to the structure we assigned
- 46,208 coordination events where a cross-team change was followed by a follow-on change in another team's module
- Clear directional asymmetry in a subset of pairs: one module consistently drove the other, not the reverse
The patterns were structurally coherent. The modules with strong directional cross-team coupling were the ones where, in a real organization, you'd expect engineering leads to be having the same conversation repeatedly: "why does every change in X require a change in Y?"
That conversation is expensive. It usually happens informally, without any record. It doesn't appear in retrospectives or architecture reviews. But it appears in the commit history — if you look.
You can explore the full MongoDB analysis at demo.calyntro.com — no login required.
Three Questions This Makes Answerable
For an engineering leader, the practical value of this analysis isn't the metrics themselves — it's the questions they make answerable:
Which modules are creating hidden coordination overhead between teams?
Not the dependencies that are formally documented and managed, but the ones that emerge organically from how the work actually gets done. The ones where a change in team A's module silently requires someone from team B to follow up — with no mechanism to make that dependency visible until it's already causing friction.
Does your architecture reflect how your teams actually work — or how they're supposed to work?
Org charts and architecture diagrams describe intention. Commit history describes reality. The gap between them is where Conway's Law lives, and where the invisible coordination costs accumulate.
Is a planned reorganization going to reduce coupling or increase it?
Before restructuring teams, you can look at the current coupling patterns and reason about which new structure aligns with actual co-change behavior — and which modules would need to be actively refactored to make a new structure viable without increasing coordination overhead.
These questions aren't new. What's new is that they're answerable from existing data — without instrumentation, without surveys, without source code access. The signal has been accumulating in your repository since the first commit.
Why This Is Different from Static Dependency Analysis
Static dependency analysis tells you what the code imports. That's useful, but it captures only formal, explicit dependencies.
Git history tells you what the code needs to change together in practice. That includes implicit dependencies — shared data contracts, configuration coupling, behavioral assumptions that are tested together even when they're not linked in the import graph. It includes the operational dependencies that emerge from how the system is actually deployed and maintained.
And it includes something no static analysis tool can capture: the organizational signal. A co-change pattern between two modules doesn't just tell you about the code — it tells you about the people. About who coordinates with whom, how often, and in which direction.
That's the Conway's Law signal. And reading it doesn't require any changes to your development process.
What This Looks Like in Practice
The Team Alignment view in Calyntro makes this analysis operational. You define your team structure — which contributors belong to which team, which modules fall under which team's ownership — and the analysis maps your actual co-change history against that structure.
The output answers the questions above directly:
- Modules with cross-team co-change patterns, ranked by coupling strength
- Directionality scores for each pair — which module is the driver
- Ownership drift: modules where the de facto contribution pattern doesn't match the assigned owner
- Knowledge concentration: where a single contributor (regardless of team) has accumulated the bulk of recent commits
The analysis runs on your Git history. No source code is parsed. No external data is required. Nothing leaves your infrastructure.