The Engineer Who Left a Year of Bug Fixes Behind

What you actually need to know

• When an engineer leaves, the visible cost is the salary gap. The invisible cost is twelve months of learned behavior and silent bug workarounds that disappear with them.
• Most startup codebases have three to five systems that only one person truly understands. That person's departure is a latent incident.
• Documentation culture is not a bureaucracy tax. It is an insurance policy that most teams only wish they had paid after the resignation email arrives.
• The bugs an engineer tolerated silently are often more dangerous than the ones they reported. Someone else will rediscover them the hard way.
• Bus factor is not a hypothetical. It is a countdown clock that resets only when knowledge is transferred, not when a replacement is hired.

Departure Scenario	Knowledge Transfer	Recovery Time	Cost to Team
Planned exit, 4 week notice, runbooks written	High	4 to 8 weeks	Low
Planned exit, 2 week notice, minimal docs	Medium	3 to 6 months	Medium
Sudden exit, no notice, no docs	None	6 to 18 months	High
Exit after burnout, docs exist but outdated	Low	4 to 10 months	High

The core argument

I have seen this happen more than once. The senior engineer who held everything together gives two weeks notice. The team is surprised, even though the signs were there. And then the first Monday without them, something breaks. Not a new bug. An old bug. One they had been quietly patching for nine months with a cron job that ran at 3am and nobody else knew about.

The postmortem is almost always the same. The engineer was carrying institutional knowledge the same way they carried their laptop home every night. It went with them. The codebase was technically intact. The readme was technically accurate. But the layer of operational reality that kept things running lived entirely in one person's muscle memory.

The problem is not the individual engineer. It is the system that allowed that concentration to happen. Startups reward moving fast. They reward the person who knows the codebase cold and can ship without asking questions. They do not reward the person who writes down what they know, because that takes time and does not ship features. So knowledge accumulates in heads, not in files. And every departure is a partial data loss event.

What gets lost is specific and predictable. The fix for the race condition that only appeared under high load. The database index that was added by hand on the production replica after a query performance emergency. The third party API that requires a specific header that is not in the official docs and was discovered after three hours on a support call. None of this is in the codebase. None of it surfaces until the new engineer runs into the same wall.

The knowledge that never made it into the codebase

There are three categories of knowledge that departing engineers leave behind in their heads.

Tolerances

The bugs the team decided to live with. Every team has them. A memory leak that is small enough that a nightly restart covers it. A queue that backs up on Mondays because of a batch job but drains by noon. A validation rule that has a known edge case that affects zero point one percent of users and was triaged as acceptable. The departing engineer knew about all of these. They watched for them. The new engineer will discover them through production incidents instead.

Tribal fixes

The fixes that were applied without a ticket, without a PR, sometimes directly on the server. The configuration change that was never committed. The environment variable that was added six months ago to unblock a deploy and nobody has questioned since. The workaround in the deployment script that was added after a failed migration and is now something the whole deploy depends on. These are the landmines. The new team finds them by stepping on them.

Vendor relationships

Every startup has at least one vendor or third party integration with a quirk that required a support conversation to resolve. The departing engineer knows the right contact at that vendor, the undocumented parameter that prevents the timeout, and the retry logic that only works in a specific configuration. That knowledge does not transfer through an API reference. It transfers through pairing, through notes, through a deliberate handoff conversation that most teams never make time for.

What it requires

The fix is not documentation for its own sake. It is a specific, consistent practice that makes knowledge transfer a routine event rather than a scramble right before someone leaves.

Practice	Time Investment	Knowledge Protected	Difficulty
Postmortem notes on every fix	15 min per fix	Specific bug context	Low
Monthly knowledge audit	4 hours quarterly	Single points of failure	Medium
Pair rotation on critical systems	2 hours monthly	Operational knowledge	Medium
Runbooks for every on call scenario	1 to 2 days upfront	Recovery procedures	High
Architecture decision records	30 min per decision	Design rationale	Low

What to look for before it is too late

• Engineers who say "I am the only one who knows this" as if it is a badge. It is a warning.
• Systems that have never been deployed by more than one engineer.
• On call rotation where one person handles every real incident because they are the only one who can.
• Bug tickets that stay open because "only person X can look at this."
• Cron jobs, scripts, or manual procedures that are not in version control.
• Vendors whose support contact is stored in one person's email and nowhere else.

Expert opinion

