The task claim: a small lock that saves a standup

Two people pick up the same task. Nobody notices until one of them mentions it, usually the next morning, usually in the meeting that exists largely to catch this. Everyone laughs, someone drops their version, and an afternoon is gone.

This is treated as a discipline problem, people should communicate more, and so the fix is always another ritual. A better fix is to make the state visible at the moment the decision is made.

Polite claims do not hold

The soft version of this is an assignee field. Anyone can set it, anyone can change it, and it is frequently stale because nothing forces it to be true. An assignee says who is supposed to do the work. It does not say who is doing it right now, and those are different questions.

What you want to know, standing in front of a board at 9am, is the second one. A field that answers the first question while looking like it answers the second is worse than no field, because it is believed.

The cost of the duplicate

It is tempting to treat duplicated work as a minor embarrassment, but the bill is larger than the hours involved.

There are the hours themselves, doubled. There is the discard, which is nobody's favourite afternoon and does real damage to whoever loses the coin toss. There is the review load, because two implementations of the same thing arrive and someone has to arbitrate. And there is the quiet cost: the next time, both people hesitate before picking anything up, because starting has become socially risky.

That last one is the expensive part, and it is the reason "communicate more" is such a weak fix. It asks people to carry coordination in their heads and then blames them when the memory fails.

Make it hard, and make it expire

So in Timato a claim is a lock. One person holds a shared task at a time. Starting a timer on it takes the claim; you cannot take one someone else holds, and the interface tells you who has it rather than quietly failing.

Two properties matter more than the lock itself.

A claim expires. Somebody claims a task on Thursday, gets pulled onto an incident, and forgets. If the claim outlives the intent, the lock becomes the thing people work around, and a workaround is how a feature dies. Claims release themselves when the work stops.

A claim is releasable by anyone with the right to. An admin can take one back. Locks that only their holder can open create a support queue, and the person who can fix it is always on holiday.

What it does not do

A claim is not a performance signal. It is not stored as a record of who did what, it does not roll up into anybody's totals, and there is no report of who claims the most. The moment a lock becomes a scoreboard, people start claiming defensively, and a coordination tool turns into a status game.

It also does not stop two people working on the same thing deliberately. Pairing is fine. The claim tells you the task is in hand; it does not tell you to go away.

The part we did not expect

The obvious benefit is less duplicated work. The one we did not predict is that the standup got shorter, not because the meeting changed but because the question it mostly answered had already been answered.

"What is everybody on?" is a question a board can answer if the board is honest. Making it honest cost us one database constraint and an expiry job. It is not a clever feature. Most of the useful ones are not.

Why a lock and not a convention

Every team that has ever had this problem has tried the convention first: say in the standup what you are on, move the card before you start, drop a message in the channel. Conventions work until the day someone is in a rush, which is also the day the duplicate happens.

The difference between a convention and a constraint is what happens under pressure. A constraint costs the same on a calm Tuesday and a bad Thursday. A convention costs more exactly when you have least to spare, which is why it fails in precisely the conditions it was designed for.

That is the entire argument for making the claim a server-side lock rather than a shared expectation. Not because people are careless, but because the cheapest moment to record an intention is the moment you act on it, and starting a timer is already that moment. Nobody has to remember anything.

The small print that makes it liveable

A hard lock is easy to get wrong in the other direction, and a coordination feature that becomes an obstacle gets routed around within a week. Three things keep it honest.

Starting the timer is the claim. There is no separate button, because a separate button is a convention again.

The claim releases itself. When the work stops, the task is free. Nobody has to remember to unclaim, which is fortunate, because nobody would.

Somebody can always break it. An admin can release a claim. There is no state a team can get into where the tool is holding their work hostage and the only fix is a support email.

What it is not, again

It is not a record of who did what. It is not visible after the fact, it does not appear in anyone's totals, and there is no report ranking who claims most. The moment a lock becomes a scoreboard, people claim defensively, grabbing tasks to look busy, or avoiding claims to stay off a chart, and you have traded a coordination problem for a political one.

Small lock, short life, no memory. That is the whole feature, and it is the cheapest standup minutes we have ever bought.