Roles, not people

The single biggest blocker to getting systems into a small business is that the owner thinks in people and not in roles.

Janet does the bookkeeping. Mark runs the field crew. Sarah handles the customer calls. The work is described, in the owner's head, in terms of who does it. As long as Janet and Mark and Sarah are around, the business runs. Day to day, this works fine.

The problem shows up the moment any of those people leave. Janet retires. Mark gets a better offer. Sarah goes on maternity leave. Suddenly the business is missing not "the bookkeeper" or "the field operations lead" or "the customer-facing voice" — it is missing Janet, Mark, and Sarah specifically, and the parts of the business that lived in their heads are scattered across the wreckage.

The same problem shows up, in a slower form, when the business tries to scale. A second person cannot be Janet. A second Mark does not exist. The work cannot be hired against, because the work has never been described in a way that anyone other than the original person could pick up.

This is why the move from people to roles is not a HR exercise. It is the most foundational systems-thinking move an owner can make. Until it happens, no operational system you install — no checklist, no template, no software, no AI — can do its job.

The distinction, plainly

A person is a specific human being. A role is the work the person does, separated from the person doing it.

"Janet" is a person. "The bookkeeper" is a role. The role is what gets done. Janet happens to be the one who is doing it right now.

This distinction sounds pedantic. It is, instead, the most consequential mental shift in operating a small business. When you describe the work in terms of the role, several things become possible that were not possible before:

• You can hire for the role without rewriting the job from scratch
• You can train someone into the role with a clear target
• You can install a system that supports the role, not just the person
• You can outsource part of the role
• You can decide whether AI can do part of the role
• You can promote the person and have someone else step into the role

When the work is only described in terms of the person, none of those moves work. The work and the person are the same thing in your mind, and "replace the person" feels like "lose the work."

How role-and-person mix together in practice

In real businesses, roles and people are intertwined. The person brings personality, judgment, history. The role brings a defined scope of work. The combination is what makes the business hum.

The mistake is to confuse the two halves of that combination.

Ways the confusion shows up:

"Only Janet can do that." Sometimes true, in a narrow sense — Janet has built up tacit knowledge that nobody else has. But the question is: should only Janet be able to do that? If the role is "bookkeeper," and only Janet can do it, that means the role has not been documented. It is a person dependency masquerading as a job.

"We can't hire because we can't find another Mark." Of course you can't. Marks are not for sale. The question is whether you can find someone who can do Mark's role — and the answer depends on whether you have ever described that role outside Mark's head.

"Sarah does whatever needs doing." Common in early-stage businesses. Useful for a stretch. Eventually a problem, because "whatever needs doing" is not a role — it is the absence of one. When Sarah leaves, the work she was absorbing scatters and nothing catches it.

"That's just how she does it." A specific way a person does a specific thing. Sometimes that is what the role requires. Sometimes it is incidental — the person has a habit, and the work has accreted around the habit, and now the work and the habit are inseparable in the team's mind. Roles let you tell the difference.

The healthy version: every person on the team understands their role as a defined scope of work that exists independently of them. They can describe it. They know where the role's boundaries are. They know when something falls inside the role and when it falls outside. They know what successful performance of the role looks like. The person brings themselves to the role; the role does not bring itself to the person.

Why this is upstream of every system

A system — any system, manual or digital, simple or sophisticated — can only support a defined scope of work. If the scope is not defined, the system cannot serve it. This is why owners who try to install systems before they have separated roles from people end up with systems that do not fit anyone.

The pattern: an owner buys a CRM, or a project management tool, or an estimating system. The team is supposed to use it. Three months in, half the team uses it for half their work, and the other half ignores it. The owner blames the team. The actual problem is that nobody clearly defined which role does what inside the tool, because the work was always defined by who was doing it, not by what the role required.

The same applies even more strongly to AI. An AI feature is built to support a role. "AI assists the bookkeeper with reconciliations." "AI drafts quotes for the estimator to review." If the role does not exist as a defined thing, the AI feature has nothing to attach to. It assists Janet — but Janet's job, as Janet does it, is unique to Janet, and the AI cannot adapt to a moving target.

This is one of the most overlooked reasons AI projects fail in small businesses. The AI is fine. The model is fine. The integrations are fine. The role the AI was supposed to support was a person, not a role, and the moment the system tried to support the person it ran into the fact that the person's job had no shape outside of their head.

How to start separating

You do not have to organize your whole business at once. You can start small. Three steps, in order.

Step one: name the roles. Make a list. Not of the people you have, but of the roles the business needs filled. Some of these will map cleanly to current people. Some will be split across multiple people. Some will be currently unfilled. Resist the urge to write people's names next to each — for this exercise, write the roles only.

If the list looks short — six roles for a ten-person business, say — that is a sign you have been thinking in people. Most small businesses have ten to twenty distinct roles, even if only six people are on the payroll. People wear multiple roles. That is fine. Naming all the roles is the first move.

Step two: describe each role in terms of its outputs. For each role, write one sentence: what does this role produce, and for whom? "The bookkeeper produces accurate monthly financial reports for the owner and the accountant." "The estimator produces approved quotes for active customers." "The field operations lead produces completed jobs that meet spec for the customer." Outputs, not activities.

This step alone, done honestly, surfaces problems. Roles that turn out to have no clear output — "office manager" sometimes does this — need to be either redefined or eliminated. Roles whose output is "whatever the owner asks today" are not roles; they are the owner doing the work through a proxy.

Step three: identify, for each role, what is the role and what is the person currently doing the role. Janet's role is bookkeeping. Janet's specific magic — that she calls customers when invoices are 30 days late, that she catches anomalies the software misses, that she has a soft touch with the accountant — is a mix of role and person. Some of that is the role (the role should always include catching anomalies). Some of that is Janet (Janet's particular way of calling customers may or may not be how the next person does it). Pulling those apart is uncomfortable and necessary.

You will not finish this work in a week. You will probably not finish it in a year. Owners who have been thinking in people for twenty years cannot fully reverse that habit overnight. But the moment the work begins, every other systems-thinking move becomes available. Hires get easier. Software fits. Roles can absorb AI. The business stops being a portrait gallery of indispensable people and starts being a system that operates the loop, with the people the talented humans who currently inhabit it.

The owner's particular role

One last thing.

The owner is in a role too. The owner's role is usually the most undefined of all, because the owner is the person who has been making everything up as they go. "I do whatever the business needs me to do today" is the owner's version of the same problem — and it has the same cost.

An owner who cannot describe their own role cannot delegate any of it. The work the owner does — the actual definable work, separable from "being the owner" — gets stuck on them, indefinitely, because nobody knows what part of it could move and what part has to stay. The result is the owner doing the bookkeeping, the estimating, the sales, and the field operations, all at once, until the body gives out.

Defining your own role is the move that lets you eventually stop doing the parts of the business that should not be the owner's job. It is also the work owners avoid most. The next person you hire, the next system you install, the next AI tool you adopt — the value of any of them is capped by the clarity of your own role, and the gap between what only you can do and what only you happen to be doing.

For more on what gets done with the role-and-person separation in place, read Source of truth (and what it costs to lack one), Workflows: how value moves through a business, and Deciding vs executing.