Burnout and documented business processes

Key-person risk is the danger that a business stalls when one person, often a founder, is sick, on holiday or gone, because only they know how things work.

It rarely looks like a risk from the inside. It looks like dedication. In August GarageDesk has 200 shops and about twenty new ones a month. On a Friday at 11 p.m. the SMS service announces a weekend outage; only Nina knows how to switch to the backup, so she does it by 1 a.m., before reminders start at 9:00. It is her third weekend in a row, and every new shop's setup also goes through her.

Everything worked, and that is the trap. The outage was fixed only because one tired person happened to be awake. If Nina is ill for two weeks, reminders stop and new shops wait.

Most of what only the founder can do isn't expert work at all: it is knowing the steps. Steps can be written down, tested on someone else and handed over. Documentation, automation and hiring all reduce key-person risk; heroics increase it.

You can't document everything at once, so rank the repeating work. For each task ask four questions: how often does it happen, how long does it take, who can do it today, and what breaks if it's done wrong or not at all.

Two kinds of task go to the top:

• frequent tasks that eat time: onboarding a new shop, twenty times a month; the monthly check of failed and missing payments. Every hour saved repeats;
• rare but critical tasks: responding when reminders stop going out; switching to another SMS provider about once a year. Nobody remembers these steps exactly when they're needed, often at night.

At GarageDesk all four depended on Nina alone, which makes them the first four procedures.

Tasks that are rare, harmless if they wait a week and doable by anyone, like changing a sentence on the website, go to the end of the list. Writing a procedure for them costs more than it saves.

Most procedures fail on a single vague step. “Set up the reminder rules” is clear to Nina, who has done it a hundred times, and useless to Martha, GarageDesk's part-time support person, who hasn't. A good step answers everything the reader would otherwise have to ask.

Check each step for five parts:

• the action, with one verb: open, enter, choose, send;
• where: the screen, menu or file, ideally with a screenshot;
• the values: which services, which intervals, which template, and where to find them (for example the shop's own price list);
• why it matters, in one short clause, so the reader can handle a case the step doesn't cover;
• how to check it worked: what the reader should see when it's done right.

A step can be long and still be one step. What it must not do is assume knowledge that lives only in the author's head.

A quick test: could someone do this step on their first day, alone, at 1 a.m.? If not, the step needs more detail, not the reader more experience.

An SOP (standard operating procedure) is a written, step-by-step description of a recurring task, detailed enough that someone new can do it without asking the founder. Note-to-self shorthand isn't enough.

A reliable way to write one:

1. Do the task yourself and note every step as you go. Writing from memory skips the steps an expert no longer notices.
2. Add why each step matters, the known traps and screenshots, plus how to check the result worked. Better too much detail than too little.
3. Test it: someone else follows it while the author watches in silence, without helping.
4. Fix the document wherever they got stuck. If the tester is confused, the document is wrong, not the person.
5. Review it regularly and after every product change, or it quietly drifts away from how things really work.

Martha's first try at the onboarding procedure stopped at step four, “set up the reminder rules”: which rules, for which services? That is the silent test doing its job. Each such gap, found on a quiet Tuesday, is one less phone call at night.

Writing a procedure has a bonus: it shows what a machine could do. Nina noticed that setting up each new shop's reminder rules by hand (services, intervals, texts) takes about 1.5 hours and is almost the same every time.

First, size the manual work:

monthly hours = tasks per month × hours per task = 20 × 1.5 = 30 hours a month

That is about seven hours a week, well above the founders' own rule of automating anything that takes more than about four hours a week.

Then compare it with the one-off cost of the tool. A setup wizard with ready-made rules for typical services (oil change, brakes, timing belt) takes about 45 hours to build:

payback = build hours / hours saved per month = 45 / 30 = 1.5 months

After that, each month saves about 30 hours, as long as onboarding keeps its pace of about 20 shops. If new shops slowed to five a month, the saving would drop to 7.5 hours and the payback would stretch to six months, so check the pace before you build.

Procedures and automation work in a fixed order: write it down first, automate what is frequent and stable, keep a person for the exceptions.

Writing comes first because you can't automate steps nobody has spelled out. The written procedure shows which parts are the same every time and which need judgement.

A task is a good candidate for automation when it is:

• frequent, so the saved hours add up: twenty onboardings a month;
• stable, almost the same each time: the reminder rules for oil change, brakes and timing belt barely differ between shops;
• costly by hand compared with building the tool: 30 hours a month against a 45-hour build.

Keep a written procedure and a person for:

• rare tasks: switching the SMS provider once a year. A tool would cost more than it saves, and a clear SOP is enough;
• exceptions and judgement calls: an outage, an unusual request from a franchise, a shop with odd services. Automation handles the typical case; people handle the rest, using the procedure as a checklist.

Written procedures only end founder burnout when someone else actually uses them. At GarageDesk the work moves in three ways.

• Hand over the routine. With the procedures, Martha takes onboarding and the monthly payment check.
• Share the emergencies. From October Ethan, a contract developer, works part time for 35,000 UAH a month. He and Nina take turns on weekend duty, using the incident procedure. It works without calls to Nina only because Ethan has followed the procedure himself and the gaps he found were fixed.
• Protect rest on purpose. Nina takes one full day off every week, written in the calendar, with the phone off. “Call me if you're unsure” quietly cancels all of this: it keeps her on duty every day.

A founder who rests makes better decisions than a hero who is always on call. And there is a side effect: a business that runs from written procedures and more than one pair of hands is worth more to anyone, a buyer or the founders themselves.

It is tempting to see written procedures as paperwork for a future buyer. They do make a business easier to sell: a buyer pays more for a company that runs without its founders. But that is a side effect.

The direct gains come first, and they come whether or not the business is ever sold:

• fewer mistakes: a checked list of steps beats memory, especially for rare tasks like switching an SMS provider;
• work can move: Martha takes onboarding and the payment check, so Nina's hours go back to the product;
• rest becomes possible: with an incident procedure, Ethan can take weekend duty and Nina can take a real day off;
• automation becomes visible: writing the onboarding down revealed 30 hours a month of manual setup worth automating.

The founders who never plan to sell benefit most, because without procedures they are the ones answering at 1 a.m., indefinitely. A business that depends on its owners' constant presence isn't really owned; it owns them.