Single points of failure (usually: you)

A single point of failure is any component whose removal stops the whole system — and in a firm of 5–50 people, the most common one is the founder. The test is one question asked honestly: if this person, tool or client disappeared for a fortnight, what would halt? Engineers design redundancy into anything that matters; most service firms run their revenue, their client relationships and half their delivery through exactly one irreplaceable node and call it dedication.

Where do single points of failure hide in a service firm?

The audit is short because the candidates are predictable:

• The founder. Sales close only when they sell; escalations resolve only when they intervene; prices are set only in their head. The firm is not a system with a founder in it — it is a founder with staff attached.
• The one client. When a single client is 40% of revenue, then their budget cycle is your solvency. Concentration is a single point of failure wearing a good relationship's clothing.
• The unofficial expert. The one person who understands the deployment process, the reporting spreadsheet, or the legacy client's setup. Utterly reliable, never documented, currently interviewing elsewhere.
• The single channel. All new business from referrals is one failure point; so is all new business from one rented platform, where an algorithm change is a supplier deciding your lead flow.
• The unowned tool. The automation only one contractor can modify, the domain registered to a personal email, the sending infrastructure on someone else's account.

The systems-mapping habit of A Systems-Thinking Guide for Founders makes these visible fast: draw the flows — money, information, decisions — and circle every node where exactly one line carries everything.

Why does the founder end up as the biggest one?

By succeeding. Early on, the founder genuinely is the best salesperson, the best decision-maker and the client's preferred contact, so every important path gets routed through them — each routing individually sensible, the sum structurally fatal. The result is a strange emergent property: a firm that looks like a team but behaves like a sole trader with overheads — and as culture, it is a system output nobody chose. The founder experiences it as being indispensable, which is flattering, exhausting, and precisely the problem: indispensability is not a compliment, it is an architecture review finding. Buyers of businesses price it accordingly — owner-dependent firms sell at a discount or not at all.

Isn't some concentration just efficiency?

Yes, and honesty matters here: redundancy costs something, and a ten-person firm cannot duplicate every role. The question is not "eliminate all single points of failure" but "which failures can the firm not survive?". A single point of failure in a low-stakes process — one person books the travel — is a shrug. A single point of failure on a load-bearing path — revenue generation, key client delivery, the founder's judgement — is an outage waiting for a date. Rank by blast radius, fix the top of the list, and keep some deliberate spare capacity around the rest; that reserve is its own discipline, covered in slack: the capacity you keep on purpose.

How do you remove one?

The mechanism, step by step:

1. Run the fortnight test. When you list every person, client, tool and channel and ask "what halts if this vanished for two weeks?", then the load-bearing nodes identify themselves. Write them down; do not trust memory to keep the list uncomfortable.
2. Rank by blast radius and likelihood. When a node scores high on both — the founder's selling, the 40% client — then it goes first, however awkward it feels.
3. Document before you delegate. When a process exists only in someone's head, then extract it into a written procedure first; delegation without documentation just moves the failure point to a different skull.
4. Split the load, don't clone the hero. When the founder is the failure point, then carve their role into functions — selling, pricing, escalations — and move each to a system or a named person separately. Nobody can absorb a founder whole; three systems can.
5. Add the second path. When one channel produces all leads, then build a second before the first fails; when one person owns a client, then introduce a second contact while things are calm. Redundancy is cheap to build early and unbuyable during the outage.
6. Re-test annually. When the firm grows, then new single points of failure form quietly — yesterday's redundancy is tomorrow's bottleneck.

Where does speed make this urgent?

Anywhere response time is the product. A firm whose enquiry handling lives with one person does not have a follow-up process; it has a follow-up person, and their holiday is a revenue event. The numbers are unforgiving — contact rates drop roughly eightfold after five minutes, as an industry rule of thumb — which is why the 5-minute rule is effectively an argument for redundancy: only a system, not a hero, answers within five minutes on a wet Tuesday in August. That is the general shape of the fix. Heroes fail annually, at minimum, for two weeks at a time. Systems take holidays never — design accordingly.

---

Keep the thinking coming: The Format — a fortnightly letter on business and personal systems. Subscribe by email.