Assignee

Work decided in a meeting often sits untouched until the next meeting. The agreement in the room was real. Someone named the problem, someone described what had to happen, everyone nodded. No name got attached to it.

Pagedeck lived through exactly that. Permission checks were slow when a document was shared by link, the topic came up, and the conversation ended with "could someone take a look at that part." Two weeks later the same complaint came back. Theo had assumed Noa was cleaning up the screen first; Noa had assumed the server side was being checked first. Nobody was lazy. Neither of them had ever thought of it as theirs.

The assignee field turns that gap into a record. It isn't a new rule so much as an existing agreement written down where people can see it. What to do goes in the title and description, when it's wanted goes in the due date, and who would do it went nowhere at all — it stayed in the room. A week later, an agreement that only lives in memory is remembered differently by each person who was there.

One item, one name, and that person pushes the item until it closes. What gets decided here isn't how the labor splits. It's who drives.

1. Only one name goes in. Put three in and all three assume one of the others will start, so nobody does. When several people genuinely have to touch the work, split the item instead of lengthening the list — break it into subtasks and give each piece one owner, and every piece is back to a single name.
2. Owning an item doesn't mean doing all of it alone. The assignee surfaces blockers, pulls in help when help is needed, and decides when the work is finished. An item that needs both a design review and a server change still has one assignee, and that person watches for the moment the two halves have to meet.
3. There's a point where the field has to be filled. It can be empty at creation. But by the time the workflow status — the value saying which stage the item currently sits in — moves to in progress, a name belongs there. Items sitting in progress with no name turn out, a few days later, to be items nobody touched.
4. Handoffs come with words. Change the name alone and the new owner learns about it from a notification, then has to read backward through the history to find out where things stand. A one-line comment about what's done and what's left costs far less time than that reconstruction.

An empty field is information too. An item with no assignee is an item nobody has started, and empty fields piling up in the in-progress column mean the board has drifted away from what is actually happening.

The value earns its keep in roughly four places.

1. Seeing load pile up on one person — filter the board by assignee and you see how many items each person is holding at once. Someone carrying seven in-progress items moves all seven a little and finishes none. The loss that comes from jumping between unrelated work is called context switching, and without this field there's no way to see whose week it is accumulating in.
2. Routing notifications — tools notify the assignee first. A new comment or a status change shows up on that person's screen. With the field empty the notification reaches nobody, and broadcasting to a whole channel instead means everyone reads it and nobody moves.
3. Asking about progress in a meeting — instead of walking the board item by item, walk it person by person. Grouped by person, what someone is stuck on becomes visible in one pass. Grouped by item, all you notice is the same name coming up repeatedly.
4. Separating kinds of involvement — for a team using RACI, the grid that splits a decision into responsible, accountable, consulted and informed, the assignee is the responsible one. Reviewers and approvers are different people, and their names belong in the reviewer or approver field, not this one.

"This ticket has no assignee — does anyone want to take it?"

Without a name on it, this item isn't going to move.

"Put me down as the assignee and I'll check the server side with Theo separately."

Not a claim to do all the work, but a commitment to see the item through.

"You reassigned it without telling me, so I only saw it this morning."

Moving the name is not the same as handing the work over.

At Pagedeck the field moves most often when somebody is about to be away. The day before Theo's vacation starts he goes through everything with his name on it and hands off only what has to move that week. He doesn't just swap names — each item gets a comment line: waiting on the customer's answer, or screen is done and only the server wiring is left. The rest keep his name and simply shift to a paused status. Clearing the name would mean that when he's back, finding out who was where in each item takes another round of digging.

The team also checks for unassigned items before standup ends. Mia filters the board by "no assignee" and shares the screen, and each one either gets a name on the spot or drops out of the cycle. Dropping it is recorded too, so two weeks later nobody has to ask why it never happened.

The most common misreading is that the assignee is the person who does all of it alone. One name in the field makes that a natural assumption. What the assignee actually carries is not the labor but the responsibility for progress. When that distinction blurs, nobody wants their name on items that need several people cooperating — and those are precisely the items that then sit for weeks. Asking "who would notice first if this stalled" rather than "who will do every part of this" usually settles the question quickly.

The other common reading is that the assignee is who gets blamed if it goes wrong. The word carries a faint smell of fault, so this happens easily. Once a team uses it that way, people put their names only on work they're confident about and leave the hard or ambiguous items blank — which empties the field exactly where it was most needed. The assignee decides where questions get sent. Why something went sideways is a separate conversation, held afterward.