Systems-Dependent vs People-Dependent Businesses

A people-dependent business is one whose results come from the skill, memory, relationships, and judgment of specific individuals. Take those individuals away and the results change, often sharply. A systems-dependent business gets its results from documented processes, defined roles, and management routines that work whoever happens to be filling the seats.

Neither description is a verdict. Most companies are somewhere in between, and some of the best businesses in the world deliberately lean on people. But the question of which side your business sits on shapes how well it scales, how it copes with a bad week, and what a buyer or lender will make of it. This article covers the definitions, the spectrum, how to diagnose where you are, the trade-offs, and how businesses move.

The two models, defined

People-dependent. Know-how lives in heads. Customers buy from a named person. Decisions wait for whoever has the authority, which is usually informal. New hires learn by watching someone and absorbing how things are done. Quality varies with who's on shift.

Systems-dependent. Know-how lives in process documentation, checklists, and tools. Customers buy from the company and deal with whichever qualified person is assigned. Decision rights are written down. New hires are trained against a standard. Quality is more consistent because the method is shared, not personal.

A system here doesn't mean software. It's any repeatable arrangement that produces a result without needing a particular person: a standard operating procedure, a hiring scorecard, a weekly metrics review, an approval limit. Software can carry a system, but a laminated checklist counts too.

It's a spectrum, and it varies by function

It's tempting to label a whole company, but the real picture is patchier. A company can have a tightly systemized finance function and a sales function that runs entirely on one rainmaker's address book. A manufacturing line can follow written work standards while product design depends on one engineer's judgment.

A more useful way to think about it is a ladder with four rungs:

1. Heroic. Everything depends on specific people doing whatever it takes. Results are good when they're present and bad when they're not.
2. Informal habits. People mostly do things the same way, but it's custom, not written, and it lives in the team's collective memory.
3. Documented. The main processes are written down, though not always current or followed.
4. Managed system. Processes are documented, owned by named people, measured, and updated when they stop working.

Plot each function (sales, delivery, finance, hiring, customer support) on the ladder. You'll find that the company-wide average hides the weak spots, and those are the ones that hurt.

Where the idea comes from

The framing isn't new. A few well-known models circle the same question from different angles.

Gerber's Technician, Manager, and Entrepreneur

Michael Gerber's E-Myth work is the most-cited popular version. According to EMyth's own account of Gerber's work, most businesses are started by Technicians operating under what he called the Fatal Assumption: "If I understand the technical work of my business, I understand a business that does that technical work." The same page describes three roles: the Technician who performs the technical work, the Manager who handles operations and systems, and the Entrepreneur who views the business as a system separate from themselves.

Gerber's aim, as EMyth describes it, is a business that works without the owner rather than because of the owner. That is the systems-dependent end of the spectrum. The same idea underpins the move from owner-operator to manager, covered in Owner-Operator vs Owner-Manager.

Codification vs personalization

Morten Hansen, Nitin Nohria, and Thomas Tierney's 1999 Harvard Business Review article described two ways firms manage knowledge. Per the Harvard Business School summary of their work, a codification strategy uses a "people-to-documents" approach: knowledge is extracted from the person who developed it, made independent of that person, and reused. A personalization strategy emphasizes dialogue between individuals instead of knowledge objects in a database.

This maps neatly onto the topic. Codification is the systems-dependent way of holding knowledge. Personalization is the people-dependent way. The authors' finding is the important part: effective firms excelled by focusing on one strategy and using the other in a supporting role, and did not try to use both to an equal degree. Their examples were Andersen Consulting and Ernst & Young on the codification side, and Bain, Boston Consulting Group, and McKinsey on the personalization side. Their article puts it as an 80-20 split, with roughly 80% of knowledge sharing following one strategy and 20% the other.

So the answer isn't "codify everything." It's to pick the primary strategy deliberately, based on what the business sells.

Tacit and explicit knowledge

Ikujiro Nonaka and Hirotaka Takeuchi's SECI model describes how knowledge moves between two forms. Explicit knowledge can be precisely explained and understood independently of whoever holds it, like an instruction manual. Tacit knowledge is understood by its holder but can't easily be explained or written down, and it's often built on insight, intuition, and experience. In the model, as summarized by MindTools, organizations move knowledge through four stages: socialization (sharing tacit knowledge through conversation and practice together), externalization (turning tacit knowledge into explicit form), combination (merging explicit sources), and internalization (turning explicit knowledge back into practiced understanding).

The practical lesson for founder-led firms is that externalization is the hard step, and it's the one that moves a business toward systems. A founder's "feel" for a customer or a pricing exception is tacit. Turning it into a rule, a template, or a checklist is the work. And internalization matters too: a written procedure nobody practices doesn't change how the business behaves.

Why it matters

Scalability

A people-dependent business scales by adding more of the same people, which means more of the scarce skill and more of the founder's attention. Output tends to grow in step with headcount, and quality varies as you add people. A systems-dependent business can add volume faster than it adds heads, because a new person is trained into a method that already works. This is why growth in a founder-led company so often stalls at the point where the founder can no longer personally touch everything.

Resilience

A business built on people is exposed to their absence. Illness, resignation, burnout, and holidays all become operating risks. A system doesn't remove the need for people, but it shortens the time it takes to cover for them. The difference between "the process is documented and someone's trained on it" and "only Sam knows how" is the difference between a bad week and a lost customer.

