How to Build a Workflow That Survives the People in It.

← Back to Insights

Here is a test I use with business owners who are not sure whether they have workflows or dependencies: ask them what happens when a specific person calls in sick. If the answer is "we figure it out" — the business has workflows. If the answer is "I have to go in" or "that area basically shuts down" — the business has dependencies disguised as workflows.

I have walked into businesses with beautiful binders of documented procedures and watched those procedures completely break down the moment the person who wrote them was not present to interpret them. The binder documented what that person did. It did not document the process well enough for anyone else to do it. That is a dependency. And it is more common than most owners realize.

The Difference Between a Workflow and a Dependency

A workflow is a process the business owns. It is documented clearly enough that a competent new person can follow it to a standard, and an experienced person can follow it to a higher standard. It produces consistent results regardless of who is executing it, within a range the business can accept.

A dependency is a process the business thinks it owns but actually lives inside a person. The most common dependencies in service businesses:

• The owner who is the only one who can handle a difficult client situation
• The senior team member who is the only one who knows the correct order to prep for the day
• The person who "knows the system" and everyone else waits for them
• The informal decision-maker who smooths over conflicts and interprets policy

Every business has these. The question is whether you are building toward fewer of them or more.

Why Dependencies Form

Dependencies form because competence concentrates naturally. The person who is best at something gets more of that thing to do. They get faster. They develop judgment. Their version of the process becomes the standard — but it lives inside them, not in the documented process, because nobody stopped to capture it.

This is not a flaw in the people. It is a flaw in how the organization treats knowledge. When knowledge is not deliberately captured and distributed, it concentrates in the people who acquire it. And concentrated knowledge creates dependencies.

What a Survivable Workflow Looks Like

A workflow that survives the people in it has four characteristics.

It is specific enough to follow. Not "check in with clients when they arrive" but what that means, what it requires, how it should feel to the client, what to do when the standard situation is not the situation. Vague workflows do not guide behavior — they leave behavior to individual interpretation, which is how inconsistency starts.

It includes the judgment layer. The most common failure in workflow documentation is capturing the steps without capturing the decisions embedded in those steps. A good workflow documents not just what to do but when to do the non-standard version, how to tell the difference, and who to involve when a situation is outside the documented scope.

It is tested by someone who did not write it. The person who documented the workflow already knows it. The only reliable test of a workflow is whether someone unfamiliar with it can execute it at an acceptable standard.

It is reviewed on a schedule. Workflows go stale. A quarterly review of core workflows is not overhead — it is how you keep the documented process aligned with the actual process.

The Hardest Workflow to Fix

The hardest dependency to address is the one that lives in the owner.

I have seen this in almost every service business I have worked with at some stage. The owner has become the workflow for certain critical functions — often the highest-stakes ones: handling an upset client, making a pricing exception, deciding when to offer a refund or a redo.

These need to become explicit processes. Not to remove the owner from judgment — some decisions will always require the owner — but to distinguish between the decisions that genuinely require owner judgment and the ones that have been defaulted to the owner because no documented process exists. When I built Valet Operations Labs — the operations platform that grew out of my own systems — one of the first things I did was ask: which of these functions need to survive me? That question forced the documentation. And the documentation forced the clarity that made the business more consistent — and eventually, more scalable.