Engineering continuity, and what it costs to lose it

Can the cost of losing an engineer be measured?

Partly, and the part that can be measured is the part usually left out of the calculation. Recruitment cost is easy to total and is rarely the largest number.

Rigby, Zhu, Donadelli and Mockus studied Chrome and a project at Avaya, adapting Value at Risk from financial modelling into a measure they called Knowledge at Risk. Their unit is the abandoned file: source code where every developer who worked on it has left the project. Files in that condition get maintained by people who did not write them, with the reduced productivity and higher error rate that follows.

The useful property of that measure is that it can be taken before anyone resigns. For each component, count the people still here who have changed it in the last year. One is a concentration risk. Zero means the loss already happened and nobody recorded it.

What actually leaves

The code stays and can be read. What goes 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 since dared remove.

Some of that survives if it is written at the moment of the decision. Much of it does not, because nobody knows in advance which detail will matter later. This is why documentation is a partial answer and why the research measures loss by who is still present rather than by what was recorded.

Does AI change the calculation?

It changes the first week and not the sixth month. Coding assistants trace call graphs, summarise unfamiliar modules and answer questions that previously required interrupting a colleague, which is a real reduction in onboarding friction.

They do not recover intent. An assistant will describe what a function does and cannot say why it was written that way, or what broke the last time someone simplified it. Meanwhile the volume of code that no living person authored is rising, which enlarges the surface with no owner at all.

Continuity as something a client can specify

Most of the practices that hold context are unglamorous. Measure concentration per component. 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 rejected alternatives.

Handover deserves a stricter test than it usually gets. Transferring credentials and walking through a repository establishes access. A handover is finished when the receiving engineer has made a real change and deployed it unaided.

For a client buying engineering capacity, this is all answerable in advance. Which named engineers will be on this system in twelve months. What happens when one leaves. Who else will have worked in the code by then. A supplier who cannot answer is not describing a risk they have priced.