Two weeks' notice sounds generous until you work out what it has to cover.
Somewhere in the first hour after reading that polite resignation email, the founder or engineering lead has the same quiet realisation... nobody else here knows how to deploy our own product.
The passwords are mostly findable. What isn't written down anywhere is the order you do things in, which of the overnight warnings actually mean something, and which jobs are safe to run twice.
One person knew all of that, and in fourteen working days nobody will.
By the end of this you will have nine questions that measure your exposure, none of which need you to be technical. You will also know how to spend the notice period so the knowledge stays behind even when the person doesn't.
The instinct is to treat this as a hiring problem and open a job posting. You should probably hire eventually. But a job posting does nothing about the two weeks you are standing in right now.
It isn't the work that leaves, it's the reasoning
Think about a muted alarm. Somewhere in the monitoring setup, a warning that used to send a message at night has been switched off. The person who switched it off knew exactly why. It fired every time a nightly job ran, it never once meant anything, and they got tired of it. That reason lives in one head.
The hands-on work is replaceable. Deploys, upgrades, the occasional 2 AM recovery... you can hire those skills again. What you can't hire back is the thinking behind the setup you already have.
Why the database runs on that size of machine. Why staging, the practice copy of your system, drifted away from the real one, and which of the two is now correct. Why the backup schedule skips a day. Each of those was a decision, made for a reason, usually in a hurry, and almost never written down.
This is the part that catches people out. Losing the reasoning doesn't hurt straight away, since systems happily run for weeks with nobody touching them. It hurts the first time something needs a judgement call. By then the person who made every previous call is gone, and a newcomer is poking at live production with no record of what was already tried and rejected.
If this is your situation, you are in ordinary company, and it doesn't mean anyone did a bad job. Researchers have put a number on it using what they call the "truck factor": how many people would have to walk out before a project stalls. They worked it out for 133 well-known open-source projects, and for most of them the answer was very small.
Roughly a third of those projects would stall if a single person left. Your infrastructure team of one is in that bucket by definition.
Nine questions that measure what you're about to lose
You do not need to understand the technology to run this audit. You need to ask nine questions while the engineer is still on the payroll, and be strict about what counts as an answer.
"They'd figure it out" is not an answer. "It's in the wiki" only counts if you have watched somebody else follow that wiki successfully, start to finish.
| Question | A weak answer | Why it matters |
|---|---|---|
| Has someone else deployed to production, start to finish, without help? | "It's mostly automated." | If nobody has, you can't ship a fix during an outage. |
| Has anyone else restored from a backup? | "Backups run nightly." | A backup nobody has restored is an assumption. |
| Who gets woken at 3 AM after their last day? | "It goes to their phone." | An alert with no owner means a customer tells you first. |
| Who holds the login for every third-party service? | "It's in their password manager." | Personal vaults leave with the person, along with renewal dates. |
| Could you rebuild production from code if the account were lost? | "Most of it is scripted." | The unscripted part is what only they remember. |
| Why is each muted alarm muted? | "They were noisy." | A muted alarm is a decision. Without the reason it's a disabled smoke detector. |
| Which background jobs are safe to re-run? | "I'd have to ask." | This is how customers get charged or emailed twice. |
| Is there a record of recent incidents and their fixes? | "We discussed it at standup." | Unwritten incidents get solved from scratch every time. |
| Who decides, after they leave, whether a change is safe? | Silence. | Everything above is evidence for this one. |
Count the weak answers. One or two, and you have a handover to do. If it's most of them, what you really have is an undocumented production environment that happened to come with a caretaker.
The last row is not like the others. Eight of these questions are about capability. The ninth is about authority, and hiring does not settle it.
Someone has to own production, meaning someone who can say "not today" about a release and be trusted when they say it. Pick that person before the engineer leaves, even if it's an interim arrangement with one of your backend developers, and tell the team who it is.
How to spend the notice period
Most notice periods produce a handover document. It will be neatly organised and mostly unhelpful.
That isn't laziness. People write down what they imagine a reader needs, not what they actually do, and nobody can document a step they stopped noticing years ago. It's the same reason a good cook writing a recipe forgets to mention they always let the pan heat first.
So spend the time watching and recording instead of commissioning a document. In rough priority order, since you probably won't get through all of it:
Have a second person deploy. First the engineer deploys while somebody records the screen and they talk through what they're doing. Then the second person does it alone while the engineer sits back with their hands off the keyboard. Every question that comes up during that second run is a hole in your documentation.
Go through the silenced alarms one at a time. Your monitoring tool keeps a list of alarms whose notifications have been switched off, and for each one you also want to know where the message would have gone. If it would have landed in a personal inbox or on a personal phone, that needs a new destination. For each silenced alarm, write down what used to set it off, why someone turned it off, and what ought to happen instead. AWS's own notes on alarm actions explain where those notifications are routed.
Restore a backup, for real. Take a database snapshot, which is a point-in-time copy of your data, and restore it into a throwaway environment. Have somebody who is staying do it, and time it with a stopwatch. AWS Backup restore testing can then run that drill on a schedule and report whether it worked and how long it took. The number you want is how long it takes you to get back, measured once while it's calm.
Ask why each piece is set up the way it is. Walk the main components and ask the question for each one, and write the answers down in their own words. Some will be sound engineering. Some will be historical accident. You cannot safely change either until you know which is which.
Get the hand-built parts into code. Anything someone clicked together by hand in a web console can be captured as a file you keep in version control, using the CloudFormation IaC generator or Terraform's import blocks. Do it while there is still somebody around to explain what it's for.
Move logins and contact details to the company. People should sign in through a company directory such as IAM Identity Center, not through accounts tied to individuals. Passwords your applications need belong in a vault built for the job, like Secrets Manager. The master account's email address, and the phone or key that approves a login to it, must belong to the company rather than a person. Point the alternate contacts for billing, operations and security at somebody who is staying, then do the same across the domain registrar, DNS, the CDN and every tool with a company card on file.
Ask what worries them. In the last few days, ask straight out: what would you be nervous about if you were me? What have you been meaning to fix? What would be hardest to deal with if it broke tonight? People are unusually generous in their final week, and hardly anyone thinks to ask.
Record all of it, whether that is screen captures, voice notes or scrappy transcripts. Tidying up can wait. Getting answers out of somebody who has already started a new job is much harder.
Why writing it up earns its time back
A runbook is just a short page that says when this happens, do these steps. Not a design document, not a diagram. A page you can follow at 3 AM on your third night of broken sleep.
Turning those recordings into runbooks pays for itself fast. Google's Site Reliability Engineering book reports that writing the steps down in advance cuts the time it takes to fix an incident to roughly a third of what improvising costs. Same outage, a third of the panic.
DORA's research arrives at a similar place from another direction. Its 2022 data on documentation quality suggests good documentation multiplies whatever else your team is doing well.
Read that as leverage rather than as precise percentages. The same good practice simply returns more to a team that writes things down.
What to do after the last day
Eventually you pick one of three doors: hire a replacement, bring in a managed service provider, or do some of both.
Hiring brings the skills back. But if the new person ends up holding everything alone again, you have rebuilt the same single point of failure, this time without the history behind it.
A managed service watches the alerts and works through tickets, which covers the labour nicely. What it generally won't do is tell you unprompted that a sizing decision from two years ago stopped making sense, since nobody raised a ticket about it.
Either door works better with a written record behind it. That record is what lets the next person start from facts rather than archaeology. And a named owner for production is what turns the next resignation into an inconvenience instead of a crisis.
What you can do this week
If the engineer is still with you, put two sessions in the calendar in the next five days. In the first, somebody else deploys to production while the engineer watches. In the second, somebody else restores the main database into a test environment.
Then list every login and every alert notification that currently points at a single person. Your engineer can pull that list in a few minutes.
And if nobody has resigned? Do all of it anyway. It's a far more pleasant conversation when nobody is leaving.