How to Document Your Job When No One Else Knows It

You are the only person who knows how your job works. There is no team who does the same thing, no shadow, no wiki that someone else maintains. Now you are leaving, and everything you know needs to end up on a page someone can actually use. Here is how to document your job when no one else knows it.

Start by deciding who will actually read it

When no one else knows your job, the document is not for a peer. It is for a stranger. That stranger might be a new hire who has not started yet, a manager who never did the work, or a contractor brought in three weeks after you leave.

This changes everything about how you write. A peer handover can say “the usual monthly report”. A stranger handover has to explain what the report is, why it exists, who reads it, and what happens if it is late.

Do a raw brain dump before you try to structure anything

The reason people freeze when documenting a job no one else knows is that they try to organise and remember at the same time. That is two jobs. Split them.

Give yourself 60 minutes with a blank doc and pull from these sources, one at a time:

• Your calendar for the last three months: every recurring meeting, every one-off you attended
• Your sent email folder for the last month: every project, contact, and question you answered
• Your task list or notes app: everything currently in flight
• Your bookmarks, tabs, and pinned Slack channels: the tools you touch weekly
• Your login history: the systems you actually use, not the ones IT thinks you use

Do not judge, sort, or edit. Just get it all in one place. The structure comes next.

Build the skeleton around six sections

Once the brain dump is done, sort what you have into six buckets. Every job, however unique, fits this shape:

Do not invent a bespoke structure. Every hour you spend designing your own template is an hour you are not documenting. This shape works.

Document the things you think are obvious

This is where solo-role handovers go wrong. You have been doing the job so long that everything feels obvious. It is not.

The reader does not know that the quarterly report needs finance sign-off before it goes to the board. They do not know that the vendor invoice always arrives on the 3rd and needs to be forwarded within 48 hours or it gets flagged. They do not know that “the usual supplier” is Karen at Nordic Supplies, and her direct line is on your phone, not in the CRM.

Capture the unwritten rules, not just the process

Processes tell someone what to do. Unwritten rules tell them how to actually get it done. When you are the only one who knows the job, the second is more valuable than the first.

Examples of what to write down:

• Which stakeholders need a heads-up before a decision is announced
• Which vendors will say yes on email but need a phone call to move faster
• Which internal systems lie: the CRM says one thing, the spreadsheet is the truth
• Which meetings are theatre and which ones actually decide things
• What day of the month payroll queries need to be in by, and who gets grumpy if they are late

Write these as one-liners. You do not need paragraphs. “Legal reviews contracts faster if you send them Monday morning, not Friday afternoon” is the whole entry.

Include a “first month” guide

A full handover document is intimidating. Someone opening it on day one needs a shorter answer to a simpler question: what do I actually do this week?

Add a section at the top called First 30 days and write it as an ordered list:

1. Week 1: get access to X, Y, Z. Read the role summary and active work sections. Introduce yourself to A, B, C.
2. Week 2: sit in on the Monday standup and the Thursday review. Watch how they run. Do not change anything yet.
3. Week 3: take over the recurring meetings. Start with the one that has the clearest agenda.
4. Week 4: send the monthly report using the template in Drive. Ask Karen in finance to review before it goes out.

This section is what turns a document from a reference into a lifeline. It tells the reader: you are not expected to know everything on day one, and here is the order in which to learn.

Link, do not duplicate

You will be tempted to copy content from other documents into the handover so the reader has everything in one place. Resist.

Link to the original document instead. If the process changes after you leave, an updated original is useful. A stale copy in your handover is worse than useless: it actively misleads.

For every link, add one sentence explaining what it is and why they need it. “Quarterly report template — use this from month two onwards” is enough context.

Pressure test the document before you leave

The best test for a solo-role handover is not a review meeting with your manager, who already knows the shape of your work. It is a stranger reading it cold.

If you can, find someone from a different team and ask them to read the first-month section and tell you what they still do not understand. Every question they ask is a gap. Every gap you fix is a problem your successor does not have.

For more on structuring the document itself, see the guide on how to write a handover document. For the harder case where there is no one hired to receive the handover yet, see how to hand over your job when there is no replacement.

The hardest part is the blank page, not the writing

When you are the only one who knows the job, the volume of what needs to come out of your head is the real problem. Structure helps. Time-boxing helps. But the first draft is still the hardest hour of your notice period.

If you work in Google Workspace, OneLast.Day reads your Gmail, Drive, and Calendar and drafts the handover from your actual work data: the projects you have been running, the people you talk to, the recurring meetings, the files you touch. You start from a first draft that already knows what your job looked like, and spend your time on the part only you can write: the unwritten rules.