Skip to content

RESOURCES · BLOG

Succession and systems: what the next generation inherits

Rui Luis · Published · 3 min read

An open ledger book on the left, its rows continuing as thin parallel off-white lines across a dark gap to a small stack of pages with a table on the right; one of the lines is ember-orange and lights up a single row of the table

Short answer: Succession plans cover ownership, governance and the family. They rarely cover what the business actually runs on: the steps only one long-serving person knows, the spreadsheet rules nobody wrote down, the approvals that live in someone's head. A successor should be able to read how the business runs on day one. Mapping that is the work, whether or not anything is ever automated.

This is for owners planning a transition in the next few years, and for the sons, daughters, nieces and nephews who will be on the receiving end of it.

What does the next generation actually inherit?

On paper, the shares, the property, the customer list and the brand. In practice, they also inherit a set of loops that run every week and every month: quoting, invoicing, month-end, the council pack, the lender's certificate, payroll. Most of those loops were built up over years by people who never had a reason to write them down.

That is fine while those people are there. It becomes a problem at the worst possible moment: during a transition, when the founder is stepping back and a long-serving controller or office manager decides it is a good time to retire too.

Which parts of the business are undocumented?

A simple test: for each recurring loop, ask whether the business could run it next month if the person who does it today were gone. Not "could someone eventually figure it out", but next month, from what is written down.

The answers tend to fall into three groups:

  • Loops anyone could run. The steps are in the system, the rules are clear, and two or more people know them.
  • Loops one person runs. Everything works, but only because one person knows which spreadsheet to open, which supplier always invoices late, and which number the bank actually looks at.
  • Loops nobody fully understands. They work, and nobody is quite sure why.

The second group is the succession risk. The third is a risk already.

What should a successor be able to read on day one?

For each loop that matters, four things:

  1. A map. The steps in order, as the loop actually runs, including the workarounds.
  2. The rules. Every threshold, tolerance and approval limit, written down: what gets flagged, who signs above what amount, which customers get different terms.
  3. The history. A log of what was done, when and by whom, so a successor can see how decisions were made, not just that they were.
  4. A runbook. What to do when the loop breaks, and who to call.

None of this needs new software. It needs someone to sit beside the person who does the work and write down what they actually do, which is how we start every assessment.

Why is building a loop properly also documentation?

Because every rule written as code is a rule a successor can read, and every action logged is a history they can check.

When a loop is built the way we build them, each step is sorted (delete, code, model or person) and the sort is written down (rule 03). Each exception has a named owner (rule 07). Each action is logged and can be reversed (rule 08). And it is handed over with a runbook, so the client's own people can run it (rule 13). A successor who inherits a loop built that way inherits the knowledge with it.

That is a side effect, not the reason to build. If a loop isn't worth automating, mapping it and writing the runbook is still worth doing for the handover (rule 14).

What shouldn't be automated before the handover?

The judgement calls the successor needs to learn to make: which customer gets an exception, when to push back on a supplier, what to say to the bank in a bad quarter. If a loop takes those decisions away before the successor has learned them, the successor inherits a business they can operate but not run.

The right shape is the one that keeps people on the decisions: rules handle the routine, a person handles the exceptions, and the successor learns by owning the exceptions alongside the person who owned them before.

Where do we start?

List the five loops in your business that only one person can run. For each, write down who that person is and what would happen if they were away for a month. That list is the operating half of your succession plan. If you want help mapping the first one, book a 30-minute call. No deck, just the work that piles up.

Frequently asked questions

Isn't succession a question for our lawyers and advisors?

The ownership side is: shares, estate planning, governance, the family agreement. This is the operating side: how the business runs day to day, and whether anyone other than the current person can run it. Both need doing, and they need different people.

Should we automate before or after the transition?

Map before. Whether anything gets automated is a separate decision, made loop by loop. What matters for succession is that the steps, the rules and the history are written down where the successor can read them. Building a loop properly does that as a side effect; so does simply mapping it.

What does a runbook look like?

A short document per loop: what triggers it, the steps in order, the rules and thresholds it applies, who approves what, where it logs, what to do when it breaks, and who to call. It should be usable by someone who has never done the work before.

← All posts