Project management without status updates.

In most project tools, a board or dashboard is only as accurate as the last person who remembered to update it. Status is a field someone edits, separate from the work it describes.

That separation is the source of the drift. The update competes with the work for attention, it happens later than the event it records, and it depends on the person least likely to have time: whoever just finished something and moved on. So teams add meetings, check-ins, and reminder messages to reconstruct what the tool was meant to show.

Most meaningful changes in a project are already actions someone takes: passing work to a colleague, sending it for review, approving it, requesting changes, or asking another team for help. Each of those is a fact about the project's state.

If the tool records those actions as structured events rather than as edits to a field, the project's state can be derived from them. Nobody writes “with design for review”; the review request says so. Nobody marks something approved; the approval does.

Event-driven status works best where work moves between people in recognisable steps, and where the main question is “who has it and what happens next?” rather than “how far along is it?”

Events describe movement, not meaning. A project can show every handoff accurately and still be at risk, because the scope is wrong, a dependency is late, or the work is moving but not in the right direction.

Some things still need a person to say them: whether a deadline is realistic, why a decision was made, what the trade-offs are, and when priorities change. The goal is not to remove those conversations. It is to stop spending them on questions the work could have answered, so there is time left for the ones it cannot.

You do not need new software to reduce status chasing. These habits move a team toward work that reports itself.