Five First Steps Away From "Only She Knows How"

The short answer

You cannot remove key-person dependency in one pass, so start with five things. Write one page of procedure. Agree where the files live. Stop sharing accounts. Sort out permissions and a record of who did what. Then have somebody else run the task once, for real.

The order matters. Without a written procedure you cannot decide where files should live, and without that you cannot decide permissions. Work down the list.

Why work concentrates in one person

It almost never happens through bad intent. Someone is fastest at a task, so the task stays with them, and every improvement they make accumulates inside their own head. The more conscientious the person, the more this happens.

The other cause is that asking is easier than writing. For a while it genuinely is faster to lean over and ask, and that period can run for years without anything being written down. The bill arrives on the first day that person is out. In a sudden handover, even they cannot explain everything at once.

The five steps

1. Write one page — just one

Trying to be comprehensive guarantees you never finish. Pick a single task that hurts when it stops, and keep it to one page. Cover four things:

• When it starts (a date each month, or an arriving document)
• What to open (file names, where they live, which service)
• The steps, numbered, using the exact names shown on screen
• How you know it is finished

The trick is not to have the regular owner write it. Have someone else write it while asking them questions. When the owner writes it alone, every assumption that has become obvious to them goes missing.

2. Decide where the files live

A procedure that says "the latest version on my desktop" cannot be handed over. Move the files the task uses off the individual machine into a shared location, and put that location in the document.

Limit the move to the files that appear in this one procedure. Start reorganising the whole company's folders at the same time and that is where you will stall.

3. Stop sharing accounts

One ID and password used by several people looks like the opposite of key-person risk, but it makes handover harder. Because nobody can tell who did what, you cannot verify a procedure or trace the cause of a mistake.

Give each person their own account and grant only what they need. If cost is the reason you share, the better first move is to narrow who performs the task at all.

4. Set permissions and keep a record

Grant only what the task requires. But watch the other failure: if the backup person cannot act because they lack access, you are back to one person again.

Alongside that, make sure you can tell later who did what and when. Records of approvals and corrections let you read back the judgement calls the written procedure never captured. In most cases, the features already in the services you use are enough.

5. Have the backup person run it once

Until somebody actually does it, you will not find the gaps. On a day when the usual owner is in, the backup person performs the task working only from the document. The owner watches, and writes each question into the page as it comes up.

It does not need to go perfectly. Every point where the backup person got stuck is a gap in the procedure.

What this looks like in practice

A five-person architecture studio where one person issues invoices and checks incoming payments.

Start with "issue invoices at the beginning of the month." The page needs to include the judgement — which jobs qualify this month, whether acceptance is complete — and who to ask internally. Next, move the invoice template and the past invoices to a shared location. Split the accounting service into individual accounts, and give the backup person only the access issuing requires. The following month, that person issues exactly one invoice from the document.

The question that comes up is almost always the same: does this job belong in this month's run? That judgement is the part nobody wrote down, and it is what key-person dependency actually consists of. In a handover, judgements like this weigh more than the steps themselves.

Write judgements as two or three past examples rather than a list of conditions: "If the acceptance certificate has arrived, it goes in this month; if not, next month. This client closes at month end, so their previous month is batched together." With examples, whoever meets a case that does not fit can also tell who to ask.

Do not overdo it

Trying to document every task produces a pile of pages nobody updates. An out-of-date procedure is worse than none, because it hands over wrong information with full confidence.

Restrict this to tasks that hurt when they stop. For something that happens once a year, it is enough to capture notes the next time it comes around. Procedures survive when you decide in advance who updates them after a change.

In short

Dependency collects around careful people. Write one page, move the files it references into a shared location, end shared accounts, set permissions and a record of activity, and let someone else run it once. When those five are done, pick the next task that hurts when it stops. Repeating this is faster than attempting everything at once.