The message is two sentences long and arrives on a Tuesday. The engineer who has written most of your client's system for four months is moving to another project from the fifteenth, and the partner is bringing in someone excellent. There is no apology, because from where they stand nothing has gone wrong: they allocate people, you bought capacity, and capacity is fungible. You sold a build with a date on it to a client who has been on calls with this person by name. Those two descriptions of one event are the whole problem.
Start with what you lost, because the instinct is to price it in hours and the hours are the cheap part. Four researchers formalised what agencies call bus factor: “Truck Factor (TF) is a metric proposed by the agile community as a tool to identify concentration of knowledge in software development environments. It states the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated.” They built an automated estimator, ran it across 133 popular GitHub projects, and found that “the majority of our target systems (65%) have TF <= 2” (Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente, A Novel Approach for Estimating Truck Factors, arXiv:1604.06766, accepted at the 24th International Conference on Program Comprehension, 2016). Two thirds of real systems sit one or two departures from being incapacitated — and that is the base rate where staffing was visible to measure. On a subcontracted build you did not pick the team, cannot see its distribution, and have no reason to assume yours is the exception.
And the loss persists, the finding most principals have never seen. A McGill replication study measured what happens to code whose author has gone, on a definition stricter than it sounds: a line counts as abandoned when the last developer to touch it has left, and “Rigby et al. consider a file as abandoned if at least 90% of its lines are abandoned.” Across eight large and medium open source projects, the authors report that with one exception, “at least 25% of the abandoned files persist for two years or more. For five of them, more than one half of the abandoned files persisted at least two years” (Mathieu Nassif and Martin P. Robillard, Revisiting Turnover-Induced Knowledge Loss in Software Projects, McGill University, ICSME 2017). Their framing of the cost is the one to carry into this week: “Understanding the source code written by leaving developers thus becomes a burden for their successors.” The departure is an event; the bill arrives in instalments, for years, paid by whoever maintains it.
First question, and it is about your paperwork rather than their conduct: were you entitled to be told? The control frameworks treat this as a named obligation on the supplier. NIST requires organisations to “Require external providers to notify … of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges,” and defines the category to include exactly the firm you hired: “External providers include service bureaus, contractors, and other organizations that provide system development, information technology services, testing or assessment services, outsourced applications, and network/security management” (National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5, control PS-7). The default in an agency subcontract is no such clause, so the notice you received was a courtesy and could as easily have been a commit from an unfamiliar address. Revoking what the leaver could reach has an owner — what access to give a subcontractor is that register — and approval over a replacement rather than notification of one belongs in the subcontract, signed long before this Tuesday.
Your first call is not to your client. It is to size the hole, and it takes an afternoon. Three questions, answered with evidence rather than with reassurance. Which parts of this system has only this person touched — ask for the authorship distribution by file, which is a git command rather than an opinion, and which you can read without reading the code. What decisions are in their head and not in a document. What is in flight now that no second person has reviewed. The partner will want to answer all three with a sentence about how strong the replacement is. Hold the questions open. You are not assessing their staffing; you are measuring how much of your client's system exists only as a memory belonging to someone who is leaving.
Then understand that a transition is a priced activity. The industry that writes this down plainly is the one buying from contractors at scale. Federal service contracts carry a standard clause obliging a contractor to “Furnish phase-in training” and to “Exercise its best efforts and cooperation to effect an orderly and efficient transition to a successor,” to “provide sufficient experienced personnel during the phase-in, phase-out period to ensure that the services called for by this contract are maintained at the required level of proficiency,” and to “allow as many personnel as practicable to remain on the job to help the successor maintain the continuity and consistency of the services.” It then concedes the part everyone else leaves out: the contractor “shall be reimbursed for all reasonable phase-in, phase-out costs” (Federal Acquisition Regulation, 52.237-3 Continuity of Services, Jan 1991; FAC 2026-01).
The clause governs contract expiry rather than one engineer rolling off, and the part that matters maps exactly: overlap of experienced people is the mechanism, and somebody pays for it. In a white-label build nobody has budgeted a penny, and both parties have a reason to pretend it is free — your partner because absorbing it costs margin, you because raising it invites a change order. So the handover becomes a forty-minute call with screen sharing, which is not a transition. It is a demonstration that one did not happen.
Buy the overlap, and be specific about its shape. A stated number of working days with both engineers on the work, not a meeting. The leaver moves into a reviewing role and stops writing new code on day one of it; the replacement writes and the leaver comments, the only arrangement that surfaces what the replacement has misunderstood while someone is still there to say so. And the leaver's final days go on artefacts rather than commits — a commit made on the way out is one more file with their name on it and nobody else's.
Be precise about what you ask the leaver to produce, because you cannot compel any of it. You have no employment relationship with this person and a goodwill window that closes the day they start the next thing. So ask small and ask immediately: a written map of the areas they owned, the decisions they made with the reasoning and what would justify reversing each, the things in the code that look wrong but are deliberate, and the failure modes they know about that never reached the tracker. That last item is the genuinely irrecoverable one. Everything else can be reconstructed by reading; the known-bad edge case nobody wrote down gets rediscovered by a customer.
Then the commercially important judgement: telling a real replacement from a warm body at the same rate. The honest signals are behavioural and visible inside two weeks. The partner names the individual before you ask. The person arrives with questions instead of confidence. They can describe your client's system back to you by the end of week one, including the parts they have not understood. Their first pull request is small and lands where they were briefed. The anti-signals are as legible: a CV in place of a person, a start date that quietly moves by a week, and the tell that should stop the conversation — an assurance that the replacement is more senior than the leaver, offered with no matching reduction in schedule risk. If they were genuinely better, the date would improve. If the date does not move, the seniority claim is a pricing statement.
Give the replacement two weeks to produce three things you can inspect without reading any code. A written description of the system in their own words, compared against the leaver's map. A list of what they have not understood yet — the artefact a competent engineer produces and a nervous one does not. And one non-trivial change shipped end to end, the only one of the three that proves the environment, pipeline and access work for a person they were not configured for. If week two produces velocity but not the first two, you bought hours and not continuity.
What this does to your date is not zero, and the reflex fix is the wrong one. The schedule arithmetic, the three signals that precede an admitted slip and the four honest moves are the subject of when subcontracted work is late and the client is yours, and apply here unchanged. The thing to add is about risk rather than duration. Whatever contingency you held was sized for a team you had observed for four months. A mid-build replacement converts a known team into a partly unknown one, so the reserve that was adequate on Monday is not adequate on Wednesday — and the right response is to widen it quietly on your own plan, not to re-quote the date twice.
Now the question you have been putting off: do you tell your client? This is narrower than whether to disclose that a partner exists at all, which who your client trusts when you subcontract settles. The test is not whether you are obliged to. It is whether your client learning this in three months would change how they read everything you said in between. If the date holds, the scope holds and they never met this person, it is an internal staffing event — firms do not announce their own reassignments either. If they had met them by name, or the date moves at all, silence is not discretion; it is a fact you have chosen to have discovered later, by someone who will then wonder what else was handled this way.
The structural fix costs margin and there is no version that does not. A second reader on everything that carries money, design documents written before the code and living in your repository, one of your own engineers on the build even when they are the slowest person on it. Each makes the next departure an inconvenience rather than an event, and each is a line somebody has to approve. Long engagements are where it compounds hardest, which is why the platform consolidation we ran for Cove was structured as continuous delivery across twenty-four months rather than one long promise — a shape that survives turnover only because no quarter of it depends on a single memory. Where the boundary is real, a scoped sprint gives you the same property by ending.
The test is one question, better asked at kickoff than in the week you need the answer. If the most productive person on this build vanished tomorrow, how long would it take you to find out which parts of the system had just become unreadable? A partner who can answer that from their own records on the day you ask is running a team. One who has to go and look has a truck factor they have never measured, and you are carrying it. That is fair to ask of any white label software development partner while nothing is wrong — and the answer that should worry you is not a low number. It is the firm that has never considered the question, which is most of them.
Find this useful? Tell Google to show you more of it.