The Handover Document That Decides Whether You Can Take a Week Off

Search for how to hand over before a holiday and you will find a large amount of sensible, generic advice: brief the team, write an overview of ongoing projects, set an out-of-office, start two weeks early, name a point person. All of it is true. None of it explains why founders who do all five still spend the week answering messages from a hotel.

The reason is that the standard advice is written for an employee going on leave, and an employee’s handover problem is coverage — someone has to do the tasks. A founder’s handover problem is different and mostly invisible in the advice: it is authority. Your team usually knows perfectly well what to do. What they do not know is whether they are allowed to do it without you, and in the absence of that knowledge the safe move is to wait, or to ask. So the messages arrive, and the week is not a week off, it is the same week with worse wifi.

This is the document that fixes that, in the order the items actually matter — which is the order in which their absence breaks the week, not the order they appear on a checklist.

Why do handovers fail even when everything is documented?

They fail because the document answers “what happens” and the team’s real question is “what am I allowed to decide”.

The distinction is easy to miss because both look like the same sentence. “Client X’s report goes out on Wednesday” is coverage. “If client X asks for a change to the report, Priya decides, up to two hours of extra work, without checking” is authority. The first one is satisfied by a project list. The second one is the entire difference between a real week off and a remote week.

Oncken and Wass gave the underlying dynamic its lasting name in Management Time: Who’s Got the Monkey?, which opens on the paradox that managers run out of time while their subordinates run out of work. Their metaphor is that responsibility — the “monkey” — jumps from the subordinate’s back to the manager’s during ordinary conversations, because the manager takes ownership of solving the problem rather than leaving it where it belongs. A founder’s holiday is the highest-intensity version of this. Every unresolved question in the business is looking for a back to sit on, and yours is the default one. It stays the default one unless something has been written down that assigns it elsewhere in advance.

Which is why the useful mental model for the document is not “handover notes”. It is a decision-rights document, with the project list attached at the end because it is the least important part.

The three questions that produce the whole document

Before writing anything, answer these three, in this order, because the document is just their answers written out:

1. What decisions arise in a normal week? Not emergencies — normal ones. Approving an invoice, agreeing a scope change, replying to a complaint, signing off creative, letting someone start early.
2. Who decides each one while I am away, and up to what limit? A named person, and a number or boundary. “Use judgement” is not an answer; it is the thing that generates the message to you.
3. What is genuinely worth interrupting me for? A short list, written in advance, that both of you have agreed. If you do not write it, the list becomes “anything the person is nervous about”, which is unbounded.

That third one is where most founders quietly sabotage themselves. Saying “call me if anything comes up” feels generous and is the opposite — it transfers the judgement of what counts back to a person who has every incentive to be cautious. Two or three specific triggers, written down, is both kinder and more effective.

What goes in the document, in order of what breaks first

1. The decision-rights table

This is the whole document if you only write one thing, because it is the only part that prevents the messages rather than answering them.

One row per recurring decision. A named owner. A limit. It looks like this:

Two things about that table matter more than its contents.

The “nobody decides” rows are as important as the rest. A handover that grants no authority produces a paralysed week; one that grants unlimited authority produces a week you spend undoing things. Naming the small number of decisions that simply wait until you are back is what makes granting the others safe, and it is a much easier conversation to have in advance than in the moment. Most of those rows will be the same functions in the five things a founder should never fully delegate — pricing, the first-time complaint, the hire — which is not a coincidence. The permanent version of that list and the one-week version have the same logic behind them.

Every limit is a number or a boundary, never an adjective. “Small changes” is not delegable. “Up to half a day” is. The number does not have to be right. It has to exist, because a wrong number gets corrected once and an absent number generates a question every time.

2. The escalation path, with a named human at each step

Write down who the covering person calls when the thing is above their limit and you are unavailable — and make sure it is a person, not you.

