Knowledge Loss When an Engineer Leaves: What to Capture

When an engineer leaves, the code and the tickets stay, but the reasoning leaves with them: why systems are built the way they are, what was tried and failed, which odd behavior is expected, and who outside the team to call. Knowledge continuity means getting that reasoning written down while the person is still around, so the team can keep going without them.

Most teams discover the gap on the engineer's last day, or the first week after, when a question comes up that only they could answer. By then, recovering the answer takes hours of reading old threads, or it cannot be recovered at all.

What institutional knowledge is

Institutional knowledge is the shared understanding of how a company works and why, built up over time by the people in it. Some of it is written down in docs, runbooks and code comments. Most of it is not. It lives in people's heads as habits, shortcuts, history and relationships.

Tribal knowledge is the same thing at team level: what "everyone knows" on a team, which a new hire learns only by asking the right person. Both are valuable, and both are fragile, because they depend on specific people being around.

What leaves when a key engineer leaves

• The reasons behind past decisions, such as why the service uses this database or why that retry limit is set so low.
• The history of incidents, and which fixes were permanent and which were patches.
• The map of who to ask outside the team: the vendor contact, the person in finance who approves the bill.
• Knowledge of what looks broken but is fine, and what looks fine but is fragile.
• Half-finished work and the plan in their head for finishing it.

The cost depends on how much of this was written down. To put a rough number on it for your team, try the knowledge loss calculator.

How to tell if your team has a knowledge continuity problem

• One or two people get asked about everything, and they are the ones who can never take a full holiday.
• New hires take months to work alone on core systems.
• Old decisions get re-argued because nobody remembers the reasons.
• Every incident in a certain area waits for the same engineer.

The first sign is the most important. A person everyone depends on is a key person dependency. See the guide to key person dependency for how to find and reduce it.

Knowledge transfer before someone leaves is usually too late

The standard response to a resignation is a frantic knowledge transfer during the notice period. It helps, but it is late. The leaving engineer is busy finishing work, the team does not yet know which questions it will need answered, and most of the reasoning is years old and half-forgotten.

The better fix starts long before anyone resigns: write decisions and their reasons down as they are made. A team that keeps a decision log has most of its reasoning written before anyone leaves. A team that writes good handoffs every day, using a format like the engineering handoff template, has the state of the work written too.

A two-week knowledge transfer plan

When someone does leave, use their notice period in this order.

Days 1 to 2, list. The leaving engineer lists their systems, open work, recurring tasks and outside contacts. The manager adds the questions the team will need answered.

Days 3 to 6, record. For each system, the engineer writes a short note: what it does, how it fails, what is fragile, and the main decisions behind it, with reasons.

Days 7 to 10, pair. The new owner does the work while the leaving engineer watches and answers questions. Every answer that was not in the notes gets added to them.

Days 11 to 12, hand over. Open work moves to new owners, with the state of each item written down, in the same format as a handover document before leave. Outside contacts are introduced by name.

Days 13 to 14, check. The new owners list what they still do not know, and the leaving engineer answers it in writing.

How AI can help with knowledge continuity

AI can make written knowledge easier to find and ask about. It can search across docs, tickets and threads, and answer questions from what people wrote, with the source. What it cannot do is recover reasoning nobody wrote down. An AI tool that guesses at why a decision was made is worse than one that says it does not know, because the guess sounds like history. Use AI to make the written record more useful, and keep writing the record.

Where StandIn fits

StandIn is a personal knowledge base, built on the work that you already do, that answers your teammates when you're away, in chat and email. Each brief adds to a written record of what people did and decided, in their own words, so less of the team's knowledge lives only in someone's head. When the answer is not in the record, StandIn never guesses: it says so and points to the person who knows. For the wider picture of covering work when people are away, see the guide to covering for a teammate on leave, and see how StandIn works for engineering teams.