Yes, architecture is a big bottleneck, because the majority of our time is spent reading code rather than writing it (and now, with AI, similar issue - AI has to spend time reading code before it makes changes).
"Reading" is at different levels - system level architecture, component level architecture, class design, and method implementations. Thye all need to be optimized to reduce maintenance costs.
Thanks for sharing! Could you elaborate further on "The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history."
We parse the full git log — every commit gives us: author, timestamp, and the list of files touched. That's the raw material.
For knowledge concentration, we count commits per author per file. If one person is responsible for 80% or more of the commits to a file over time, that file is flagged as a silo.
Roll that up to module level and you get a silo ratio per module — a number, not a feeling.
We ran this on the MongoDB open-source repository.
One developer accounts for 1,551 commits across 116 files in a single module. No secondary coverage. That's not a guess — it's directly in the history.
For hidden coupling, we look at co-change frequency: which files appear together in the same commits, and how often.
Files that repeatedly change together have an implicit dependency — regardless of what the architecture diagram says.
That's the "changing this always breaks reporting" pattern made visible.
The output is a ranked list: here are your highest-risk modules, here's who owns them, here's what they're coupled to across team boundaries.
No surveys. No manual mapping. Just the history the team already created.
If you want to see it on a real codebase: demo.calyntro.com — no login required.
This is really clear, thanks for walking through it, Karl-Heinz. The part that resonates most is turning "only Mike knows billing" into a number leadership can act on; that reframing is usually what gets it prioritized.
The nuance I'd add: the git log tells you where the risk is, but not why it got that way. A silo map is step one; changing the incentives that created the silo is the harder part, which is exactly where your review-routing and targeted-pairing points earn their keep.
Once a team sees their silo map for the first time, what's the most common first move you see them actually make?
The honest answer: the most common first move is a conversation, not a code change.
Someone shares the map with the team. The number lands differently than the feeling did — suddenly there's something to point at.
That usually moves things faster than any process discussion.
From there, the teams that actually follow through tend to do one specific thing: they pick a module — not necessarily the highest-risk one, but one they're about to touch anyway — and they add a reviewer who's never been in that code. No process change, no initiative. Just one PR.
You're right that the map doesn't tell you why. But I've noticed the "why" matters more for the emotional reaction than for the first step.
Whether the silo exists because Mike is brilliant and nobody else was allowed in, or because the module is genuinely scary and people avoided it — the first intervention looks the same: route work there with a fresh pair of eyes.
The incentive question tends to surface later, once the map is no longer a surprise. That's usually when the harder conversation starts.
Architecture becomes the real bottleneck.
Yes, architecture is a big bottleneck, because the majority of our time is spent reading code rather than writing it (and now, with AI, similar issue - AI has to spend time reading code before it makes changes).
"Reading" is at different levels - system level architecture, component level architecture, class design, and method implementations. Thye all need to be optimized to reduce maintenance costs.
"Only Mike understands billing" — that's not just a people problem. It's measurable.
When 80%+ of the commits to a module come from one person, that's a knowledge silo.
Git history records it commit by commit — long before Mike hands in his notice.
"Changing this always breaks reporting" is also in the log: billing and reporting co-changing in the same commits, across years, across teams.
Nobody documented it, but the codebase did.
The mental map experienced developers carry exists in the git log.
It just needs to be read.
Yes, knowledge silos are a huge problem. What are some strategies you've tried to tackle this problem?
The first step that actually worked for me: stop guessing where the silos are.
Most teams think they know — but when you look at the commit history, the real concentration is often somewhere unexpected.
A module nobody worries about, owned by one person for three years.
Once you have the map, three things help:
Deliberate review routing — PRs for high-silo modules go to someone who doesn't own them. Slow at first. Worth it in the end.
Pairing on the scary modules — not as a general practice, but targeted at the files with the highest knowledge concentration.
Making the risk visible to leadership — "only Mike knows billing" lands differently when you can show it as a number.
That's when it gets prioritized.
The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history.
Happy to share more if useful.
Thanks for sharing! Could you elaborate further on "The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history."
The process is simpler than it sounds.
We parse the full git log — every commit gives us: author, timestamp, and the list of files touched. That's the raw material.
For knowledge concentration, we count commits per author per file. If one person is responsible for 80% or more of the commits to a file over time, that file is flagged as a silo.
Roll that up to module level and you get a silo ratio per module — a number, not a feeling.
We ran this on the MongoDB open-source repository.
One developer accounts for 1,551 commits across 116 files in a single module. No secondary coverage. That's not a guess — it's directly in the history.
For hidden coupling, we look at co-change frequency: which files appear together in the same commits, and how often.
Files that repeatedly change together have an implicit dependency — regardless of what the architecture diagram says.
That's the "changing this always breaks reporting" pattern made visible.
The output is a ranked list: here are your highest-risk modules, here's who owns them, here's what they're coupled to across team boundaries.
No surveys. No manual mapping. Just the history the team already created.
If you want to see it on a real codebase: demo.calyntro.com — no login required.
This is really clear, thanks for walking through it, Karl-Heinz. The part that resonates most is turning "only Mike knows billing" into a number leadership can act on; that reframing is usually what gets it prioritized.
The nuance I'd add: the git log tells you where the risk is, but not why it got that way. A silo map is step one; changing the incentives that created the silo is the harder part, which is exactly where your review-routing and targeted-pairing points earn their keep.
Once a team sees their silo map for the first time, what's the most common first move you see them actually make?
The honest answer: the most common first move is a conversation, not a code change.
Someone shares the map with the team. The number lands differently than the feeling did — suddenly there's something to point at.
That usually moves things faster than any process discussion.
From there, the teams that actually follow through tend to do one specific thing: they pick a module — not necessarily the highest-risk one, but one they're about to touch anyway — and they add a reviewer who's never been in that code. No process change, no initiative. Just one PR.
You're right that the map doesn't tell you why. But I've noticed the "why" matters more for the emotional reaction than for the first step.
Whether the silo exists because Mike is brilliant and nobody else was allowed in, or because the module is genuinely scary and people avoided it — the first intervention looks the same: route work there with a fresh pair of eyes.
The incentive question tends to surface later, once the map is no longer a surprise. That's usually when the harder conversation starts.