Valuation and sellability

Buyers and lenders look at how much of the value would leave with the owner. The clearest official statement is US tax guidance for valuing closely held stock. Revenue Ruling 59-60, section 4.02(b), says the loss of the manager of a so-called "one-man" business may have a depressing effect on the stock's value, particularly where there's a lack of trained personnel able to succeed to management. The same passage lists offsetting factors, such as assets that aren't impaired by the loss, life insurance cover, or the ability to hire competent management. It doesn't set a percentage, and it's US guidance, so other jurisdictions apply their own approaches.

The takeaway isn't a number. It's that a business which can show documented processes, trained successors, and delegated authority gives a buyer fewer reasons to discount it.

Key person risk

Key person risk is the direct consequence of dependence on individuals. The more of your results depend on a few people, the larger the exposure. Moving toward systems is one of the main ways to reduce it. The full treatment is in What Is Key Person Risk?, and the founder-specific version is in Founder Dependence.

How to diagnose where your business sits

You don't need a consultant to get a first read. Work through these questions, function by function.

A rough scoring approach: for each function, count how many answers fall in each column. If most land on the left, the function is people-dependent. If the answers are mixed, it's in transition. This is a judgment tool, not a benchmark, so use it to compare your own functions against each other, not against other companies.

Two additional checks help:

• The vacation test. Ask each manager to take two weeks fully offline. What breaks tells you more than any workshop.
• The documentation audit. Pick three important processes at random and ask the person who does them to hand over the written version. If it doesn't exist, or nobody follows it, you've found a gap.

The trade-offs: systems aren't always better

It would be easy to read all this as "systems good, people bad." That's wrong, and it's worth being careful about.

Craft and judgment can't be fully codified. A senior lawyer, a head chef, an architect, or a top enterprise salesperson works from tacit knowledge that no manual captures. Trying to turn it into a script can flatten what made the work good. Hansen, Nohria, and Tierney's finding points the same way: for firms that sell customized solutions to unique problems, a personalization strategy, with knowledge shared person to person, can be the right primary choice.

Relationships can be the product. In some businesses the customer is paying for access to a specific person. A boutique advisory firm or a design studio with a famous principal may be better off protecting that than diluting it. The risk is real, but it's a deliberate trade, and it should be managed with deputies and shared client contact, not erased.

Systems have costs. Writing, maintaining, and training against procedures takes time. Badly designed systems create bureaucracy: rules nobody believes in, approvals that slow everything, and employees who follow the process off a cliff because judgment is discouraged. A system that's out of date is worse than none, because it gives false confidence.

Early-stage companies need flexibility. A five-person company that's still discovering its product doesn't benefit from heavy procedures. Documenting what you do before you know what works just writes down the wrong thing.

The better framing is a question about fit: for each function, how much of the value is craft and judgment, and how much is repeatable work? Systemize the repeatable part and protect the craft part, with backups.

How businesses move toward systems

Nobody flips a switch. The move happens one function at a time, and it's mostly about changing habits, not buying tools. A workable sequence:

1. Find the dependencies first. Use the diagnostic above and the key person assessment to list where results depend on one person. Start with whatever would stop the business.
2. Choose the order by damage and by repeatability. Systemize high-damage, repeatable work first. Leave highly creative work for later, and handle it with cross-training instead of scripts.
3. Get the knowledge out of heads. This is the externalization step. Have the person who does the work walk through it while someone else writes it up, or record them doing it. A first draft that's 70% right and in use beats a perfect one that's never finished.
4. Name an owner for each process. A procedure without an owner goes stale. The owner keeps it current and answers questions.
5. Test it with someone else. Have a different person do the task using only the document. Every place they get stuck is a fix. This is where internalization happens.
6. Write down decision rights. Use a delegation of authority matrix so people know what they can approve and what must escalate.
7. Build a layer of management. Systems need people who run them. Developing a management team below the founder is usually the step that makes the rest stick.
8. Review on a schedule. Set a regular review so procedures change when the work does.

This is the core of what's described in Professionalizing a Business and, at its end point, Institutionalizing a Business. The founder's part in it is usually the hardest: letting go of being the answer to every question, and accepting that the second-best way, written down and followed, often beats the best way, held in one head.

Key Facts: Systems-dependent vs people-dependent businesses

• A people-dependent business gets results from specific individuals' skill, memory, and relationships; a systems-dependent one gets them from documented processes, defined roles, and management routines.
• Most businesses sit on a spectrum and vary by function, so diagnose sales, delivery, finance, and hiring separately.
• According to EMyth's account of Gerber's work, most businesses are started by Technicians operating under the Fatal Assumption, and the aim is a business that works without the owner rather than because of the owner.
• Per the Harvard Business School summary of Hansen, Nohria, and Tierney (1999), effective firms focused on either codification or personalization and used the other in a supporting role.
• Revenue Ruling 59-60, section 4.02(b), says losing the manager of a "one-man" business may depress stock value, especially without trained successors. It sets no percentage.
• Systems aren't always better: craft, judgment, and personal relationships can be the product. Systemize the repeatable work and protect the rest with backups.

Related reading

• Owner-Operator vs Owner-Manager
• What Is Key Person Risk?
• Founder Dependence
• Professionalizing a Business
• Institutionalizing a Business
• Second-in-Command
• Process Documentation