If your key engineer resigned, spend the first 48 hours on access and on the cover decision, not on documents. Lock down the accounts only they control, list what only they know, and pick your backfill route that same week, so a successor or interim engineer is working next to them before the last day. This plan assumes a 30-day notice, which mitstech describes as often the case, though it says some notice periods run to 60 or 90 days. It's written for a CTO or VP Engineering at a team small enough that the leaver is a real single point of failure. For the wider set of guides, see Startup CTO guides: leadership, diligence and the first hires.
What you need before day 1
One person who owns the plan. That's you or a named senior engineer, not "the team". Without an owner, the plan becomes a shared document nobody finishes.
You also need admin-level access to the places the leaver's work lives: source control, cloud console, CI, the secrets manager, the DNS registrar, monitoring and the ticket tracker. If you can't list who holds admin on each, step 1 is your first job, and you've learned something about your bus factor.
If the engineer is leaving today with no notice, do steps 1 and 2 in the next few hours, then jump to step 3. Pairing and teach-back shrink to whatever the remaining team can reconstruct from code, logs and the leaver's last pull requests. The cover decision matters more here, not less.
How to run the 30-day plan
1. Secure access and single points of failure (days 1-2)
List every account, credential and service that is registered to the leaver personally or that only they can administer: cloud root or owner roles, domain registrar, app store developer accounts, CI secrets, payment methods on vendor accounts, on-call tools. Move ownership to a company role or a second admin, and rotate shared credentials on the leaver's last day rather than today, so the handover isn't blocked.
Do this before the departure is announced widely. The aim isn't distrust. Accounts under a personal login are a risk whenever anyone leaves, and mitstech makes the same point about removing single points of failure in the first days. Deliverable: a one-page access register with a current owner and a backup owner for each item.
2. Inventory what only they know (days 1-3)
Sit with the leaver for an hour and walk through four lists: systems they own, jobs and crons that run unattended, vendor and customer contacts, and the unwritten rules ("never deploy that service on a Friday, the migration locks the table"). pdpspectra's protocol starts with an inventory in week one, and that order is right.
Then score each item for how many other people could handle it today: zero, one or several. The zeros are your plan. Deliverable: a single table with the item, the current expert, the backup (often blank) and a due date to fix it.
3. Decide the backfill route the same week
There are three routes, and each starts the clock at a different time.
- Promote someone internally. Fast to start, but it opens a second gap in the role they leave, and the person still has to learn the departing engineer's systems.
- Hire permanently. The right long-term answer for a role you understand, but a search that starts now is unlikely to finish within a 30-day notice, so plan for a gap.
- Bring in interim senior cover. A contractor can start while the leaver is still in the building, and the permanent search runs in parallel.
In our judgment, the mistake is treating this as a choice between hiring and not hiring. The real question is whether anyone senior will be next to the leaver during notice. If the honest answer is no, you need interim cover, and you need to request it in week 1. If the leaver is your CTO, the problem is leadership rather than code, and that's a different decision from this one.
BlueOptima titles its report "8 Months: The Real Cost of Replacing Software Developers", but the page shows no method or sample, so we don't use the number. Plan from your own last hire: how long from opening the role to a first merged change?
Deliverable: a written decision with a start date for whoever takes over the work.
4. Start interim cover in week 1 for overlap
Overlap is what interim cover buys you. An engineer who arrives in week 1 can sit in the pairing sessions, read the runbooks as they're written and ask the leaver the questions you wouldn't think to ask. One who arrives after the last day inherits a codebase and a Slack archive.
Give the interim engineer a defined scope: the specific systems from the zero-backup list in step 2. Treat their first week as onboarding on those systems, with access from your register in step 1. Deliverable: a named person with a start date before day 7.
5. Pair on real work (days 4-21)
In our judgment, documents written in a leaver's last week tend to be thin. Real tasks surface the missing parts. Give the successor, or the interim engineer, actual tickets in the leaver's area. In the first week the leaver drives and the successor watches. By the second week they swap: the successor drives, the leaver comments.
Keep sessions short, 60-90 minutes, and record them if the team is comfortable with it. Deliverable: a list of tasks completed by the successor with the leaver as reviewer only.
6. Write and test runbooks, ADRs and the on-call guide (days 7-21)
Capture the decisions that explain why the system looks the way it does as short architecture decision records, and write a runbook for each recurring job and each alert the leaver usually handled.
A runbook isn't finished until someone who has never done the task follows it cold and gets the result. That person finds the missing step on day 14 instead of at 3am in month two. Deliverable: runbooks for every zero-backup item, each tested by a person other than the author.
7. Run a teach-back and a no-leaver drill (days 21-27)
The exit test is whether the successor can explain the system back, ship a small change and run a production deploy without the leaver's help. Existing docs don't prove that. Schedule it for days 21-27 and make the leaver unavailable for the drill, even if they're sitting two desks away.
Anything the successor gets stuck on goes back into a runbook the same day. Deliverable: one change shipped and one deploy run end to end, with the leaver watching silently or not at all.
8. Close out (days 28-30)
Re-run the access register from step 1 and remove the leaver's remaining permissions on their last day. Ask whether they'd stay reachable as a paid consultant for a few hours a month, which can cost less than an incident nobody can explain. Then decide on the permanent search with what the plan taught you about the role: what the work really is, what level it needs, and whether the interim engineer should stay on.
If the leaver is a contractor, the plan is the same. The guide to replacing an underperforming augmented developer has a replacement handover step covering overlap days and access close-out.
How do you find your bus factor before someone resigns?
The bus factor is the number of people who would have to leave before a system can't be run or changed. A bus factor of one means a single person holds the knowledge. The idea gets attention: a Hacker News thread titled "Vibe coding creates a bus factor of zero" reached 223 points in August 2025.
A 10-person check takes an afternoon. List your systems on one axis and the engineers on the other, then mark who could fix an incident in each system without help. Any row with one mark is a bus factor of one. Fix the rows with the highest customer impact first, using the same pairing and runbook steps above.
Resignations rarely come from nowhere. Our judgment is that regular skip-level meetings can surface unhappiness earlier than a direct-manager one-to-one, because some people say more to a manager's manager.
What this means for your backfill decision
You're deciding two things: whether to cover the gap with interim senior capacity, and when it starts. The rest of the plan runs either way.
Our judgment is to start the overlap while the leaver is still present. Interim cover that begins in week 1 can learn from the person who built the system. Cover that begins in month 3 learns from a stale wiki. Then choose the permanent hire after the plan has shown what the role really needs, not before.
On cost, the model matters more than the day rate. A contractor with no minimum hour commitment and no recruitment fee lets you scale cover down once the successor is ready, and a permanent-hire option, if you want it later, should be priced up front. If this needs sign-off, the business case for a senior hire compares in-house, contractor and nearshore routes by cost, time to start and exit, and you can adapt its table to show interim cover next to a permanent hire.
Hiring interim senior cover through HighCircl
If you need a senior engineer next to the leaver, HighCircl matches senior engineers from a vetted shortlist within 72 hours, with 3 to 5 candidates. There's no minimum hour commitment and no recruitment fee. HighCircl applies a transparent margin of 20%, capped, on top of what the engineer earns, and a deposit of one month's estimated cost is applied to the first invoice. If the engagement isn't working, there's a replacement guarantee at no additional recruitment cost. A later permanent hire carries an 18% buyout of annual gross. Engineers are based in seven European countries: Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain.
FAQ
How do you prepare a knowledge transfer plan for a departing engineer?
Start with access, then an inventory of what only they know, then pairing on real tasks, then tested runbooks, then a teach-back where the successor ships without them. Put dates on each stage and one deliverable per stage. The 30-day plan above is one way to lay it out.
What should you do when a good employee quits?
Within 48 hours, secure the accounts only they control and list what only they know. In the same week, decide who covers the work and when they start. A counter-offer is a separate decision, and whatever you decide, running the access and inventory steps costs little and protects you either way.
What is the bus factor of 1?
It means one person holds knowledge or access that nobody else has, so losing them stops or slows the work. You find it by mapping systems against the engineers who can fix each one unaided. Any system with a single name against it is a bus factor of one.
How long should a developer handover take?
It depends on the notice period and how much the person owns. Over a 30-day notice, the plan above puts access and inventory in the first three days, pairing and runbooks in weeks 1 to 3, and the teach-back in the final week. With a shorter notice, cut the documentation first and keep the pairing and the drill, and get interim cover started immediately.
Should you ask the leaver to stay on as a consultant?
Often yes, for a small number of hours a month for a defined period, agreed before their last day. It gives your successor a person to ask without keeping the leaver in the daily loop. Agree the scope and rate at close-out, not after the first emergency.