In short
Real ownership requires three things to be named together: who decides, who does the work, and by when the decision is due. Most accountability failures are missing the third. Assign ownership at the level of outcomes rather than tasks, give every owner the authority and access to act without escalation, and write down the default that applies when the owner does not respond in time. If nothing happens when an owner goes silent, you do not have an owner — you have a bottleneck with a job title.
Key takeaways
- Shared ownership is unowned. Two names on a responsibility means the work waits for whoever feels guiltiest.
- Ownership without authority is a trap: you have made someone accountable for something they cannot control.
- Every decision needs a due date and a stated default for what happens if it is missed.
- Assign owners to outcomes, not to tasks. Task owners optimise their step; outcome owners fix the whole flow.
- The test of ownership is what happens when the owner is silent, not what happens when they are engaged.
Why work stalls between people who are all working hard
Watch a piece of work move through a business with an ownership problem and the pattern is always the same. The work is completed promptly at each step. The gaps between the steps take days.
This is why the usual response — asking people to be more proactive, or adding a status meeting — produces so little. Nobody is being slow at their job. The delay lives in the space between jobs, and that space has no owner, so nobody is being slow at anything.
The work is fast. The seams are slow. Adding effort to the work does nothing to the seams.
Three species of ownership failure
| Failure | What it sounds like | What is actually missing |
|---|---|---|
| Diffused | “I assumed operations had picked it up” | A single name against the outcome |
| Hollow | “It's my responsibility but I can't approve it” | Authority and access matched to the accountability |
| Untimed | “It's with legal” (for the ninth day) | A due date and a stated default |
The third is the most common and the least discussed. A great many businesses have correctly assigned owners for everything and still move slowly, because ownership without a clock is a queue with a name on it.
Assign owners to outcomes, not tasks
The single highest-leverage change is choosing what to assign ownership over.
Task ownership sounds precise and behaves badly. If Amara owns “send the onboarding pack” and Ben owns “schedule the kickoff call,” both can be fully compliant while a client sits unattended for two weeks between the two. Each optimises their own step. Nobody is responsible for the distance between them.
Outcome ownership fixes this by definition. If Amara owns “a new client is productive within ten working days,” then the gap between the pack and the call is inside her remit, and she will notice it, because it is the thing she is measured on.
How to phrase an outcome
A well-formed outcome has a subject, a state, and a boundary:
- “Every invoice raised in the month is issued by the third working day of the next month.”
- “Any inbound enquiry receives a substantive human response within one working day.”
- “No production system has an unreviewed access grant older than 90 days.”
Compare those with “owns invoicing,” “owns the inbox,” “owns access management.” The second set can be satisfied by anyone who touches the thing occasionally. The first set can only be satisfied by someone who is watching the whole flow.
One name, always
Co-ownership feels collaborative and is corrosive. When two people share an outcome, the honest description is that the outcome is owned by whoever has the lowest tolerance for it being unfinished, which is a terrible way to allocate work and an unpleasant experience for that person. If a genuine partnership is required, name one owner and one named contributor. The distinction costs nothing and eliminates the ambiguity.
Ownership without authority is a trap
The fastest way to burn out a capable person is to make them accountable for an outcome they cannot control. It happens constantly, usually with the best intentions.
For each outcome you assign, verify four things are actually in the owner's hands:
| Requirement | Test question |
|---|---|
| Access | Can they get into every system this outcome touches, at the permission level required, without asking? |
| Spend | Is there a threshold below which they can commit money without approval? Is it high enough to be useful? |
| Sequencing | Can they change the order of steps or reassign work within the flow? |
| Escalation | Do they have a named person who is obliged to respond when they escalate, with a time limit? |
If more than one is missing, you have not delegated the outcome. You have delegated the anxiety about the outcome.
A useful rule of thumb for spend authority: set the threshold so it covers roughly four in five of the decisions the owner actually faces. A limit that only covers the trivial cases converts every real decision into an escalation and quietly reinstates the bottleneck you were removing.
The access half of the problem
Access is where good ownership designs die silently. Somebody is given an outcome, discovers three weeks later that they cannot approve a refund or edit the template, and starts routing through whoever can. Within a month the original bottleneck has re-formed, and it now has an extra step in it. Audit access at the moment you assign ownership, not afterwards — this is the same discipline described in key person risk.
Put a clock and a default on every decision
This is the mechanism that converts an ownership map from a diagram into something that changes how fast the business moves.
For every decision point in a core workflow, record two things alongside the owner:
- Due within: how long the decision may take, in working hours or days, measured from when the request became complete.
- Default if missed: what happens automatically if the clock expires.
Defaults are the uncomfortable part, and the reason they work. There are only three honest options, and choosing between them forces a genuinely useful conversation about how much the decision matters.
| Default | Appropriate when | Example |
|---|---|---|
| Proceeds automatically | The cost of a wrong yes is lower than the cost of delay | Standard discount within policy; routine supplier renewal under threshold |
| Escalates automatically | The decision genuinely needs a human, but not necessarily that human | Contract variation; anything with a client commitment attached |
| Is declined and returns | Silence should be treated as a no, and the requester needs to know | Exceptional spend; policy exceptions |
What you may not choose is “it keeps waiting.” That is the current state, and it is the thing you are fixing.
Why this changes behaviour
A default converts silence from a neutral act into a decision with consequences. Owners respond to requests they would previously have left in the queue, because ignoring one now produces a visible outcome attributed to them. Almost every business that introduces defaults finds that the volume of decisions requiring the owner falls, because the trivial ones start flowing through automatically and everyone can see which decisions were actually load-bearing.
Mapping ownership in an afternoon
You do not need a governance framework. You need one table, filled in for your five or six core workflows.
Columns: Outcome · Owner (one name) · Decides what · Due within · Default if missed · Escalates to.
Fill it in with the relevant people in the room, and expect the exercise itself to be the value. Three things reliably surface:
- Outcomes with no owner. Usually the ones that fall between two functions, which is exactly where the delays were.
- Owners who did not know they were owners. Common, and mostly resolved by saying it out loud once.
- Owners who cannot actually decide. The hollow-ownership cases, which need an authority fix rather than a naming fix.
Then do the part most teams skip: publish it where the work happens, not in a governance folder. If the workflow runs in a project tool, the owner's name and the clock belong on the workflow. An ownership map that requires someone to remember it exists will be consulted twice.
Review it when the shape changes
Ownership maps go stale on structural events, not on a schedule. Revisit when you add a function, lose a person, take on a materially different client type, or change a system. Each of those either creates a new seam or moves an existing one.
What actually changes when ownership is real
The observable outcomes, in roughly the order they appear:
- Status meetings get shorter, because the question “where is this?” has an answer that does not require a meeting to produce.
- Escalations become rarer but more meaningful. The routine ones flow through defaults; the ones that reach a leader are genuinely ambiguous.
- Elapsed time drops before touch time does. Nobody is working faster. The waiting has been removed, which is where most of the delay lived — see the cost of operational friction for how to measure this.
- Blame conversations decline. When ownership was ambiguous, failure required a search for who was at fault. When it is explicit, the conversation is about the process, because everyone already knows who was accountable and it is not in dispute.
That last effect is the one people underestimate. Clear ownership is usually experienced as less pressure rather than more, because it replaces a diffuse sense that everything might be your fault with a specific, bounded, achievable set of things that definitely are.
If you want to know where ownership is missing before you map it, the Mayim Ops assessment scores ownership and accountability as one of ten dimensions and reports the specific seams where work is stalling between functions.
Frequently asked questions
What does operational ownership actually mean?
Operational ownership means one named person is accountable for an outcome, holds the authority and access required to deliver it, and operates against a stated deadline with a defined default for what happens if that deadline passes. Naming someone without giving them authority or a clock produces the appearance of ownership without the effect.
Why do tasks stall between departments?
Because the handoff between them was assumed rather than defined. Each department completes its own step promptly, so nobody is being slow, but the space between the steps has no owner and no deadline. Assigning ownership over the whole outcome rather than the individual tasks puts that space inside somebody's remit.
Is RACI the right tool for a small business?
RACI can work, but small teams usually get more from a simpler table: outcome, single owner, what they decide, how long the decision may take, and what happens by default if it is missed. The failure mode of RACI in small businesses is that it produces a matrix nobody consults, while the decision clock changes behaviour immediately.
Can two people share ownership of a process?
In practice, no. Shared ownership means the work waits for whoever has the lowest tolerance for leaving it unfinished, which allocates work by guilt rather than by design. If genuine collaboration is required, name one owner and one named contributor so the ambiguity is removed without removing the partnership.
What should happen if a decision owner does not respond in time?
One of three things, decided in advance: the request proceeds automatically, it escalates automatically to a named person, or it is declined and returned to the requester. Choosing between them forces a useful conversation about how much the decision actually matters. What must not happen is indefinite waiting, which is the problem being fixed.