Run the weekly team digest

A digest written from memory reports the loudest work. One assembled from records reports the work, and the difference shows most in what is stuck — which nobody volunteers.

Gather

• Shipped: pull requests merged in the last seven days, grouped by area, with the ones that changed something a user sees separated from the ones that did not.
• Closed: tickets moved to done, with anything that was a customer-reported bug marked.
• Opened: new tickets, and among them anything at high severity.
• Stuck: this is the section that matters. Tickets in progress for longer than usual, pull requests open more than a few days, and anything that has been reassigned twice. Get these from the dates on the records, not by asking.
• Incidents: anything that paged, and whether its review is written.
• One number the team is steering by, with its change.

Write it

• Open with the two or three things worth knowing, in one line each, in plain language. Most readers stop here and that is fine — make these the right ones.
• Then shipped, as user-visible changes. "Deleting a toolkit now refuses while anything is listed against it" rather than a PR title.
• Then stuck, each with how long and what it is waiting on. Waiting on a person is a different problem from waiting on a decision, and naming which is the whole point of the section.
• Then what next week is for, in one line.

Keep it under a screen. A digest people scroll past is a digest that is not read.

Post it

One message in the team channel, on the same day and hour every week. Link the detail rather than including it.

Stop and ask

• Before naming an individual as the reason something is stuck. Name the item and what it waits on.
• Before including anything from a private channel or a ticket marked confidential.