Every team has a ritual for status. A Monday standup, a Friday update, a spreadsheet a lead fills in before the exec review. Each one takes time, and each one is out of date almost as soon as it is written.
That is not a discipline problem. It is a design problem: the tool that holds the plan cannot see where the work actually happens.
Where the truth actually lives
A delay is mentioned in a chat thread on Tuesday. A decision is made in a meeting on Wednesday. A pull request is merged on Thursday. None of it reaches the ticket until someone remembers to update it, usually right before they are asked.
So the plan and reality drift apart all week, and the status update is an attempt to stitch them back together by hand.
Three reasons manual status fails
- It is late by design. Status is reported after the fact, on a schedule, not when things change.
- It is a tax on the wrong people. The engineers and designers doing the work are the ones asked to describe it, which is the least valuable thing they could be doing.
- It hides the impact. “Auth is delayed” is a fact. Which other tasks move, and whether the launch moves, is the part that matters, and a text update rarely says.
Build status from activity instead
The alternative is to treat activity as the source of truth. Chat messages, commits, pull requests, and meeting transcripts already describe what happened. A system that reads them can keep the plan current without anyone typing a report.
That only works with two safeguards. First, the system must show its evidence: every claim links to the message or commit behind it. Second, it must not change the plan on its own. It should propose the change and let a person approve it.
What changes for the team
Leads stop chasing updates and start reviewing proposals. Engineers stop writing status and keep working. And the question “is the launch on track?” gets an answer that is true today, not true as of last Friday.
A checklist for teams that want to stop
- Find where status really comes from. List the places where work is discussed: chat channels, repositories, meeting calls.
- Link work to tasks. Use task IDs in branch names and commit messages, and link important chat messages to the task they are about.
- Make dependencies explicit. A status that says “delayed” is only useful if you know what is waiting on it.
- Replace the weekly update with a weekly review. Instead of writing status, spend the time deciding on the changes the activity suggests.
- Keep a human in the loop. Automated status should propose changes, never apply them silently.
Common mistakes
The most common mistake is automating the report instead of the truth. A bot that summarises tickets once a week still summarises stale tickets. The second is trusting summaries without sources: if a status line cannot point to the message or commit behind it, nobody can check it.
This is the idea behind Keel. It reads the work your team already does, keeps the plan true, and tells you what is slipping and why. See how the loop works.
