A key team member resigns in the middle of a release. What do you do?

What the interviewer is really testing

• Risk management. Do you act on the risk the same day, or wait for it to hit?
• Calm under pressure. Do you protect the release and the client, without panic?
• Prevention. Did you allow a single point of failure in the first place? This is the one most candidates miss.

The weak answer vs the strong answer

Here's the answer most candidates give: "I'll ask HR for a replacement as soon as possible."

Hiring takes weeks, and a new person needs weeks more to learn the system. That answer solves next quarter's problem, not this release.

The 5-step answer

1. Plan the notice period. On day one, list the critical knowledge only this person holds: the modules, the integrations, the open defects, the environment set-ups. Then schedule handover sessions against that list, highest risk first.
2. Pair a backup immediately. Not next week. Today. The backup sits with them, works on their tickets with them, and gradually takes the lead while the expert is still there to help.
3. Capture the knowledge. Recorded walkthroughs, design notes, code comments, runbooks. If it only lives in one person's head, it leaves with them.
4. Re-plan and tell the client early. Re-check the plan with the reduced capacity. If there is any impact on the date or the scope, the client hears it from you now, with options, not three days before go-live.
5. Fix the root cause. After the release, cross-train and rotate people, so no single person is ever a bottleneck again.

A real example

Here's a real example. I'll keep the client anonymous.

On a US healthcare program, our integration lead resigned four weeks before a major release. They were the only person who knew the claims interface to the vendor system.

The same day, we listed everything they owned, about fifteen items, and ranked them by risk. We paired a senior developer with them full time and recorded every handover session.

I told the client that week: the date was safe, but two low-priority items would move to the next drop. They appreciated hearing it early.

The result: the release went live on time, with no critical defects, and the backup became the new owner of the interface.

After that, we made pairing on every critical module standard practice on the account.