{"slug":"assign-owner","meta":{"title":"Assign an Owner","slug":"assign-owner","kind":"pattern","summary":"Exactly one named person is responsible for a record at any moment, visible on the record and filterable across the collection.","problem":"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?\"","family":["coordinate","workflow"],"data_shape":["record","collection"],"principles":["orientation","surface-dont-bury"],"interaction":["selection","decision"],"density":"low","complexity":"low","status":"stable","visibility":"public","use_when":["More than one person can act on the same records.","Items can sit without anyone noticing.","People ask \"who is dealing with this?\" out loud, and nobody can answer it."],"avoid_when":["One person does all of it. The field is noise.","The work is genuinely a pool that anyone picks from on demand — use a queue with a claim instead.","Assignment would be theatre, with no authority attached to it."],"alternatives":[{"slug":"review-queue","when":"Work should be pulled by whoever is free, not pushed to a named person."},{"slug":"handoff-workflow","when":"Ownership moves between teams at defined points, and the transfer is the important part."}],"ask_leo":"Add an owner to this record type.\n\n- One owner at a time, a real person, not a team. Watchers and collaborators\n  are separate fields — the owner is the one accountable.\n- Show the owner on the record header and as a column in the list, so\n  \"whose is this\" never needs asking.\n- Make the collection filterable by owner, and give people a one-click\n  \"assigned to me\" view. That view is what makes the field useful rather than\n  decorative.\n- Allow unassigned as an explicit state, show it distinctly, and surface how\n  many unassigned items exist. Unassigned work is the thing this pattern\n  exists to make visible.\n- Record every reassignment in the record's history with who changed it and\n  when.\n- Notify the new owner when something is assigned to them, and let them see\n  everything they own in one place.\n- When someone is deactivated, do not silently orphan their records. Surface\n  them for reassignment.\n","related":[{"title":"Activity Timeline","url":"/patterns/activity-timeline","summary":"Where reassignments are recorded, and how ownership disputes get settled."},{"title":"Lifecycle Status","url":"/patterns/lifecycle-status","summary":"Owner answers WHO; status answers WHAT NEXT. Most records need both."}]},"body":"## Anatomy\n\n```\n  Unassigned (4)  ← surfaced as a count: this is the point of the pattern\n  ─────────────────────────────────────────────────────────\n  JOB-118  Framing level 3      ○ Unassigned      6d old\n  JOB-121  Riser boarding       ● Dana            2d old\n  JOB-124  Second fix           ● Priya           1d old\n                                 ↑ one person, filterable, in the list\n```\n\nThree properties, and the third is the one that makes it work:\n\n1. **One person**, not a team. A team owner is the same ambiguity with a\n   different label.\n2. **Visible in the list**, not only on the record. Ownership you must open a\n   record to see cannot be scanned.\n3. **Unassigned is an explicit, counted state.** The value of the field is\n   almost entirely in making the gap visible.\n\n## Why it works\n\nDiffusion of responsibility is a real and well-documented effect: the more\npeople who could act, the less likely any individual does. Naming one person\nremoves the ambiguity that the effect depends on.\n\nThe \"assigned to me\" view is what converts the field from data into behaviour.\nWithout it, ownership is something you can look up; with it, ownership is a\nworklist, and people work their list.\n\nMaking unassigned visible and countable is the other half. In most teams the\nuseful number is not who owns what — it is **how many things nobody owns**,\nbecause those are the items that will surprise someone later.\n\n## Owner is not status\n\nThese get conflated and they answer different questions. **Owner is who; status\nis what next.** A record can be owned and blocked, unowned and urgent, owned and\nfinished. Folding them into one field — an \"Assigned\" status — loses one of the\ntwo answers, usually the one you needed.\n\n## Getting it wrong\n\n- **A team as the owner**, which reproduces the original problem.\n- **Multiple owners**, same.\n- **Owner only on the record**, so it cannot be scanned or filtered.\n- **Unassigned hidden or treated as an error state**, so gaps stay invisible.\n- **Assignment with no notification**, meaning the owner does not know.\n- **Assignment with no authority**, where the named person cannot actually\n  decide anything — this is the version that breeds cynicism fastest.\n- **Orphaned records** when someone leaves, discovered months later.\n\n## Exemplars\n\n**Linear** treats assignee as a first-class field with a keyboard shortcut and a\ndefault \"my issues\" view, which is why assignment is habitual rather than\nadministrative.\n\n**Intercom's conversation ownership** shows the pattern in a shared-inbox\ncontext: the assignment is what stops two agents replying to the same customer.\n\n**GitHub issues** demonstrates the counter-case honestly — assignment is\noptional and often unused on open-source projects, and the result is exactly the\ndiffusion this pattern prevents. It works there because the maintainers are the\nimplicit owners; in a business, implicit ownership is the problem.\n\nThe extractable rule: **the value of an owner field is the unassigned count.**\nIf nobody ever looks at what is unowned, the field is administration rather than\ncoordination.\n"}