top of page

How to build consistency that does not depend on key people

  • Writer: Sylvie Cowell
    Sylvie Cowell
  • May 6
  • 3 min read

The key person risk most businesses ignore

Most businesses know, at some level, that they have key person risk. There is someone — sometimes it is the founder, sometimes it is a long-serving team member — whose knowledge, habits, or relationships hold a disproportionate amount of the business together.


The risk is usually framed as a continuity problem: what happens if that person leaves? But the more immediate cost is not what happens when they leave. It is what happens every day while they are still there.


When consistency depends on a person rather than a system, consistency is fragile. It fluctuates with their capacity, their focus, and their availability. When they are busy, things slip. When they are away, things stop. When they move to a different role, the consistency they carried does not transfer.



The difference between personal consistency and system consistency

Personal consistency is when things work because a specific person knows how they should work and makes sure they do. It is the person who always follows up, the one who remembers the client preferences, the one who knows which stage every project is actually at.


System consistency is when things work because the process is defined, documented at the right level, and followed by whoever is doing the work. The knowledge lives in the system, not the person. Handovers are clean. New team members can perform to the same standard within a reasonable period. Quality is not a function of who is in today.

Most founder-led businesses operate primarily on personal consistency. It works until it does not.


The business that depends on people who cannot be replaced is a business that cannot scale. The work is to make the knowledge transferable.



What documenting at the right level means

One of the reasons businesses avoid this work is that process documentation has a reputation for being bureaucratic and time-consuming. A 40-page procedure document that nobody reads is worse than nothing — it creates the illusion of a system without the reality of one.


Documenting at the right level means capturing the decisions, not the keystrokes. The things that someone new would get wrong without guidance. The quality standards that are not obvious. The sequences that matter. The exceptions worth knowing about.


The test is simple: could a capable new person follow this to a reasonable standard? If yes, it is documented well enough. A well-structured one page is more valuable than a comprehensive manual nobody reads.



Where to start

Start with the processes that most depend on specific people, and the ones where inconsistency is most costly. These are usually client-facing processes, delivery processes, and the processes that feed directly into revenue.


The account manager who holds all the client context in their head. The operations lead whose handover notes have never been written down. The founder who is the only person who knows how to price a complex job. These are your starting points.

For each one, ask: if the person who currently owns this left tomorrow, what would break? That is your documentation priority list.


Then work backwards from the answer. What knowledge does someone else need to perform this process to the same standard? Write that down. Test it with someone unfamiliar. Improve it. That is process documentation done properly.



The meeting rhythm that holds the system

Process documentation alone is not enough. Processes erode without a mechanism to maintain them. The operating rhythm — the consistent meeting cadence, the regular performance reviews, the weekly check on priorities — is what holds the system together over time.


Consistency that does not depend on people is built in two stages: first, you make the knowledge explicit and transferable. Then, you build the rhythm that keeps the system honest. Both are required. Neither is sufficient on its own.


When both are in place, the business no longer depends on heroics. It depends on design.

 

If you have completed the Operating System Diagnosis, go to Section 3 — this is where that gap will show up most clearly.


If you haven't, it is worth doing. It takes about 3 minutes and gives you a structured view of where your business's operating gaps actually are.



 


Comments


bottom of page