Process owner

What ownership includes

• The outcome, not the activity. Owning 'leads are contacted within the standard' rather than 'the routing tool is configured'.
• Authority to change the steps, the standard and the supporting systems.
• The exception list: the owner sees breaches and decides what happens.
• The documentation, and its review date.

Why one name

Two names produce hesitation during a busy week, which is precisely when the process matters. Contributors can be many; accountability is singular. If ownership genuinely spans two functions, the honest fix is to split the process at the boundary and write a handoff contract between the halves.

How to test whether ownership is real

• The owner can change a step without asking permission from three people.
• The owner sees the exception list without requesting a report.
• When the process fails, the owner is the first to know rather than the last.
• The owner is named in the documentation, and the name is current.

If any of these fails, what exists is a reporter rather than an owner — and the process will drift back to its previous behaviour as soon as attention moves elsewhere.

The boundary discipline is in work leaks between teams.