Why this exists

Official org charts are aspirational. They show the structure leadership wishes existed — the clean reporting lines, the tidy ownership domains, the teams that supposedly collaborate. The codebase shows the real one. The duplicated abstractions, the unowned modules nobody touches, the team boundaries dressed up as architectural choices, the passive-aggressive TODO that has survived four reorgs. If you want to know how a company actually works, don't read the wiki. Read the diff.

What you get back

  • An inferred org chart, derived from module boundaries, naming conventions, and commit clustering.
  • Identified team boundaries with file-level evidence — which directories belong to which tribe.
  • Suspected conflicts between teams, surfaced through duplicated abstractions, competing utilities, or rival frameworks living in the same repo.
  • Unowned or contested modules — the orphan code nobody will touch and the battlegrounds where two teams keep overwriting each other.
  • Recommendations for which org-level conversations would unblock the codebase, ranked by leverage.

When to reach for this pattern

Pre-acquisition due diligence, when you need to know what you're really buying. Org redesigns, when leadership is debating boxes on a slide and the code already has the answer. Consulting engagements where you have a week to understand the team and the people won't tell you the truth but the repo will. And the most useful case: explaining to leadership why the refactor will fail if the team structure doesn't change first. Conway's Law doesn't negotiate.