Why tasks stall between people

Ask why a piece of work is late and you will usually be told about the person holding it.

That is almost never where the time went. The time went in the gaps between people — the intervals when a task had been finished by one person and had not yet started with the next, because the next person did not know it was theirs.

The three kinds of stall#

Nobody knows it is theirs. The most common by a wide margin. The work moved on and the notification did not, or arrived somewhere nobody looks.

Everybody thinks it is somebody else's. A task with two names on it and no statement of who acts. Diffusion of responsibility is not a failure of character; it is what happens when a system permits ambiguity. The same thing at the scale of a project is one project, many contractors, where the delay sits in the handover between two trades rather than inside either.

Somebody knows it is theirs and is blocked. The only one of the three that is visible, and consequently the only one that gets managed.

Most attention goes to the third. Most of the delay is in the first two.

The stall nobody can report#

A document was sent for signature in our own system. It sat there. The person who had to sign it did not know they had to sign it.

They were not ignoring it, and they had not missed a message. The message had arrived exactly as the system intended, and the way the system intended was wrong. The request went out carrying a generic type — question — which had been mapped, sensibly enough, onto the row for comments in the notification grid. That row's default delivery is a digest: held back until the next scheduled broadcast, ringing nothing, arriving as one line among a dozen others that did not need doing right now.

A document holding up a payment was delivered as chatter. The full account is filed as chatter.

The important part is why nobody reported it. The person who had to sign did not know there was anything to report — from where they stood, nothing had happened. The person who sent it assumed it had landed, because sending it produced no error. Both held a completely consistent picture of the day, and the two pictures did not overlap at the point where the work was stuck.

That is the most durable kind of stall. It has no owner because nobody experiences it as a problem.

What a request has to say#

The useful question about any handover is not how important it is. Everybody's own work is important, and a priority scale where everything is at the top is not a scale.

The useful question is what it asks the reader to do, and there are only three answers:

• Nothing. You should know this happened. Read it whenever.
• Later. Look at this next time you are looking at things.
• Now. Somebody is standing still until you act.

A signature request is always the third. It is not information about work; it is a request for a specific person's hand, and until that hand moves a document, a payment and usually another human being are all stopped.

Classify by what is being asked rather than by how important it feels, and the routing follows without anybody having to argue about priority. The wider argument is in an alert that rings for everything.

Make the waiting visible from both ends#

A stall persists because it is invisible to the two people best placed to end it.

The person waiting often cannot see what they are waiting on — only that nothing has happened. The person holding it cannot see that anybody is waiting.

Two cheap fixes cover most of it.

A standing statement on the work itself, in plain words: what it is waiting for, who it is waiting on, and how long it has been waiting. Not a status code. A sentence. We added exactly this to every task in our own system after watching people ask the same three questions in meetings that a line of text could have answered.

A view of what is waiting on me, that is genuinely complete. Incomplete is worse than absent, because a list that misses things teaches people they still have to check everywhere else, and then they stop using the list.

The pause that nobody owns#

There is a specific structural stall worth naming: the interval where a task has left one stage and not yet entered the next.

Approved but not yet issued. Signed but not yet filed. Received but not yet booked. Ready but not yet started.

These intervals have no assignee by definition, and most systems represent them as a status rather than as somebody's work. So no queue contains them, no reminder covers them, and they can last indefinitely without appearing anywhere as late.

The fix is to make every state have an owner, including the transitional ones. If the answer to "whose is it right now" is "nobody's, it is between stages", the process has a hole and the hole will fill with time. Where the next actor is outside the company altogether, that owner belongs in a different system — a CRM and a task system are not the same thing.

Chasing is a finite resource#

The instinct once stalls are visible is to add reminders. It works briefly.

A reminder that is occasionally wrong teaches people to skim the whole class of reminder, and once they skim it, the one that matters costs the same as the ones that do not. We watched a chaser ring our finance team every few days about money that had already left the account, because of a stale field elsewhere in the system. Nobody reported it. They just stopped reading that kind of message, and the credibility spent was not spent only on that chaser — it was spent on every chaser in the building.

So: fewer, better-targeted, and correct. A chasing system's accuracy is not a nice-to-have. It is the whole asset.

The short version#

Work stalls in the gaps, not in the hands.

Classify requests by what they ask a person to do, give every state an owner including the transitional ones, put a plain sentence on the work saying what it is waiting for, and keep reminders rare enough and right enough to still be read.

And when something has been stuck for a month, look first at how the request was categorised on its way to the person who was supposed to act on it. The answer is usually a row in a routing table, not a failure of diligence.