How ownership analysis changes when you layer in change coupling — with real findings from the MongoDB open-source repo.
Most tools that measure bus factor stop at the number. One person owns this module. Here is the percentage. Good luck.
That's useful context. It's not useful guidance.
The question an engineering leader actually needs answered isn't how concentrated is the knowledge? — it's what do I do about it, and where do I start?
The Problem With Raw Risk Metrics
Knowledge concentration exists in virtually every codebase. Run any ownership analysis on a real production repository and you'll find modules where one person did 80% of the meaningful work. You'll find files nobody else has touched in two years. You'll find developers who accumulated knowledge across hundreds of commits that isn't written down anywhere.
Showing all of that at once produces a list of concerns. It doesn't produce a priority.
What Changes When You Add Context
We ran Knowledge Risk analysis on the MongoDB open-source repository (~500k commits). The analysis surfaces five recommended actions, ranked by severity. Three are marked critical.
Here's the most urgent finding, in the exact language the analysis produces:
"Single point of failure — Developer 1389 is the sole owner of 116 files in src_third_party, with 1,551 commits of accumulated activity."
Recommended action: "Initiate knowledge transfer — no secondary owner in high-churn module."
That's not a metric. That's a sentence you can read in a planning meeting and act on the same week.
The Combined Risk Signal
The more interesting finding is what happens when you look at two analytical dimensions together.
bazel_resmoke is a small module — 3 files, 100% silo ratio. One developer, no secondary owner. Flagged as critical.
On its own, that's manageable. Small module, isolated risk, schedule a knowledge transfer session.
Now add: bazel_resmoke changes together with src_mongo at a coupling score of 100 — cross-team.
The analysis flags this as: "Combined risk: ownership concentration + cross-team coupling."
Recommended action: "Priority: bazel_resmoke couples strongly with src_mongo — silo risk is amplified by cross-team coupling."
This changes the response entirely. It's not just "schedule a knowledge transfer session." It's "this module's isolation doesn't just affect one team — it affects the team that depends on it too." Two teams need to be part of the conversation.
A silo risk and a coupling risk, separately, are each manageable. Together, they amplify. If the sole owner leaves, the coupled cross-team dependency loses its primary contact point on both sides simultaneously.
Prioritisation by Severity
The Knowledge Risk view produces a sorted list:
- Critical — sole ownership + high activity + no secondary coverage → act now
- Watch — ownership concentration increasing month-over-month → monitor, plan
- Elevated — measurable risk, not yet acute → track
That ordering matters. 17 of 43 MongoDB modules show measurable knowledge risk. If everything is equally urgent, nothing gets addressed. The severity ranking turns a list of concerns into a sequence of decisions.
How the Analysis Works
This runs entirely from Git history. No source code access. No interviews. No dependency on team members self-reporting their expertise.
The Git history records who built what, when, and how much. Temporal ownership — who owned the code when the meaningful decisions were made, not just who last touched it — is what makes the signal credible.
A module that was built entirely by someone who left 18 months ago doesn't look risky in a current ownership snapshot. It looks risky in the historical record.
The full MongoDB analysis is live at demo.calyntro.com — no login required. To run this on your own repository: calyntro.com/#contact. Self-hosted. Nothing leaves your infrastructure.
