Status updates are a tax on your best people

It’s Friday afternoon, and your most productive coder is writing a status report. They’re summarising a week of work that already exists in tickets, pull requests and comments, for readers who will skim it at best. Most weeks, nobody reads it at all.

The report looks like a small ask. It’s a tax, and it lands hardest on the people whose time you can least afford to lose.

The tax falls on the wrong people

Nobody hands the weekly update to the newest member of the team. It goes to whoever understands the work well enough to explain it: the tech lead, the senior engineer, the product manager. Those are the same people you’d least like to see spending an afternoon on anything else. Every hour they spend restating the week is an hour not spent on the problem only they can solve, or on unblocking the junior who has been stuck since Wednesday.

The report also goes stale quickly. By Monday it describes last week, and anyone who wanted an answer midweek either waited or interrupted someone. I’ve written before about the version of this I lived with, where the work sat in three tools at three levels of detail and the only place it all came together was a PowerPoint rebuilt by hand every week. The weekly report is the same problem in a smaller form: a reconstruction of the work, made by the people doing it, on top of doing it.

Getting Claude to write it moves the cost

The technically minded, with a token budget to spend, have found a workaround. A homegrown script pulls the week’s tickets, commits and chat threads into Claude and asks it for the update. It’s clever, and it beats typing the thing by hand.

But somebody now maintains the machinery. They look after the prompt, the access tokens, the export that breaks when someone renames a field in Jira, and the skill that keeps it all running, held together with sticky tape. The cost has moved from writing the report to keeping the report generator alive, and it still falls on one of your strongest people.

All that machinery only summarises tickets. The result doesn’t look good, it doesn’t roll up from task to feature to initiative, and a reader who wants more detail on one item can’t drill down to find it.

And the output is still a document that few people read. The problem was never the typing. Automating a report nobody reads gives you more reports nobody reads, sooner.

Make the work explain itself

Transparency should be a by-product of the work, not a second job. That needs two things, and most teams only ever attempt the first.

First, the record has to exist where the work happens. When an engineer moves a card, notes a blocker or posts a one-line update on the card they’re working on, that is the status. Progress should roll up from the task to the feature to the initiative without anyone summarising it, so there is nothing to compile on Friday.

Second, and this is the half most tools miss, the least technical person who wants to know must be able to find the answer unaided. Your CEO will not learn Jira’s filters. If the view needs training, a guide or a patient engineer sitting alongside, the executive asks for a report again and the tax comes straight back. The bar is high: you give them a link and let them get on with it.

Get both right and the reader chooses their own depth. What was done is a click away. Why it was done, the decision and the reasoning behind it, sits next to the work rather than in a document nobody can find in six months. How it was done is there for anyone who wants the detail. The engineer no longer pre-digests any of it.

What it looks like in a real tool

Slipdock, a kanban board with a wiki built in, is designed around this rule. A status update goes on the card it describes, in a click. A health signal on each card rolls up from everything beneath it, so a problem buried three levels down shows on the initiative an executive is actually looking at. The Narrative view takes a set of cards and a date range and tells you what happened to them, which is the Friday report without anyone writing it. Every board and card can carry its own wiki pages for the why and the how, and an executive gets a saved view that opens from a link.

You don’t need my tool to do this. You need one rule: every report reads from the work, and nobody restates it. A tool you already pay for, set up properly and used by everyone, can get you most of the way.