The Ownership Illusion
Six months after the backend cofounder "owned" the server codebase, he opened it and didn't recognize half of it.
Nothing dramatic had happened. No mass rewrites, no stealth architect who redesigned everything while he slept. Just six months of small decisions: a bug fix at midnight because the frontend person happened to be online and the thing was on fire, an API endpoint added because waiting would cost a week, a refactor that made sense to whoever was in the code that day. Commit by commit, the actual expertise migrated. His name was still on everything in git blame. The CODEOWNERS file, the config that tells GitHub who should review changes to each part of the codebase, still pointed to him. Every teammate's mental model still had him as the backend person.
Nobody noticed because no metric tracked it.
This is ownership drift. Not the dramatic "key person quits" scenario that gets discussed in planning meetings, but the slow, invisible divergence between who is listed as the owner and who actually understands the code. It happens on every engineering team. Almost nobody sees it while it's happening.
This is the version of the problem you can see once someone points it out. The version you can't see is worse.
The standard response to this kind of risk has a name: the bus factor. It's the number of people who would have to disappear before a project is in serious trouble. One person understands the payments service? Your bus factor is 1. The conventional wisdom says raise that number: rotate contributors through, get more eyes on the code, spread the ownership until no single departure is catastrophic.
This is directionally wrong, not just slightly off.
Bird et al. at Microsoft Research first identified the "minor contributor effect" in 2011, studying Windows: components with more minor contributors had more pre- and post-release defects, not fewer. More contributors, more bugs. The minor contributor count was a stronger predictor of defect rates than code churn, total changes, or team size. A "minor contributor" meant anyone responsible for fewer than 5% of changes to a component.
That was 2011, and the finding has replicated consistently since. Greiler et al. (2015) confirmed it at file and directory level across four Microsoft products, finding weakly owned files significantly more defect-prone. In 2024, a study of TensorFlow and PyTorch found that ownership metrics improved vulnerability detection by 20% over code-only metrics, with the minor contributor count as a key signal. Research on Kubernetes and Ansible configuration scripts identified the same pattern, labeling it "minors are spoiler": minor contributors correlated with security infections and configuration defects. A study of the Linux kernel found that when more than nine developers contribute to a source file, it is sixteen times more likely to contain a security vulnerability.
The mechanism matters more than the number, and it's worth understanding why. Minor contributors lack the component's internal semantics. They don't carry the invariants, the edge cases, the implicit "never touch X without also touching Y" that exists in no design document anywhere. Their changes look correct in isolation and violate assumptions that only the deep owner holds in their head. This isn't about skill level. A senior engineer with shallow familiarity with a component is structurally more likely to introduce subtle defects than a junior engineer who has been living in that code for two years. Context depth is what makes changes safe, and context depth can't be borrowed or distributed by fiat.
The uncomfortable math: TF=1 with a genuine expert is fragile but stable. TF=10 with ten shallow contributors is fragile AND defect-prone. You didn't fix the risk. You replaced one kind of fragility with a worse kind. Both configurations are vulnerable to departures, but only one actively degrades code quality while everybody is still at their desks.
GitHub reported 43.2 million PRs merged per month in 2025, up 23% year over year. Ninety percent of engineering teams now have AI tools in their workflows. For top-adopting teams, PR throughput runs roughly 2x baseline, and for specific power-user cohorts tracked by GitClear, code changes scale 4 to 10 times higher. AI is the ultimate minor contributor. It touches vast swaths of code with zero understanding of business logic, architectural constraints, or the invariants your team has encoded over years of production incidents. The ownership dilution that Bird, Greiler, and the Kubernetes researchers all documented is now happening at machine speed, and AI-generated PRs carry a 32.7% acceptance rate against 84.4% for manual ones. That gap is the Bird finding playing out in real time.
The metric most engineering leaders reach for when thinking about this, bus factor, contributor count, CODEOWNERS entries, is measuring labels. What it's not measuring is knowledge.
Fritz et al. (2010) built a computational model for developer knowledge of source code, validated against developer self-assessments. Four factors determine how well you understand a piece of code: whether you wrote it originally, how recently you've interacted with it, how much of it has changed since your last interaction, and how much you've been reading and debugging it as opposed to just authoring it.
That third factor is the one that matters for ownership drift. Other people's commits to a file actively erode your knowledge score. Not as a metaphor, as a measurable quantity. Every sprint where someone else makes changes to a component while you're working on something else, your understanding of that component degrades. The decay is continuous and computable, not a vibe or gut feeling. An actual regression model, validated against what developers themselves said about their own expertise.
A name in CODEOWNERS is a historical artifact. It says who understood this code at the time of authorship. It says nothing about who understands it now. The person who wrote a critical service two years ago and is still listed as the domain expert has, under this model, measurably lower knowledge of it today than the day they shipped it, assuming others have been changing it while their attention was elsewhere.
This is the mechanism behind the drift scenario above. No one decided to erode the backend cofounder's expertise. No one made a decision at all. It happened as a mathematical consequence of normal engineering work: attention divided, tickets distributed, other things on fire. The label stayed green while the knowledge underneath it quietly eroded.
The ownership mismatch doesn't stop at code quality. Where code in one team's domain calls into code owned by another, and those two teams have no regular communication, delivery delays pile up at that boundary. Cataldo and Herbsleb's socio-technical congruence research found that code collaboration patterns mostly confirm the existing org chart rather than reveal a hidden one underneath it. Teams with matching coordination structures resolved issues 32% faster on average. The gaps your org chart doesn't show, and your Jira board doesn't show, live in the structure of the code itself.
The single most valuable knowledge transfer you can make is TF 1 to TF 2. That move takes a component from existential fragility to survivable risk. Beyond that, the returns diminish faster than most leaders expect, and the Bird research suggests that past a certain threshold, spreading ownership actively increases defect risk rather than reducing it. Avelino's 2016 study of 133 GitHub projects found that 65% had a truck factor of 2 or lower, which means most teams are already in the existential zone for most of their critical components. The problem isn't that people don't understand the concept. It's that they're applying the wrong fix.
Three things have to change, none of which require a reorg.
Measure depth, not breadth. Contributor count is the wrong metric. What matters is how many people have deep, recent understanding: commits, reviews, debugging sessions over the last quarter, not the drive-by fix that shows up in git blame and inflates the TF count.
Track decay, not blame. Knowledge fading is not a personal failure. It's a natural consequence of senior engineers doing their jobs, which involves rotating attention, leading initiatives, and occasionally not touching the payments service for six months because there are bigger fires. The question isn't who let their knowledge decay. It's whether anyone is watching the decay rate before the gap shows up in an incident. I keep seeing teams discover this the hard way: the person in CODEOWNERS and the person who actually understands the component are not the same person anymore.
Focus transfers on specific high-risk gaps. Imagine you run a payments service, a notification pipeline, and an internal ML feature store, each with one person who actually understands it. Broad cross-training spreads attention too thin to build real depth. Pick three components with dangerous knowledge concentration, identify three people who should be spending time in them over the next quarter, and bound it. Targeted, time-bounded, prioritized by where the gap is actually dangerous.
What this looks like in practice: knowing, week by week, which components have drifted from their listed owners. Not a quarterly audit someone runs the week before an engineering offsite. A continuous signal, the equivalent of uptime monitoring but for your knowledge topology rather than your infrastructure. When the real expertise has migrated from the person in CODEOWNERS to whoever has been living in the code for the past three months, you want to know about it before a production incident makes the introduction.
(It kind of is a product pitch. But the research that makes the case for it, Bird, Fritz, Cataldo, all predates any product by over a decade. The measurement problem has been sitting there since 2010. The tools are newer than the problem.)
The metrics tracking the number of owners are telling you something real. They're just not telling you what you think they're telling you.
Most teams do knowledge transfer reactively: someone puts in their notice, and suddenly there's a frantic two-week handoff where the departing engineer tries to dump everything they know into documents nobody will read. Or an incident reveals a gap, and the postmortem action item is "cross-train the team on the payments service," which gets deprioritized by the next sprint. By the time the transfer happens, the knowledge has already degraded past what a rushed handoff can recover.
The alternative is to treat knowledge transfer like you treat testing or code review: continuously, proactively, as part of how the team works rather than a response to something breaking. Deeper each quarter, not broader each crisis.
The next question is what that actually looks like. Knowing which expert has drifted from their component is useful. Moving knowledge from the person who used to understand it to someone who needs to now, without destroying anyone's flow state to do it, is harder. That's what the next post is about.
Next time: Once you can see where knowledge has drifted, how do you move it? The Detect-Match-Transfer-Verify loop, and why the interrupt model from Post 3 is the wrong transfer mechanism even when you know exactly who needs to learn what.