This is the item that most founder handovers skip entirely, on the assumption that the answer is obviously “the founder”. If that is the answer, you have not handed over; you have simply added latency. Google’s SRE practice makes the same point about people carrying a pager: the chapter on being on-call lists the most important on-call resources as clear escalation paths, well-defined incident-management procedures, and a blameless postmortem culture. Note what is not on that list — deep expertise, or the presence of the person who normally does the job. What makes cover work is knowing where the next decision comes from.

For a small business the path is usually short and that is fine: covering person → second named person → you, with the second name being someone who can make a call rather than someone who merely knows things. It has to be written, because the point is to remove the moment where someone has to decide whether their problem is big enough to justify contacting you. That moment is where holidays are lost.

3. Access, before you go, tested

Everything the covering person will need to open, opened by them, while you are still in the country.

Access failures are the most common way a handover collapses, and they are almost entirely preventable, because they are discoverable in advance. The pattern is familiar: the ad account is under your personal login, the domain renews to your card, the client portal has one seat, the payment gateway requires an OTP to your phone, the bank needs your token. Nothing here is a documentation problem. It is an ownership problem that becomes visible only when you are unreachable — which is exactly the argument in who owns the ad account, and the reason to run that audit is not really the holiday, it is what happens if you are ever unreachable without planning it.

The test is the whole point, and it is one line: have the covering person actually log in to each system while you are still available, rather than confirming they have the credentials. Those are different claims and only one of them is checkable.

Give particular attention to anything that sends a code to your phone. Two-factor tied to a founder’s personal device is the single most common blocker, it fails silently until the exact moment it matters, and the fix — shared authenticator, a second registered device, or a delegated account — takes an afternoon.

4. The money view

One paragraph: what is due in, what goes out, what happens if either does not.

A week is short enough that most cash questions can wait and long enough that a few cannot. What the covering person needs is small: which receipts are expected and from whom, which payments go out automatically, what the balance floor is, and what to do if a large expected receipt does not land. That last one is the only genuinely tricky case, and it deserves a written instruction because the instinct — chase immediately and firmly — is not always right early in a relationship. The sequence for a client who has stopped paying is a good default to point at, and pointing at an existing document beats inventing a policy in an airport.

If you do not know your own floor, that is a bigger finding than the holiday: how much runway a services business actually needs is the calculation, and it is worth doing before you go, not because the week is risky but because the answer changes how much authority you are comfortable granting.

5. The client-facing sentence

Decide what your clients are told, and write the exact wording rather than the policy.

Two decisions here, and both are yours rather than the team’s. First, whether clients are told at all — for a founder-led business, “he is away this week” is heard by some clients as “the person I actually buy from is not available”, which is a service message whether you intend it or not. Second, if you say nothing and a client discovers you are away by getting a slow reply, that is worse than having said it. The workable middle is usually: tell the accounts that have a live deliverable this week, say nothing to the rest, and give the covering person the exact sentence to use.

Write the sentence. Not a guideline about the sentence. This is a brand touchpoint like any other — your brand is whatever your worst touchpoint is — and the version an anxious team member improvises under time pressure is rarely the version you would have chosen.

6. The project list

Last, because it is the part everyone writes first and the part that causes the fewest problems.

Your team already knows what the work is. Keep this short: what is due, to whom, and by when, with anything unusual flagged. The only rows worth writing carefully are the ones where something is not yet agreed, because those are the ones that will need a decision, and a decision needs a row in table one.

The rehearsal that actually tells you whether it works

Take a Wednesday off, unreachable, before you take the week.

This is the highest-value item in the entire post and it costs one day. A full day of genuine unavailability — phone off, no email, agreed in advance — surfaces every gap in the document in a way that no amount of reviewing it does. You will come back to a list of the things that were waiting for you, and that list is the missing part of your handover. Nothing else produces it. A document reviewed at a desk always looks complete, because you read the gaps and fill them in from memory without noticing.

Do it two or three weeks before the real trip so there is time to fix what it finds. And be strict about the unavailability, because a rehearsal you break at 3pm produces no information at all.

Reading what happened when you get back

