Thirty-one days after Priya's last day, a customer is waiting on the data that the nightly sync job has not yet delivered, and Marcus is staring at a retry delay of forty minutes, hardcoded, with no comment. Nobody on the six-person platform team knows why it is forty minutes and not five. Priya built the service. Her handoff document is open in a second tab, but it does not mention the delay.
When a key employee leaves, the team loses the documented handoff gradually. The undocumented context is lost all at once. The gap, however, does not appear in the first week. It shows up over the following months as questions nobody can answer, decisions nobody can explain, and work that gets done more than once.
Most advice for this moment is written for the manager who receives the resignation: announce it, hold the exit interview, use the notice period. Gallup puts the cost of replacing an employee at between one-half and two times the annual salary, but that figure is the company's bill. The team pays its share over the next ninety days. This post follows an engineering team through that period, though the pattern is common for most teams.
The Handoff Covers Only What Was Written Down
Priya gave her two weeks' notice, and her right away team followed the standard advice to capture a design doc for the sync service and the deploy pipeline, a forty-minute recorded walkthrough, and an updated README. By the end of week two the team felt the handoff was completed. That timing is the trouble with any knowledge transfer plan that begins at the resignation because it covers only what the leaver remembers during that time.
The design doc described what the service does. However, it did not describe why a delay was chosen, which customer integration forced a library version pin, or why the pipeline skips one staging step on purpose. Those facts felt obvious to Priya, so they never reached the documentation, which is the reason why experienced employees skip documentation. A complete-looking handoff is often risky because it tells the team that coverage exists, but nobody is aware of what is missing.
Day 30 and Day 60: The Question and the Decision Nobody Can Explain
On Day 30, Marcus asks in the team channel why the delay is forty minutes. Lena guesses it protects a partner API from overload, and two engineers agree with that guess since it sounds right. But nobody knows for certain. With the customer waiting, Marcus cuts the delay to five minutes. Within hours the partner API starts rejecting requests, and the sync stays down for a day. The team restores the forty minutes and adds a comment reading "do not change," which tells the next engineer what not to do but without any reasoning.
By Day 60, a security scan flags an old library version pinned in the same service. Lena upgrades it as routine cleanup, because the pin looks like neglect. However, it was deliberate because one customer's integration depended on the older behavior. Two weeks later that customer's import fails and support escalates, just because the reason for the pin lived in a Slack thread from the previous spring and not in the live documentation. This is the loss described in what companies lose when employees leave, arriving as an escalation, in this instance.
None of the failures was due to carelessness. Capable people acted sensibly on the information available to them, yet they resulted in failures.
Day 90: The Rework and the Message to the Former Colleague
To fix the integration, Lena rolls back the upgrade and ships a patch. A week later the scanner flags the same library and a second engineer starts the same upgrade; Lena stops it only because she remembers the escalation. Each cycle costs hours of debugging by people who don’t have the entire context. The replacement engineer starts in week ten and inherits the same unanswered questions.
Priya was one message away the whole time, and nobody sent it. She now works at another company, each question looked small until the incident that followed it, and asking felt like admitting the handoff had failed.
Marcus first searches Slack for "retry" and gets hundreds of results, which is part of the cost of searching for information at work. With Priya gone, nobody knows who else touched the service, so finding the right person to ask is guesswork too. On Day 88 he finally messages Priya on her personal account, and she answers a day later that the partner API throttles at a threshold that resets every forty minutes.
Such a message is the real handoff process in many companies. It is a favor asked of someone who no longer has any obligation to answer, and the answer lives in a private message where the next engineer cannot find it.
What Changes When the Explanation Was Already Saved
Replay Day 30 and Day 60 with one difference. Months before she resigned, Priya had answered both questions in Slack. A junior engineer asked why the sync waits forty minutes between retries, and she explained the partner API's throttling window. Support asked why an old library version was still in production, and she explained the customer integration that depended on it. In each case the person who asked saved the thread, because the answer solved their own problem and they wanted it findable. Saving took three clicks.
Pravodha keeps those threads attributed to Priya, searchable by topic, and marked as useful by the colleagues who found them valuable. On Day 30, before he touches the setting, Marcus searches "sync retry delay" and finds her explanation, with her name on it. On Day 60, Lena searches the library's name and finds the thread explaining the pin. There is no outage, no escalation, and no message to a former colleague. The recognition from teammates also shows whose explanations carry weight.
The capture does have its limits. Threads that nobody saved before the resignation are still lost, and judgment that Priya never put into words leaves with her. But the reasoning behind specific decisions, the context behind both failures here, is often said out loud at least once, in a thread, to someone who asked, so that limit is often very small.
What to Do Before the Next Resignation
Most of what a team can do to lower the cost of a departure has to happen while everyone is still reachable.
- List the open questions for each key role: the services, reports, and processes that only one person fully understands, and the decisions made about each.
- Save explanations on the day they are given, not during the last two weeks of notice.
- Ask for the settings that look wrong but are deliberate. In the notice period, have the person name every pin, exception, and workaround a newcomer would be tempted to "fix." That targets decisions that look like mistakes, which a general request to document everything tends to miss.
- Agree on who will ask the leaver questions after they go, and how often. Settling that in advance keeps the first question from waiting for an incident.
A team that knows which decisions have an explanation on record, and which do not, can ask the right questions while the person is still in the building.
Pravodha is built around the capture model. It integrates with Slack, Microsoft Teams, and your email provider to preserve the institutional knowledge your team generates every day: attributing it to the people who created it, surfacing peer validation through colleagues who recognize contributions as valuable, and making it permanently searchable without adding any burden to the experts who know the most.