Assign an Owner

Work that belongs to everybody belongs to nobody. A shared list gets read by four people who each assume one of the others has it, and the item sits until it becomes urgent — at which point the first question is still "whose is this?"

Anatomy

  Unassigned (4)  ← surfaced as a count: this is the point of the pattern
  ─────────────────────────────────────────────────────────
  JOB-118  Framing level 3      ○ Unassigned      6d old
  JOB-121  Riser boarding       ● Dana            2d old
  JOB-124  Second fix           ● Priya           1d old
                                 ↑ one person, filterable, in the list

Three properties, and the third is the one that makes it work:

One person, not a team. A team owner is the same ambiguity with a different label.
Visible in the list, not only on the record. Ownership you must open a record to see cannot be scanned.
Unassigned is an explicit, counted state. The value of the field is almost entirely in making the gap visible.

Why it works

Diffusion of responsibility is a real and well-documented effect: the more people who could act, the less likely any individual does. Naming one person removes the ambiguity that the effect depends on.

The "assigned to me" view is what converts the field from data into behaviour. Without it, ownership is something you can look up; with it, ownership is a worklist, and people work their list.

Making unassigned visible and countable is the other half. In most teams the useful number is not who owns what — it is how many things nobody owns, because those are the items that will surprise someone later.

Owner is not status

These get conflated and they answer different questions. Owner is who; status is what next. A record can be owned and blocked, unowned and urgent, owned and finished. Folding them into one field — an "Assigned" status — loses one of the two answers, usually the one you needed.

Getting it wrong

A team as the owner, which reproduces the original problem.
Multiple owners, same.
Owner only on the record, so it cannot be scanned or filtered.
Unassigned hidden or treated as an error state, so gaps stay invisible.
Assignment with no notification, meaning the owner does not know.
Assignment with no authority, where the named person cannot actually decide anything — this is the version that breeds cynicism fastest.
Orphaned records when someone leaves, discovered months later.

Exemplars

Linear treats assignee as a first-class field with a keyboard shortcut and a default "my issues" view, which is why assignment is habitual rather than administrative.

Intercom's conversation ownership shows the pattern in a shared-inbox context: the assignment is what stops two agents replying to the same customer.

GitHub issues demonstrates the counter-case honestly — assignment is optional and often unused on open-source projects, and the result is exactly the diffusion this pattern prevents. It works there because the maintainers are the implicit owners; in a business, implicit ownership is the problem.

The extractable rule: the value of an owner field is the unassigned count. If nobody ever looks at what is unowned, the field is administration rather than coordination.

Ask Leo for this

Paste this into your Leo chat. It describes the behaviour, not the code, so Leo can fit it to your data.

Prompt

Add an owner to this record type.

- One owner at a time, a real person, not a team. Watchers and collaborators
  are separate fields — the owner is the one accountable.
- Show the owner on the record header and as a column in the list, so
  "whose is this" never needs asking.
- Make the collection filterable by owner, and give people a one-click
  "assigned to me" view. That view is what makes the field useful rather than
  decorative.
- Allow unassigned as an explicit state, show it distinctly, and surface how
  many unassigned items exist. Unassigned work is the thing this pattern
  exists to make visible.
- Record every reassignment in the record's history with who changed it and
  when.
- Notify the new owner when something is assigned to them, and let them see
  everything they own in one place.
- When someone is deactivated, do not silently orphan their records. Surface
  them for reassignment.