When I left my role running People at Aware, a health-tech startup in Berlin, I hit a problem I'd watched go badly at every company before it. Everything about how the People function actually ran, the payroll quirks, the severance approach, the immigration edge cases, lived in my head and nowhere else.
The problem
This is normal. Startups don't write process documentation, because there's always something more urgent. You learn German parental-leave law the week someone gets pregnant. You learn the payroll cycle by running it wrong once. Then you leave, and it all goes with you.
The usual handover is a couple of calls and a half-finished document. I've been on the receiving end of that, so I knew it wouldn't do. But "write down everything you know" is a paralysing instruction. You don't know where to start, how much detail is enough, or which of the things obvious to you will be a mystery to your successor.
Who this is for
This works when three things are true: someone holds significant knowledge that isn't written down, there's a deadline that rules out a slow documentation project, and that person will talk even if they'd never sit and write it up. A head of people leaving a startup. A finance lead handing over month-end close. An operations manager who built a function from scratch. The domain doesn't matter; the pattern is always the same. Someone learned how something works by doing it, and now has to pass it on before they go.
The approach
I started with structure, not content. Before documenting anything, I spent about an hour with an AI building a table of contents: 13 chapters covering the whole role, from legal entities and payroll through onboarding, benefits, leave, terminations, immigration, compliance, and open items.
That choice mattered more than it sounds. A blank page asks "what do you know?", which is overwhelming. A chapter asks "what do you know about this?", which you can actually answer. (I had the AI critique the framework first and flag the gaps, which sharpened it before I wrote a word.)
Then the part that made it work: an AI agent that would interview me, chapter by chapter, and synthesise my answers into structured documentation in real time. I'd talk. It would turn what I said into clean, consistently formatted prose.
Small batches
The single most useful discovery was tactical. Early on the agent asked five or six questions at once. I cut it to two or three per round, and everything improved.
Two reasons. First, cognitive load: two or three questions sit in working memory, so you can answer them well without taking notes. Second, quality control: after each short round you see exactly how the AI interpreted you, so you catch a misread in the next exchange instead of finding it buried in a 20-page document later. When it once invented a cost-saving severance structure I'd never described, I caught it immediately. Tight loops also cut hallucination risk, because each cycle is small enough for the model to handle accurately.
What it wouldn't do
The agent's job was to be a documentarian, not an author. It turned "yeah we just email the export and she processes it" into "Generate the payroll export from Personio, upload it to NetFiles, and notify the external provider that the file is ready." It kept the structure consistent across all 13 chapters.
And it never invented anything: no processes I hadn't described, no best practices I hadn't confirmed, no assumptions dressed up as fact. Where something was missing, it flagged the gap rather than filling it. That boundary is the whole game. Unreliable handover documentation is worse than none, because it creates false confidence.
The result
Thirteen chapters, about 10,000 words, covering the People function end to end. About 15 hours of my time (10 hours creating the documents plus another 5 for successor review). From scratch it would have taken 40 to 60 hours, and realistically it wouldn't have happened at all.
The best and most detailed handover they'd ever received from a client.
— the external HR agency that took over the function