Stop chasing people for updates

Somewhere in your week there is a block of time you have never accounted for. It is not in your calendar and it does not appear on anyone's workload report. It is the twenty or thirty times you typed some version of “hey, any update on this?”

Managers tend to treat this as a discipline problem — theirs or their team's. If people updated things properly, the chasing would stop. So they introduce a Monday stand-up, or a Friday status email, or a rule that every ticket must be updated before close of play. Within about five weeks, the chasing is back.

It comes back because chasing is not a symptom of laziness. It is a symptom of asking the question in the wrong place.

The question and the work live in different buildings

Consider what actually happens when you ping someone in chat. You type a question that has almost no context in it, because the context is somewhere else — in a task, a document, a thread from three weeks ago. The other person has to reconstruct that context before they can answer. They are probably mid-something, so they either break their focus to do that reconstruction, or they leave it for later and it silently becomes a thing you will have to ask about twice.

Say they answer straight away. Now the answer exists in a scroll. It is not attached to the work it describes. Nobody else who needs it will find it, and in eleven days neither will you. When the same question comes up — from a client, from your own manager, from you — the entire exchange happens again from scratch.

Chat is an excellent medium for conversation and a catastrophic one for record. The problem is that a status update is both.

This is the mechanism. You are not chasing because your team is unreliable. You are chasing because the previous answer evaporated, and the only tool you have for retrieving it is another question.

Three fixes that don't work

The recurring status meeting. It converts thirty scattered interruptions into one scheduled interruption, which feels like an improvement and is, marginally. But it also sets the maximum age of your information at one week, and it costs eight people an hour to transmit updates that six of them did not need. Worse, it teaches the team that the official moment for surfacing a problem is Monday at ten, which is precisely the incentive you do not want on a slipping deadline.

Mandatory daily updates. You will get compliance, and compliance is not information. “Still working on it” satisfies the rule perfectly while telling you nothing. You have added a chore to everyone's day and are no better informed.

A dashboard of self-reported percentages. This is the one that feels like the real answer, and it is the most quietly damaging of the three — but it needs its own argument, which is over here.

What actually changes the pattern

The fix is not a new ritual. It is moving the question to where the work is, so that answering it once is enough.

Three things have to be true at the same time. Miss any one and the chasing returns.

• The question carries its own context. Ask on the task, not in a channel. The person receiving it is already looking at the thing you are asking about, so the cost of answering drops from “reconstruct and reply” to just “reply”.
• It is asynchronous but addressed. A mention on the work is directed at a specific person without demanding their attention this second. It waits. A chat message does the opposite: it demands attention now and then disappears.
• The answer stays with the work. This is the part that compounds. Six months later the exchange is still sitting on the task, in order, next to the decision it explains — rather than in a scroll that has aged out of your plan's retention window.

Separate the logbook from the conversation

There is a second-order mistake worth naming, because most tools make it for you. They give you one comment box and let it absorb three different kinds of writing: what someone learned, what a group agreed, and what the system recorded. Compress those into one stream and all three become unsearchable — you end up scrolling past chatter to find a decision.

Keeping them apart costs nothing at the moment of writing and pays back constantly:

• Notes — the running logbook of how the work was actually done. The finding, the spec that turned out to be wrong, the vendor limit that changed the approach, the option you rejected and why. Written while you work, because that is the only time anyone will ever write it.
• Comments — the conversation. Who confirmed what, the open question and its resolution, the mention that unblocked someone.
• History — what the system observed. When it slipped, what was approved, what was rejected and on what feedback. Nobody writes this one; that is the point.

The test for whether you have this right is simple. Someone goes on leave unexpectedly. Can the person picking up their work reconstruct where things stand from the record alone, without a handover meeting? If the answer is no, your team has been keeping its real status in a place you cannot query — and you will keep chasing, because chasing is the only interface that place has.

The trade-off, stated honestly

This asks something of people. Writing a note at the moment you learn something is a habit, and habits take a few weeks to install. For the first fortnight it will feel like overhead, because the payoff — not repeating an hour of work in three months — has not arrived yet.

It also will not fix a genuine performance problem. If someone is not doing the work, moving the question onto the task will make that visible faster, which is useful, but the conversation you then have is a management conversation and no tool has ever had one of those for you.

What it does fix is the far more common case: capable people, working hard, whose progress is invisible to everyone except themselves. That invisibility is what you have been compensating for with all those messages. Remove it, and the messages stop being necessary — which is a considerably better outcome than getting better at sending them.