The Offboarding Checklist That Saves the Codebase

TL;DR: HR's offboarding checklist protects the company from the person: revoke access, collect the laptop, sign the forms. Nobody's checklist protects the codebase from the departure, so ownership evaporates, cron jobs die under a disabled account, and the knowledge walks. The engineering checklist runs five tracks from the day notice is given: map real ownership from git, inventory every personal-identity dependency, reassign formally, transfer knowledge by blast radius, then watch the orphaned areas for a quarter.

HR has an offboarding checklist, and it's good at its job: access revoked, laptop returned, payroll stopped, forms signed. Its job is protecting the company from the person. Nobody in that process is protecting the codebase from the departure, and those are different problems. The first is solved with a ticket to IT. The second is the one where, three weeks later, a cron job silently dies because it ran under a disabled account, and nobody knows which of the four orphaned services pages next.

This is the second checklist - the engineering one. Run it alongside HR's, starting the day notice is given.

Track 1: Map what they actually owned (Day 1)

Skip the org-chart version and pull the git version. From the last 12 months of history, list every area where the leaver authored or reviewed most of the meaningful changes, weighted the same way you'd weight a bus-factor calculation, by authorship and review rather than raw commit counts. Seniors especially own through review - context on code they never typed.

Then add what git can't show: the operational layer. Which deploys, migrations, vendor relationships, and incident types always routed to them? Ask the team "what would you have asked them next?", not just the leaver, whose map of their own indispensability is usually too modest.

The stakes of this map are not hypothetical. Avelino et al. (2016) found 34% of 133 popular GitHub systems had a truck factor of exactly 1 - one departure away from orphaned code. If any of the leaver's areas were single-owned, this map is the list of your codebase's newest orphans. Rank it by blast radius: what stalls if this goes dark, and how soon? That ranking budgets everything below.

Track 2: Inventory the personal-identity dependencies (Days 1-3)

The post-departure failure that hits first is rarely the lost knowledge. It's the automation nobody knew ran as the person:

• Personal API tokens in CI secrets, deploy pipelines, and integrations.
• Cron jobs and scheduled scripts running under their user on some box.
• Vendor accounts where they're the admin or the billing contact: the analytics login, the DNS registrar, the error tracker.
• Bot accounts they created and are the sole owner of.
• OAuth grants connecting third-party services through their identity.

Search for their username and email across CI configs, infrastructure code, and vendor admin panels before the account is disabled. Every hit gets migrated to a service account, which is where these should have lived all along. The system that let load-bearing automation accumulate under one person's login is the same system that concentrates knowledge in one head; the departure is just the audit you never scheduled.

Track 3: Reassign in writing (Week 1)

Ownership that isn't reassigned doesn't distribute - it evaporates. For every area on the Track-1 map, name a successor in writing:

• CODEOWNERS and review assignments updated the week notice is given, before the farewell lunch. Put the successor on every PR in the area now, with the leaver as second reviewer while that's still possible. Review is one of the strongest transfer channels a team has: Bacchelli and Bird's Microsoft study found review's actual outcomes lean toward knowledge transfer and team awareness, beyond the defect-finding everyone cites.
• On-call rotations and recurring duties - the weekly data fix, the monthly cert check - explicitly moved, with the successor running one cycle while the leaver watches.
• Unowned-by-decision: write down what you're consciously not reassigning. An honest short list beats a complete fiction that reassigns everything to nobody.

If a successor is inheriting an area cold, treat it as onboarding, because it is one.

Track 4: Transfer knowledge by blast radius (the notice period)

This track deserves its own article, and it has one: Your Senior Engineer Quit. Now What? covers the deep knowledge-transfer plan: pairing on live tickets in the critical areas, the recorded "why" walkthrough, runbooks for operational duties only. This checklist's contribution is the budget discipline: the notice period is a fixed, non-renewable resource, and Tracks 1-3 tell you where to spend it. Hot-and-critical areas get live pairing. Critical-but-dormant areas get runbooks, and everything else gets explicitly accepted as a loss. The worst spend is the default one - the leaver alone at a desk, writing documentation nobody will read.

Track 5: Watch the orphaned areas (the next quarter)

After the goodbye, the gap shows up in the work. Watch the Track-1 areas for the telltales: PRs idling because nobody feels qualified to approve, and questions going unanswered in chat. Developers already spend serious time hunting for answers - 61% report more than 30 minutes a day in the 2024 Stack Overflow survey

• and that cost spikes locally in areas that just lost their index. The spike marks where the transfer didn't take; route follow-up pairing there.

The real fix is not needing the checklist

A departure that triggers a five-track scramble is a symptom: the org discovered its ownership map only when a resignation rendered it. The teams that offboard calmly knew their single-owned areas all along. They run succession planning for engineers so every critical area already has a named, warmed-up second, and they watch for the legacy system with one living interpreter before it becomes one. That map is computable from the git history you already have, continuously rather than only in the week someone quits.

Run the checklist this time. Then build the version of your org where it's boring.