An owner is a person, not a team
· 6 min read · by Tan Gravam
The short answer
Assign one named person as the owner of a demand, not a team. Ownership here means accountability for the decision - whether the work is understood, ready and worth committing to - which is a judgement a group cannot make. A team name looks like an answer and behaves like a blank: when the demand needs a call, four people each assume one of the others has it. The owner does not have to do the work, and does not have to be the manager; they have to be the person you would ask.
Owner: Platform Team.
That field is filled in. It passes every validation. It will be reported as complete on every dashboard. And when the demand needs a judgement call in week four, four people will each assume one of the others has it.
What ownership actually means here
The word is overloaded, so it is worth being precise about which sense matters at this layer.
Not "who does the work" — that is usually several people and changes over time. Not "who is responsible if it fails" — that is a blame model and produces the behaviour blame models produce. Ownership of a demand means: who is accountable for the decision — whether this is understood, whether it is ready, whether it is worth committing to, and what happens to it next.
That is a judgement, and judgements are made by people. A team can hold work. It cannot hold a judgement.
Why a team name is worse than an empty field
An empty owner field is honest. It says nobody has picked this up, which is information, and it shows up in every "what needs attention" view.
A team name is a blank that looks answered. It clears the validation, it satisfies the reviewer, and it removes the demand from every list of things missing an owner. The absence is now invisible, which is strictly worse than the absence.
This is the same pattern as a risk register filled with generic risks : the artifact looks complete, so nobody asks the question it exists to prompt.
The owner does not have to be senior, or the person doing it
Two objections come up, and both dissolve on inspection.
"The manager should own it." Sometimes. But a manager owning forty demands owns none of them; the field becomes a routing default and stops meaning anything. The useful test is not seniority — it is: who would you ask if you had one question about this? That person is the owner, whatever their title.
"But the work is done by the whole team." Yes, and that is unaffected. Owning the decision is not owning the keyboard. The owner's job is to know the state of the demand and to be the address for questions about it, which is a couple of minutes a week for most demands.
Naming a person makes the demand refusable
The under-appreciated effect. A demand owned by a team can drift indefinitely, because no individual is in a position to say "this is not ready" or "we should decline this" — that reads as speaking for the group.
A named owner can. They can park it, decline it, ask the requester for more, or say it is not ready to commit. Every one of those is an exit that a team-owned demand does not have, which is why team-owned demands accumulate rather than resolve.
If you want recorded noes , you need someone with standing to say one.
The same logic applies while a demand is stalled: someone has to own the chase, or waiting on an answer decays into never getting one .
Handover is the part everyone skips
Owners change: people move teams, go on leave, leave. The failure is not the change, it is that ownership transfers implicitly — the field still says a name, and that person no longer thinks about it.
A stale owner is worse than an empty one for the same reason a team name is: it suppresses the signal. Any review of open demands should be checking whether the named owner still recognises them as theirs, and that check takes seconds when the field holds a person and is impossible when it holds a team.
How DeliverySheet handles it
The owner is confirmed at the Decide stage rather than demanded at capture — early enough to be real, late enough that the demand is understood well enough to know who should hold it. It defaults to the person who captured it, which is usually right and is at least always a person.
An owner is required to leave the Shape stage, and that rule is enforced on the server rather than in the form, so it cannot be bypassed by a direct API call. The picker offers the workspace's actual people and teams, and typed text is adopted when no record exists yet — because a governance rule that requires you to first create an org chart is a rule people route around.
Where a team genuinely is the right answer — capacity per craft, a dependency needed from another group — the product asks for a team explicitly, in a different field. The distinction is the point: teams hold capacity and dependencies, people hold decisions.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$10/month per workspace during the launch period (normally $189), unlimited members, 7-day free trial. I answer the support email myself.
More on deciding what to commit to
Read the overview: How to decide what to commit to →
- What a decision-ready demand actually contains
Not a template to fill in — the six things that have to be established before a request can honestly become a commitment, and how to tell when one is missing.
- You will commit before you are ready. Make it cost four fields.
Banning early commitments does not stop them, it hides them. Recording them takes a minute and converts an invisible gamble into a decision with a name on it.
- Why delivery commitments slip before a single line of code
Most missed delivery dates are decided weeks before the work starts — at the moment a request becomes a commitment without anyone checking whether it was ready.