The work that isn't software.

Start by writing down what must happen

Not what people do — what must happen regardless of who does it. Sit down for an hour and list the things that would cause a problem if they stopped: the monthly filing, the supplier renewals, the escalation route, the security review. Most companies of thirty people produce between forty and eighty. The first pass is always incomplete, and that is fine.

Then put exactly one name against each

The test is simple: if this does not happen, whose phone rings? If the honest answer is "it depends", you have found something worth fixing. Resist the urge to write a team name — shared ownership is the most reliable way to produce something owned by nobody.

The uncomfortable second column

Add a backup for each one. You will not be able to fill in all of them, and the empty cells are the most valuable output of the whole exercise. Order them by what it would actually cost if the owner were unavailable for two weeks, and work down from the top.

• A backup who lacks the access is not a backup
• A backup who lacks the authority is not a backup
• A backup who has never done it is a plan, not cover
• A backup on the same holiday is not cover either

Write the roles after the responsibilities, not before

It is tempting to start with job descriptions. Do not. Job descriptions describe an ideal; responsibilities describe what is actually happening. Once the responsibilities exist you can group them into roles that reflect the real company, which is a far more useful document than one written from a template.

Onboarding: build the template on the second hire

On the first hire in a role, write the steps down as you do them. On the second, you have a template. The single biggest improvement available to most small companies is not a better onboarding process — it is doing the same one twice.

Offboarding: transfer before you revoke

The order is the whole thing. Knowledge transfer first, then responsibilities to named successors who accept them, then customer introductions, then access on the last day, then equipment. A plan that revokes access in week one locks the company out of its own processes while the person who understands them is still sitting there.

Access: start with a list, not a project

You do not need to control every system to benefit. Write down who can reach what, including the shared advertising login and the supplier portal nobody thinks of as a system. That list answers the security questionnaire, catches the leaver, and makes the first access review possible. Automating provisioning can wait a year.

Review it when something changes, not on a schedule

Quarterly reviews of a responsibility map get skipped. What works is attaching the review to events that already happen: somebody joins, somebody leaves, somebody changes role, or a new recurring obligation appears. Each of those is a natural moment to ask whether the map is still true.