The week produces a data set about your business that nothing else produces. Read it before it evaporates.

Ask the covering person for three things — not “how did it go”, which gets you “fine”:

• What did you wait on that you would rather have decided? These become new rows in the decision table, with limits. This is the list that makes next time shorter.
• What did you decide that you were not sure you were allowed to? These are the rows where your document was unclear rather than absent, which is a different fix.
• What broke that nobody had thought of? Occasionally this is a genuinely new failure mode and it belongs in the document permanently.

Then read the list of things that got escalated to you against the trigger list you agreed. Anything that reached you and was not on that list is either a gap in the document or a signal that the covering person did not believe the authority was real. Those two look identical from a distance and have opposite fixes, so ask which it was.

The uncomfortable version of this finding is worth naming. If a week away reveals that nothing can move without you, that is not a documentation failure and no document will fix it. It is a structural fact about how the business is built, and it has a cost you are already paying — in the ceiling on what you can take on, in what the business is worth to a buyer, and in what happens if you are unavailable for a reason you did not choose. That is a longer piece of work than a handover, and it starts with knowing which client is actually profitable when everyone works on everything, because concentration of work in one person usually tracks concentration of margin in a few accounts.

What not to do

Do not write it the night before. The value is in the decisions, and decisions made at 11pm while packing default to “ask me”.

Do not make the document long. A decision table, an escalation path, an access list, a money paragraph, a client sentence, a project list. Two pages. Anything longer will not be read at the moment it is needed, which is the only moment that counts.

Do not check in “just briefly” on day two. One check-in re-establishes you as the decision-maker for the rest of the week, and everyone reverts to waiting. If you genuinely cannot be unreachable, schedule one fixed window — a specific hour on a specific day — and be unavailable outside it. A predictable window is a workable compromise. Ambient availability is not.

Do not skip the debrief. The week is the most honest audit of your operational dependency you will ever run, and its findings have a shelf life of about three days.

Do not treat the document as single-use. Nearly all of it is true every week, not just holiday weeks. The decision table in particular is a permanent artefact that happens to have been written for a trip.

FAQs

How far in advance should I start? Two to three weeks, and the reason is the rehearsal rather than the writing. The document itself takes an afternoon. Finding out what it missed takes a test day plus time to fix what the test day surfaces.

What if I have no one to hand over to — it is just me? The document changes shape but does not disappear. A solo founder’s version is: what genuinely cannot wait a week, what a client is told, who has emergency access if something goes badly wrong, and what is scheduled to happen automatically while you are away. Most solo businesses can be unavailable for a week; what they cannot do is be unavailable silently. Say it in advance and almost nothing breaks.

Should the covering person get extra pay? If you are granting real authority, you are asking for something materially different from their normal job, and treating it as a favour is how it becomes resented. Whether that is money, time back, or the explicit developmental framing depends on the person — but decide it before you ask, not after they raise it.

What if a client escalates specifically because I am not there? That is worth knowing about and it is usually a relationship-design problem rather than a holiday problem: the client has been trained that you personally are the escalation route. The fix is not available this week. It is the same work as the first 90 days of an account — establishing early who the client’s actual counterpart is, before the habit forms.

Is this the same as a business continuity plan? It is the readable half of one. A continuity plan covers being unavailable without notice, which needs a couple of things this document does not — mainly, someone other than you having emergency access, and a written record of what is where. If you are writing the holiday version anyway, adding those two turns it into the version that also covers the situation nobody plans for.

The point of the whole exercise

A founder who cannot take a week off does not have a scheduling problem. They have a business where every decision routes through one person by default, and that default is expensive long before it becomes a holiday question — it caps how much you can take on, it makes the business fragile, and it makes it worth less to anyone who might buy it.

The document is worth writing for the trip. It is worth keeping for what it tells you: read your decision-rights table and you are looking at an honest map of how much of your company currently runs on your presence rather than on its systems. Most founders have never seen that written down. Writing it is the useful part, and the week off is really just the deadline that forces it.