There is a specific kind of stuck that looks like success. You are the person who knows how the thing works. Nobody can cover for you, so nobody does. You take the laptop on vacation. You get passed over for the bigger job because the smaller one would collapse. Your manager calls you indispensable and means it as a compliment.
Indispensable is a ceiling. The only way through it is to make the work legible to someone else — and to do that on purpose, in a fixed amount of time, before a crisis forces the issue. This is the five-day build.
Our take: Most people fail at this because they try to document tasks. Tasks are the easy half and the useless half — a competent adult can figure out which button to press. What lives only in your head is judgment: the exceptions, the thresholds, the three vendors you never call on a Friday, the reason the number is always wrong in the second week of the month. Document the judgment and the tasks come free. Document the tasks and you have written an expensive manual nobody opens.
The test that tells you where you actually are
Forget the bus. The useful question is narrower: if you went dark for two weeks with no phone, what breaks and who notices? Write the list. Be specific — not “reporting” but “the Thursday forecast file that three people build their Monday off.”
Now sort each item into one of three buckets:
- Breaks loudly. Someone notices within 48 hours and escalates. These are your handoff targets. There are usually five to nine of them.
- Breaks quietly. Nothing happens for a month, then something is subtly wrong and expensive. These are the dangerous ones — they are almost always judgment, not procedure.
- Does not break. If two weeks of silence changes nothing, ask whether it should exist at all. A handoff project is the best excuse you will ever get to kill work.
You are documenting bucket one and bucket two. Nothing else. If your list has thirty items, you have listed tasks instead of outcomes; group them until you are under ten.
The four artifacts
Four documents. Not a wiki, not a folder structure, not a project. Four.
1. The Map (one page). What you own, stated as outcomes, with the name of the person who cares about each one. “Month-end close lands by business day four — CFO.” “Support queue under four hours first response — Head of CX.” This page is the only thing your manager will ever read all the way through, and it doubles as the first slide of your promotion case.
2. The Loop (one page). The recurring calendar of the job: daily, weekly, monthly, quarterly, annually. Each line gets a trigger, not a vibe. “Every Tuesday 9am” is a trigger. “When the Stripe payout email arrives” is a trigger. “Regularly” is not. Annual items are where handoffs die — the person taking over hits the thing you do every January and has never seen it.
3. The Runbook (one page per procedure, five to nine of them). Checklists, in the imperative, with the actual link or file path on every step. Written for a smart person on their first week, not for you.
4. The Judgment File (two to four pages, the whole point). Decision rules and edge cases. This is the artifact nobody writes and the only one that determines whether the handoff survives contact with reality.
The five-day build
Ninety minutes a day. Block it, defend it, do it in order.
Day 1 — The two-week test and the Map. Write the break list. Sort it. Write the Map page. Ninety minutes, and resist starting any procedure documentation today; you will document the wrong things.
Day 2 — The Loop. Open your calendar and your sent mail for the last ninety days and read backwards. Everything recurring goes on the page with its trigger. Then go back twelve months and add the annual items you would otherwise forget: renewals, audits, budget cycles, the one report the board asks for every fourth quarter.
Day 3 and Day 4 — The Runbook, captured live. Do not write these. Narrate them. The next time you run a procedure, hit record on a screen capture and talk through it as you go, including the parts where you hesitate. Ten minutes of recording produces a better draft than an hour of writing, because you cannot skip the steps your hands know and your brain forgot. Then turn the transcript into a checklist — or have a model do the first pass while you fix what it got wrong. The rule is one take. If you find yourself re-recording for polish, you are procrastinating.
Day 5 — The Judgment File. The hard ninety minutes. Prompt yourself with these five questions and answer in writing:
- What decisions do I make in this job that I never ask anyone about?
- What are the numbers or thresholds where my answer changes? (“Under $2,000 I just approve it. Over $10,000 it goes to Finance first.”)
- Which exceptions do I make, for whom, and why?
- What has gone wrong before, and what did I change so it would not happen again?
- Who do I actually call when it is broken — not the org chart, the real list?
Templates
Runbook entry. Keep it this short:
- Outcome: what “done” looks like, in one sentence a stranger could verify.
- Trigger: the calendar time or the event that starts it.
- Time: how long it really takes, honestly.
- Access needed: systems, permissions, the shared login that lives in the password manager.
- Steps: numbered, imperative, links inline.
- Known failures: the two or three things that go wrong most often, and the fix for each.
- Escalate to: a name and a threshold.
Judgment entry. Three lines: Situation → Rule → Why. The “why” is not optional. A rule without a reason gets followed off a cliff the first time the situation shifts, and a rule with a reason lets the next person adapt it correctly.
A worked example
Before: “Send the weekly customer email on Thursdays.”
After, as a runbook entry: outcome — email delivered by 10am Thursday to the active-subscriber segment, bounce rate under 2%. Trigger — Wednesday 3pm, when the content doc is due. Time — 45 minutes, 90 if the segment query needs rebuilding. Access — the sending platform, the analytics dashboard. Steps — nine of them, with the segment name and the test-send address written out. Known failures — the segment silently returns zero if the sync job failed overnight, so check the count before scheduling; images break if uploaded over 2MB.
And in the Judgment File, the line that actually matters: Situation: the content doc is not ready by Wednesday 3pm. Rule: send the standing fallback issue rather than skipping the week, and do not push the send past Thursday. Why: we tested moving it to Friday twice and open rates fell by roughly a third both times, and a skipped week costs more re-engagement than a mediocre issue does.
Nobody could have guessed that rule. That is the test of whether a judgment entry is worth writing.
The dry run — the only proof that counts
Documentation that has never been used by another human is fiction. Book ninety minutes with the person who would cover for you. They drive. You sit on your hands. You may not touch the keyboard and you may not answer a question until they have looked for the answer in the docs first.
Keep a running log of every moment they get stuck. Each entry is a bug in the runbook, and you fix it that afternoon while it is fresh. Expect eight to fifteen of them on a first run; expect two or three on a second. When a full cycle runs with fewer than three interruptions, you are done — and you now have evidence, which is a different thing from a feeling.
Three scripts
To your manager, asking for the time: “I want to spend ninety minutes a day next week documenting my job so someone else can run it. Two reasons: it removes me as a single point of failure, and it makes me available for bigger work. Can I take the week?” Managers approve this roughly always, because you have described their risk before you described your ambition.
To the colleague taking the dry run: “I need you to run the close on Thursday with me in the room but silent. Anywhere you get stuck is my bug, not yours. It should take you about two hours the first time.”
To the person pulling you back in after the handoff: “Check the runbook first — it should be in there. If it is not, ping me and I will add it.” This one sentence is the entire difference between a handoff and a temporary vacation. Say it every time for six weeks and it becomes the norm. If saying it feels impossible, that is a boundary problem rather than a documentation problem — and it is worth reading the playbook on saying no before you start this one.
Failure modes
- Writing it for yourself. If a step says “update the usual file,” it is a note, not a document. Ban “usual,” “just,” and “obviously.”
- The forty-page monument. Length is a proxy for avoidance. Anything over one page per procedure will not be read, which means it will not be used, which means you are still the only one who can do it.
- Documenting the happy path only. The happy path is discoverable. The known-failures section is the value.
- No named owner. A runbook with no owner reverts to you within two months. Every procedure gets a name next to it, even if that name is still yours for now.
- Confusing documentation with delegation. Writing it down transfers information. Someone else running it twice transfers the work. The dry run is not optional, and this is the same trap people hit when handing tasks to a model — a perfect brief is not the same as a checked result.
- Letting it rot. Docs decay in weeks. Attach a ten-minute rule: when a procedure changes, you edit the entry before you close the laptop. Then put fifteen minutes on the last Friday of the month to touch whatever broke — ideally inside a review you already run.
What it buys you
A real vacation, which is worth the week on its own. But the larger payoff is structural: you cannot be given a bigger job until someone can be given your current one, and you cannot hire under yourself until the role is written down. The Map page is your promotion case. The Runbook is your hiring spec. The Judgment File is the thing that makes a new person productive in three weeks instead of three months.
Five days of ninety minutes. Seven and a half hours to stop being the bottleneck in your own career.