Why engineering continuity matters

Is continuity measurable, or just preferred?

Arguments for keeping a team together usually rest on assertion. There is a research literature underneath the question, and it is more specific than the assertion.

Rigby, Zhu, Donadelli and Mockus studied Chrome and a project at Avaya, borrowing Value at Risk from financial modelling to produce a measure they called Knowledge at Risk. Their unit of analysis is the abandoned file: source code where every developer who worked on it has left. Files in that state are maintained by people who did not write them, and the study connects that condition to reduced productivity and a higher chance of mistakes.

The measure matters more than the number, because it makes a vague worry into something an organisation can check on a Monday morning. For each component, how many people who still work here have changed it in the past year? One is a concentration risk. Zero means the loss has already happened.

Ownership is related to defects

Bird and colleagues at Microsoft Research examined ownership patterns in Windows Vista and Windows 7. Two measures showed a relationship with both pre-release faults and post-release failures: the number of contributors with low expertise in a component, and the proportion of ownership held by its main owner.

The finding is uncomfortable for a common management instinct. Rotating engineers to spread knowledge produces exactly the low-expertise contribution pattern the study associates with more defects, at least in the short term. The research does not settle the question of collective versus concentrated ownership, and serious practitioners hold both positions. What it does establish is that ownership is a variable with consequences, not a preference.

What actually leaves when an engineer leaves?

Not the code, which is still there and can be read. What leaves is the reasoning: the constraint that ruled out the obvious design, the customer behaviour that explains an apparently redundant check, the incident three years ago that produced a defensive branch nobody has dared remove.

Some of that can be written down, if it is written at the moment of the decision rather than at handover. Much of it cannot, because nobody knows in advance which detail will matter. This is why documentation is a partial answer, and why the studies measure loss in terms of who is still present rather than what was recorded.

What is at risk	Recoverable from	Cost to recover
What the code does	The code, tests, and increasingly a coding assistant	Hours to days
How the system is deployed and operated	Pipelines, runbooks, infrastructure definitions — where they exist	Days to weeks, longer where undocumented
Why the design is as it is	The people who decided, or written decision records	Often unrecoverable
Which changes are dangerous	Operational history and the memory of past incidents	Usually relearned through an incident

Practices that hold context

The useful interventions are small and unglamorous. Measure concentration per component rather than counting headcount. On single-owner components, name a second reader whose job is to hold context rather than to catch mistakes. Record decisions when they are made, including the alternatives that were rejected and why.

Handover deserves a stricter definition than it usually gets. Transferring credentials and walking through a repository establishes access, not capability. A handover is finished when the receiving engineer has made a real change and deployed it without help. Anything short of that is an assumption.

What AI changes here

Coding assistants have genuinely lowered the cost of the first week in an unfamiliar codebase. They trace call graphs quickly, summarise unfamiliar modules, and answer questions that previously required interrupting a colleague. That is a real improvement in onboarding friction.

They do not recover intent. An assistant can describe what a function does and cannot tell anyone why it was written that way, or what happened the last time someone simplified it. Meanwhile the volume of code that no living person authored is increasing, which enlarges the surface that has no owner at all. The argument for continuity is stronger in 2026 than when the underlying research was published.

Why this matters commercially

Continuity is a property a client can specify and check. Which named engineers will still be on this system in twelve months, what happens when one of them leaves, and how the receiving engineer will be brought up to speed are answerable questions, and a vendor that cannot answer them is describing a risk it has chosen not to price.

We answer them because we run engagements that way: the same engineers, on the same systems, for years rather than months. Several of our client relationships are measured in years rather than projects, and that is the mechanism behind it.