Nothing shows how long a state has been true

An asset moves to Needs Review on Monday afternoon. It is reviewed on Thursday. The review took nine minutes. The other three days are not recorded anywhere, because nothing was happening in them and nothing that is not happening leaves a trace.

Nobody recorded the wait because a wait is not an event. Systems log what happens. Three days of nothing happening is not something to log, so it leaves no trace at all.

Multiply that across a campaign and the arithmetic gets uncomfortable. The work took hours. The campaign took five weeks. Nobody can point to where the difference went, and in the absence of an explanation the usual conclusion is that people are slow.

The time is in the gaps, and the gaps are unmeasured

Ask where a delay came from. The honest answer is usually a handful of intervals, none long enough to feel like a problem on its own. A day before someone opened the notification. Two days because the person who could approve it was travelling and nobody else knew they could. An afternoon because the asset was ready and the person waiting for it was not told it was ready.

None of those intervals appears in a status view. A board shows five things in Needs Review. It does not show that four arrived this morning and one has been sitting there since a week last Tuesday.

That is not a reporting gap. It changes what a team can act on. A count of five tells you the volume. It does not tell you which one is stuck, and stuck is the only category that needs anyone to do anything.

The category answers this with more messages

Read what is written about approval delays and the answer is consistent. Automated reminders. Escalation when a deadline passes. A dashboard of pending items. Service levels for turnaround.

Every one of those is a push. Each assumes the system knows who needs telling. That holds inside a fixed team. It fails the moment the work involves a freelancer, an agency and someone covering a leave. The person who needed to know was not on the list, because nobody thought to add them to something set up before they arrived.

More messages also decay. A channel that fires on every state change gets muted within a month. After that the notification is not a signal. It is noise that happens to contain one.

A state that is legible does not need announcing

The alternative is not a better notification. It is making the state readable where the work already is. The person who needs it finds it when they look, instead of being told when the system guesses.

That inverts the burden. A push has to reach the right person at the right moment, and it fails on both counts regularly. A visible state only has to be true. Anyone who opens the asset gets the answer, including the people nobody would have thought to notify.

The part still missing is duration. Even a legible state answers what, not how long, and how long is what separates a queue from a blockage. A team that could see the age of each state would stop asking who is slow. It would ask what has been waiting since Tuesday. That question has an answer and a next action attached to it. The first one has neither.

Where this applies

A team of three in one room does not need this, because the state is legible by looking up. Neither does work that moves in one pass with no waiting in it. It matters where handoffs cross organisations and the people involved change between campaigns. It matters most where nobody can say from memory what is currently waiting on whom, and where that question comes up every week.