A process nobody owns is not a process

Ask an owner whether their company has documented processes and you will often get a yes, followed by a link to a folder. Open the folder and the documents are real. Someone wrote them, usually during a period when the company was trying to get organised.

Then ask a second question: for each of those processes, who owns it?

The answer is where the trouble starts. Not because nobody knows — usually several people have a view — but because the views differ, and the differences have never had to be reconciled. The process has been running on the overlap between them.

Documentation is not the same as ownership

A document describes what should happen. Ownership decides what happens when it doesn’t.

Those are separate properties, and only one of them is load-bearing. A process with clear documentation and no owner will run fine for as long as conditions stay ordinary. The first time an input arrives in an unexpected shape, the document has nothing to say, and the process falls back to whoever notices. Usually that is the owner of the business, which is precisely the dependency the documentation was supposed to remove.

A process with a real owner and thin documentation behaves differently. The exception gets handled, and then — if the owner is doing their job — the handling gets written down. Documentation accumulates as a by-product of ownership. It does not work in the other direction.

What ownership actually requires

Ownership is a specific thing, not a name in a column. A process owner needs four things:

Authority to change it. If the owner has to escalate every adjustment, they are a monitor, not an owner, and the escalation path is the real process.

Visibility of its output. Someone who cannot see whether the process worked cannot be accountable for whether it worked.

A definition of done. Clear inputs, clear outputs, and a stated condition for success. Without this, “owning” the process means being blamed for it, which is why people decline the role when asked directly.

Time. Ownership that exists only in the gaps between other work is ownership in name.

Most process ownership in small and mid-sized companies fails on the first or the fourth, and the failure is invisible in the org chart.

Why this is the growth constraint

A business is a value chain: a sequence of processes that creates value for paying customers and supports the company’s sustainability, growth, and prosperity. Growth adds volume and variety to every link in that chain.

Volume is survivable. More of the same thing running through a process that works is mostly a staffing question. Variety is what breaks things — more exceptions, more edge cases, more inputs that the original design never anticipated.

Every exception has to be resolved by someone. If the process has an owner, it gets resolved locally and the system learns. If it doesn’t, it routes to the owner of the business. This is the mechanism by which growth produces noise instead of freedom: not because the owner is doing too much work, but because they have become the exception handler for the entire value chain.

The test

There’s a quick diagnostic that cuts through a lot of conversation.

Pick a process. Ask what happened the last time it produced an unexpected result. Not what should have happened — what actually happened, the last time.

If the answer names a person who noticed, decided, and adjusted the process afterwards, it has an owner. If the answer is that it got escalated, or that someone caught it, or that it worked itself out, the process is running on ambient attention. It will hold until it doesn’t.

Before automating anything

This matters more, not less, when AI enters the picture.

Automation applied to an owned process removes work: the owner has already defined the inputs, the outputs and the exception path, and automation executes that definition faithfully. Automation applied to an unowned process removes the ambient attention that was quietly holding it together, and replaces it with a system that executes confidently and wrongly.

The order is not negotiable. Map the process, give it an owner, watch it handle an exception, and then automate what is genuinely repeatable. Doing it in the other order is how a company ends up with faster versions of its own mistakes.

A process nobody owns is not a process. It is an assumption — and assumptions are what break first under growth.