When the lead developer resigns mid-project, the client's real fear is that the knowledge walks out with them. It usually does, unless continuity was being built from day one. So there are two halves to this: what I do in the forty-eight hours after the notice lands, and what I do on every project so those forty-eight hours hurt less.
What happens in the first two days?
The client hears it from the delivery lead within a day, with a plan attached: who the successor is, when they start pairing, what the departing developer will hand over, and by when. Internally, the same two days go into freezing risky work and booking the handover sessions with recordings turned on.
Never a bare "unfortunately". A client can absorb bad news with a plan attached. They cannot absorb bad news that arrives as a rumour.
I learned that the hard way. Early in my career I sat on a resignation for a week, hoping to have the replacement fully briefed before saying anything. The client found out from a LinkedIn update. Everything I said after that sounded like damage control, and it was. Now the rule is simple: the client knows before the team's own farewell lunch is booked.
What does a real handover contain?
Four things, and a document dump is not one of them. A recorded walkthrough of the ugliest code, a written list of what only that developer knows, three tickets paired with the successor driving, and a decision log that explains why the system ended up the way it is.
- Record a walkthrough of the parts the developer would be embarrassed to explain, because that is exactly where the successor will get stuck.
- Write the "things only I know" list, produced by one question: what would break if you vanished tomorrow and nobody could call you?
- Pair on the next three tickets, with the successor driving and the leaver watching.
- Hand over the decision log, so the successor knows why as well as how.
A hundred pages written in the last week by someone with one foot out of the door is a hundred pages nobody reads. The "things only I know" list is usually a single page, and it is the most valuable artefact in the whole handover.
Can continuity be built before anyone resigns?
Yes, and it costs little compared with the alternative. Two people touch every critical module, even if the second only reviews. Every pull request is read by someone who did not write it. Runbooks exist for anything that runs on a schedule. The decision log is written weekly rather than reconstructed later.
| Habit | Without it | With it |
|---|---|---|
| Second reviewer on every module | The handover starts from zero | Someone can already read the code |
| A live "things only I know" list | Written in the last panicked week | Updated while the knowledge is fresh |
| Weekly decision log | Reconstructed from memory and chat scrollback | Read in one afternoon by the successor |
| Runbooks for scheduled jobs | Discovered when a job fails at 2am | Handed over with everything else |
Those habits sound like process for its own sake until the day they save a project. They are the same habits I see in governing code rather than writing it, the idea that the value of code is in how well it survives its author, and it has only become more true now that so much code is generated fast and reviewed slowly.
How do you tell the client honestly without frightening them?
Separate the fact from the fear. The fact is that a person is leaving. The fear is that the project is now at risk. So the message answers the fear first, saying what changes this week and why, then states the fact, then the plan, then offers a call.
"Nothing about the timeline changes this week, and here is why" is the first line. Most clients relax at that sentence and read the rest as information rather than as a warning. The ones who do not relax want the successor's name and the pairing dates, which is why both are already in the message.
At Shanti Infosoft I keep a one-line rule for delivery leads on every software development engagement we run: any developer who is the only person who understands a module is a risk on the register, and it gets a date by which that stops being true.
If your lead developer handed in notice tomorrow, how many days would it take before your client noticed a difference?
Sonal Jain is the delivery lead at Shanti Infosoft, a CMMI Level 5 software company with more than 80 engineers on staff.
Top comments (0)