Guide
What to do when a key engineer leaves
By Campion Fellin · Published · Updated
A key engineer just left. How do we keep things running?
First, protect what is running: make sure someone else can deploy, has access to every system, and knows what to do if production breaks. Then capture what the engineer knew while you still can, through a handover if they are still around, and by reading the code, configuration, and history if they are not. Don’t rush to rewrite their work. If nobody left on the team can own it soon, bring in a senior engineer for a while to stabilize and document the systems while you hire.
The first week
- Confirm someone else has working access to every system, cloud account, domain, and vendor the engineer used.
- Make sure someone else can deploy, and has done it at least once.
- Decide who responds if production breaks, and give them the access to do it.
- List every system, script, and scheduled job the engineer owned, even the small ones.
- Rotate any credentials that only the engineer held.
If they are still working their notice
Use the time for a structured handover. Ask them to walk someone through:
- What breaks most often, and how they fix it.
- Anything that runs on a schedule or depends on a personal account.
- Decisions that look strange but were made on purpose, and why.
- Work that is half finished, and what was left to do.
If they have already gone
Reconstruct what they knew from what they left behind: the code and its commit history, deployment and infrastructure configuration, logs, tickets, chat threads, and the colleagues who worked with them. Write it down as you go. It is slower than a handover, but it is usually possible.
Don’t rush a rewrite
Unfamiliar code often looks worse than it is. Rewriting it before you understand it throws away fixes for problems you have not seen yet. Stabilize and document first; decide what to replace once someone understands how it works.
Preventing the next one
- Make sure at least two people can work on each important system.
- Keep credentials in a shared password manager, not in one person’s accounts.
- Write short runbooks for deploying, recovering, and the most common failures.
- Record important decisions and their reasons where the whole team can find them.
Frequently asked questions
How long until a new hire can take over?
It depends on how complex the systems are and how well they are documented. Plan for a ramp-up period rather than expecting the next hire to take over on day one, and arrange interim cover for anything critical.
When should we bring in outside help?
When nobody on the team can confidently deploy, fix, or explain the systems the engineer owned, or when the remaining team is too busy to reconstruct what was lost. A senior engineer can stabilize things, write it down, and hand it to your next hire.