The Senior Engineer Left. You'll Be Answering Questions About Their Services for Six Months.

The senior engineer gave four weeks notice, spent the last two weeks doing knowledge transfer — architecture walkthroughs, documentation updates, Q&A sessions with the team — and left. Three months later, a question comes up about why the payment service writes to two separate databases. Nobody on the current team knows. The documentation doesn't say. The commit that introduced the pattern is from four years ago and the message says "refactor payment persistence." The engineer who wrote it no longer works there.

Senior engineers carry institutional knowledge that is accumulated over years and is disproportionately dense compared to more recent hires. They know the history — the decisions that were made and reversed, the architectural choices that were made for reasons that are no longer obvious from the code, the workarounds that are load-bearing even though they look like they could be removed. This knowledge is valuable precisely because it's hard to reconstruct. When they leave, it leaves with them.

Why knowledge transfer doesn't fully work

The knowledge transfer process — documentation sprints, recorded walkthroughs, Q&A sessions — captures a bounded fraction of what a senior engineer knows. It captures what they know they know, and what they think is important to record. It doesn't capture what they don't realize they know — the context that feels so obvious after years of working in the system that it doesn't occur to them to document it. The workaround they implemented so long ago it feels like a feature. The incident they resolved three years back that shaped how they handle a certain class of error. The performance characteristic they discovered by feel over dozens of deployments.

This isn't a failure of effort or intent. It's the nature of expert knowledge: a significant portion of what experts know is implicit, contextual, and invisible to them until someone asks exactly the right question. Four weeks of knowledge transfer cannot surface that knowledge reliably because neither the departing engineer nor the receiving team knows exactly what questions to ask.

What leaves with a senior engineer:

  In their head (not in any document):
  -> Why the payment service uses two databases instead of one
     (migration was started in 2021, never finished, rollback was worse)
  -> The rate limiter behavior under concurrent auth requests
     (discovered via incident, workaround added, never formally documented)
  -> Which third-party webhook signatures can't be trusted
     (vendor bug, flagged, marked "won't fix", handled in code)
  -> What the "legacy_mode" flag actually does in production
     (originally for migration, now load-bearing for 3 enterprise customers)
  -> Why the queue processor sleeps 200ms between batches
     (downstream system throttles at ~5 RPS, this was empirically determined)

  In the codebase (with varying context):
  -> All of the above: the code is there
  -> None of the above: the why is not

The six-month knowledge drain

The impact of a senior engineer departure isn't immediate — it's delayed. In the first weeks after departure, the remaining team answers questions from memory. The recently-departed engineer's knowledge is still fresh in the conversations they had during knowledge transfer. As weeks become months, that freshness fades. Colleagues who absorbed some of the context remember less of it. The engineer becomes a name referenced in Slack messages asking "do we know why this was built this way?"

By six months, the knowledge gap is fully visible. Questions that used to have immediate answers now require archaeology — reading old commits, grepping for the system they owned, reconstructing context from code that was written to work, not to explain itself.

Six months after the senior engineer leaves:

  Week 1–2: Colleagues answer from memory
  Week 3–4: Answers become "I think it works like..."
  Month 2: Slack messages reference departed engineer by name
  Month 3: "Can we reach out to [engineer] at their new job?"
  Month 4: Team stops asking, starts guessing
  Month 5: Incident in payment service. Root cause traced to
           the two-database architecture no one fully understood.
  Month 6: Post-mortem notes: "institutional knowledge gap identified"

What the codebase preserves

The codebase preserves the outcomes of every decision a senior engineer made. The two-database payment architecture exists in the code and in the migration history. The rate limiter workaround is in the file where it lives. The 200ms sleep is in the queue processor, and the commit that added it has a date and a message. None of this explains itself fully — but all of it is there to be read. What the codebase needs is not more documentation; it needs to be queryable in a way that surfaces context from the code structure, the commit history, and the test suite.

Kognita makes the codebase queryable in plain language from the day after the senior engineer leaves. "Why does the payment service use two databases?" — the answer from commit history, migration files, and code structure is less complete than what the engineer would have said, but it's significantly more complete than the blank answers the team is giving six months later.

Final take

Senior engineer departures produce knowledge gaps that manifest slowly and sting eventually. The knowledge transfer process captures what the engineer knows they know. The codebase captures what they built. Reading the codebase well is the best available path to the context that the engineer no longer picks up when you call.

The senior engineer left. Their decisions are still in the codebase. The reasoning is partially gone. The code is complete. Start with the code.