The engineer who leaves a year of bug fixes behind is not a bad engineer. They are a symptom of a team that never built the habit of asking: what happens if this person is gone tomorrow? I have done knowledge audits on teams where the senior engineer had been carrying three critical single points of failure for over a year, and nobody had noticed because the system was working. It works until it does not. The time to find out is not during an incident. It is during a calm Tuesday afternoon when the engineer is still in the building and has thirty minutes to talk through what they know.

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

I worked with a B2B SaaS team that lost their backend lead after he accepted an offer elsewhere. Two weeks notice, professional departure, no drama. The team thought the transition would be smooth because the codebase had good test coverage and clear PR history. What they had not accounted for was that the backend lead had been silently managing a data consistency issue in their billing pipeline for eight months. He had a personal Slack reminder to run a reconciliation script every two weeks. When he left, the reminder left with him.

The billing inconsistency surfaced six weeks after his departure when a customer noticed a double charge. The investigation took four days. They eventually found the script in a personal folder in the repository that had never been part of the deployment or the on call documentation. The fix was straightforward once discovered. The four days of investigation were the real cost.

The postmortem from that incident is what prompted the team to build a proper knowledge transfer protocol, including a departure checklist for engineers that covered tolerances, tribal fixes, and vendor contacts. They also ran a retroactive on call runbook exercise where every engineer documented the three systems they would least want to hand off. That exercise found two more single points of failure, neither of which had been on anyone's radar.

Common mistakes

1. Treating documentation as a departure activity rather than a continuous one. By the time the resignation email arrives, it is too late to write down a year of institutional knowledge in two weeks.
2. Confusing code comments with operational knowledge. Comments explain what the code does. They rarely explain why a specific workaround was necessary or what the system looks like when it is failing.
3. Assuming test coverage equals knowledge transfer. Tests verify behavior. They do not document tolerances, vendor quirks, or manual recovery procedures.
4. Skipping the knowledge audit because the team is small. Small teams often have higher bus factor concentration, not lower, because there are fewer people to share the load.
5. Not running new engineers through the on call rotation before a departure. An engineer who has never been on call for a system is not ready to own it.
6. Treating the departing engineer as already gone during the notice period. The two weeks of notice is the most valuable documentation time the team will ever get. Use it deliberately.
7. Storing operational knowledge in personal inboxes, personal Slack reminders, or personal folders. Anything that cannot be found without the person who created it does not exist as institutional knowledge.
8. Not doing a retrospective after the departure. Six weeks after the engineer leaves, the team knows exactly what was not documented. That knowledge should inform the process for next time.

A thirty day plan

1. Schedule a knowledge audit this week. Ask every engineer on the team to spend one hour writing down the three things they know that nobody else does. Do not frame it as distrust. Frame it as resilience.
2. Review the cron jobs, scheduled tasks, and manual scripts in the codebase. For each one, confirm there is a runbook that a different engineer could follow without help.
3. Identify the three systems with the highest bus factor. For each one, schedule a one hour pairing session where the primary engineer walks a secondary engineer through normal operation and failure modes.
4. Build a departure checklist and store it in the team wiki. Include sections for tolerances, tribal fixes, vendor contacts, and manual procedures. Test it on the next voluntary departure.
5. Set a quarterly calendar reminder for a knowledge audit refresh. The first audit finds the worst concentrations. The quarterly review keeps them from rebuilding.
6. Review the tech debt audit process alongside the knowledge audit. Technical debt and knowledge debt accumulate together and should be addressed together. The combination gives the clearest picture of real organizational risk.
7. If you are a founder or lead, build documentation into the definition of done for bug fixes, not just features. A fix without a note is half a fix. The postmortem culture that improves security applies equally to ordinary bugs.

FAQ

Frequently asked

• What happens to a codebase when a key engineer leaves without documentation?
• How do I reduce bus factor risk in a small engineering team?
• What should a departing engineer document before they leave?
• How long does it take to recover from the loss of a key engineer?
• Is it the engineer's fault when they leave without documenting?
• What is a knowledge audit and should my team do one?
• How do you prevent the same bugs from resurfacing after an engineer leaves?

Author

Why Yashveer Singh is the call for this work

I have spent the last four years writing software that runs in production. Three live client sites. A Roblox game with real players. Nexli, a school management system about to launch into private testing. Nyxera, a fully local AI assistant. I write about this from inside the codebase, not from summarizing someone else's. If you want this kind of work done right, I am the person you call. Yashveer Singh, founder of Yashveer Labs.

Start the conversation See the work DM on Instagram