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. ...
Conway’s Law was stated in 1967: any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. Fifty-eight years later, it is still being treated as a principle to design toward — not a pattern to measure in what already exists. That’s the gap we wanted to close. From Metaphor to Measurement The usual treatment of Conway’s Law goes like this: recognize that your teams' communication structure will shape your architecture, then design your teams deliberately to get the architecture you want (this is what Team Topologies calls “inverse Conway maneuver”). That’s sound advice. ...
Your architecture diagram shows what your system is supposed to look like. Your Git history shows what it actually does. Those two things are rarely identical. What Change Coupling Is Change coupling measures how often two modules change in the same commit — without any static code analysis, without reading a single line of source code. Just commit metadata and file paths. If module A and module B consistently appear together in commits, something connects them. Maybe it’s a shared interface. Maybe it’s a hidden dependency. Maybe it’s one team doing the work of two. Whatever the reason, the Git history captures it. ...