Status updates without chasing the team

Why do status updates keep going stale?

Because asking humans for status puts the cost of reporting on the people doing the work, at the exact moment they are busiest, and the answer you get back is written from memory rather than from the file.

Three things go wrong every time. The update arrives after the moment it would have been useful. It is optimistic, because people report intent rather than state. And it is expensive: a fifteen-minute weekly round across a team of eight costs more than the report is worth.

There is a fourth problem, harder to see. A manager who spends Thursday asking six people where things are at is spending credibility on something a query could answer.

The alternative is not a better meeting or a better form. It is deriving status from what already exists.

Which signals can you actually pull?

Only signals generated as a by-product of doing the work. If someone has to update something purely so the report can read it, you have reinvented the chase with extra steps.

That test rules out a lot, and it should. What survives it in most consultancies and agencies:

1. Task or board movement. When a card last changed column, when a task was last completed, how many are open past their due date. Only usable if the board is genuinely how the team works.
2. File and document activity. Last modified time on the working files for a project. A deck untouched for eleven days on a project due Friday is a real signal, and nobody had to record it.
3. Calendar. Meetings held, meetings scheduled, meetings cancelled. Cancelled client meetings are one of the earliest reliable indicators that something has gone quiet.
4. Time and cost. Hours booked this week against hours budgeted, and spend against fee. This one is available in almost every professional firm and underused.
5. Client correspondence recency. When you last exchanged a message with the client on this project. Long silences cut both ways, and both are worth knowing.
6. Delivery events. Your equivalent of publishing, shipping, lodging, sending or exchanging: the event that means a milestone actually happened.
7. Invoicing. Invoices raised and paid against the schedule in the proposal. Slow invoicing is often the first visible symptom of a slow project.

You do not need all seven. Three good ones beat seven mediocre ones. Pick signals that would move if the project moved, and would not move if it did not.

How do you turn signals into a status?

Define a small number of states with explicit thresholds, and let the rules decide. The states should be honest about uncertainty.

A workable set:

• Moving. Signals in the last few days, spend tracking to budget, nothing overdue.
• Slowing. No activity for longer than the threshold you set for this type of work.
• At risk. A deadline within a set window with no recent movement, or spend running ahead of progress.
• Blocked. Waiting on the client or on a third party, with a date recorded for when that started.
• Unknown. No usable signal at all. Not the same as fine.

Write the thresholds down and tune them per work type. Seven days of silence on a fast-turn social campaign is a problem; on a long compliance matter it is a Tuesday. A single global threshold produces so many false alarms that people stop reading.

Defend the unknown state when someone asks you to simplify. A project that has fallen out of every system is exactly the one you need to look at, and a design that reports it as fine will eventually cost you a client.

What do you still have to ask a human for?

One field, once a week, per project: how confident the owner is that it will land as promised. That is judgement, and no amount of signal derivation produces it.

Keep it to a single word: confident, watch it, or in trouble. If it takes longer than about ten seconds per project, people will do it carelessly, and you have introduced a new source of bad data.

Make the ask smart. Send people only the projects the signals flagged, not every project they own. A project the system already knows is moving does not need a human to confirm it.

The interesting reporting comes from disagreement. A project showing green on every signal that its owner has just marked "in trouble" is the most valuable line in the report, because someone knows something the systems do not. That is the conversation worth having.

How do you keep this from feeling like surveillance?

Build it at the level of projects, not people, and be completely open about what is collected. This is a design decision made at the start, not a communications problem solved afterwards.

The lines that matter:

• Report on work, not workers. "Project X has not moved in nine days" is management information. A per-person activity score is something else, and it will damage the team faster than the report helps.
• No individual activity metrics, no leaderboards, no aggregate scores per person. If a signal only makes sense as a measure of a person, leave it out.
• Tell the team exactly what is read. Every source, in writing, before it goes live. Anything you would not be comfortable explaining in a team meeting should not be in the build.
• Do not read message content. Recency of correspondence is a legitimate project signal. The contents of your team's messages are not a status input.
• Show the team the same report. A status system that only management can see reads as monitoring. One everybody sees reads as coordination.
• Check your obligations. Employee monitoring and privacy obligations in Australia vary by state and by circumstance. Confirm what applies to you before you build anything that touches individual activity.

Handled this way, most teams like it, because the alternative was being asked the same question every Thursday.

What does the report look like, and what breaks?

Short, exceptions only, and delivered where people already are. If the report lists every project, nobody reads past the first screen.

A good weekly output: projects at risk with the reason, projects blocked with how long and on whom, projects with no signal, and disagreements between the signals and the owner's judgement. Usually five to fifteen lines in a firm of ten. Everything else sits on a detail page.

The failures to instrument for:

• A connection breaks and a signal stops. Every project silently becomes "unknown". Alert on a sudden rise in unknowns rather than reporting them as findings.
• A team changes tools. Board migrations, new file storage, a different calendar. Status quietly degrades over weeks. Watch the proportion of projects with at least one live signal.
• Threshold decay. Work patterns change and the thresholds stop matching. Review them every quarter, or the report becomes noise and gets ignored.
• A project never enters the system. The most dangerous case, because it is invisible by definition. Reconcile against the projects you are invoicing.

What to do next

Pick your three signals and run the derivation for a fortnight without publishing the results. Then compare what the system thought against what actually happened. You will find your thresholds wrong in one direction and one of your three signals useless. That is the point.

Then publish the exceptions report to the whole team with the sources listed openly, and drop one status meeting. Keep the human confidence field: it catches what the systems cannot.

If you would rather have the pull built in your own accounts and handed over documented, that is a typical Shift build. The rule stands either way: build only on signals the work already produces, and never report silence as good news.