On a one-engineer team, the handover document is the data team. Whatever isn’t in it leaves with them.
DataKitchen calls this hero dependency: one person holds the knowledge the team needs to resolve incidents. It looks like resilience until the hero is gone. Our 2021 survey of 600 data engineers found 97% reporting burnout, and burned-out engineers change jobs and take the tribal knowledge with them.
You have weeks, not months. Spend them on the list below.
The seven-part handover
| Part | What to capture | How to check it’s real |
|---|---|---|
| Credentials | Every account, key, and token, who owns it, and when it expires | Log in with each one yourself before their last day |
| Schedules | Every job, when it runs, and what triggers it | Compare the list with the orchestrator, not with memory |
| Dependencies | Which sources feed each pipeline, and which reports read it | Pick one report and trace it back to its sources together |
| Business definitions | The one authoritative copy of each key metric | Ask the report’s owner to confirm each definition |
| Tests | What runs, what each failure means, and who acts on it | Break a test on purpose and watch who gets told |
| Incident history | What broke in the last year, why, and how it was fixed | Read the list together and mark causes that still exist |
| Recovery | How to rerun a failed load safely and roll back a bad one | Do a rerun with the leaver watching |
The right-hand column is the handover. The middle column is just notes.
The items on a timer
The things that break first are the ones with a clock on them. You Built the Thing. Now You’re Stuck Running It. lists the usual suspects: an API token that expires every 90 days, a database password in plain text in a script, a job that runs when someone remembers to run it. Each one works fine until the week after the person who knew about it is gone. Put every expiry date on a shared calendar now.
Business logic is the hard part
Credentials take an afternoon. Definitions take the rest of the notice period. Process guardianship describes the usual state: the same rule implemented three ways in three places, with nobody sure which is authoritative. Ask the leaving engineer to point at the one true copy of each key definition. Then turn each one into a test, because a written rule stops being checked the day its author leaves and a test doesn’t.
The best rules live in someone else’s head anyway, usually an analyst’s. Bring the analyst into this part.
Profile the data before the last day
The First Move When You Inherit Someone Else’s Data gives the order: profile first, take the keys second. A dated profile records null rates that break reports, schema violations, odd distributions, and broken joins as they stood before the handover. When a bad report turns up in six months, you can show whether it predates you. Without that record, every problem becomes yours.
Rehearse recovery
A recovery paragraph nobody has followed is a guess. Have the person staying rerun a failed load while the leaver watches. This is also when you find out whether the loads are idempotent. Where to Actually Start with DataOps in 2026 describes the failure: rerun a load that isn’t idempotent and 1,000 rows become 2,000, with nobody watching the row count.
If nobody is staying, that’s a different problem. Then the handover goes to whoever runs the pipelines next, and the same seven parts apply.