Automating a weekly team digest: the digest nobody reads

The automated digest has a predictable life. It launches to appreciation, it is read for three weeks, it grows as people ask for their thing to be included, and by the second month it is a wall of text that arrives every Monday and is opened by nobody.

The failure is not technical. Pulling activity from a handful of tools and summarising it is straightforward. The failure is that the digest was never designed for a specific reader with a specific question, so it became a list of everything that happened — which is exactly what the reader could already get by looking.

What we'll cover

• Why digests die
• Deciding who it is for
• What to leave out
• Building it with CodeWords
• The shape that gets read
• Summarising without flattening
• Timing, channel and length
• Retiring it, and the review that makes that possible
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why digests die

No specific reader. A digest for everyone is a digest for nobody, and it ends up containing the union of what each group wanted.

Accretion. Every request to add a section is reasonable and the sum of reasonable additions is unreadable.

Activity instead of outcome. Twenty merged pull requests is a fact; whether the release went out is the thing somebody wanted.

No omission. A digest that includes everything has made no decisions, and the value of a digest is entirely in the decisions about what not to include.

It duplicates a channel. If the same information is already in a channel people follow, the digest is a second copy with a delay.

Nothing changes as a result. The honest test is whether anybody has ever done something differently because of it, and for most digests the answer is no.

Deciding who it is for

The single question that determines whether this works, and it has only a few good answers.

The person who was away. What they missed and need to know before Monday's meeting, which is a small and well-defined set.

The adjacent team. What changed that affects them, which is almost never the same as what the team considers important.

The manager or executive who needs outcomes and exceptions and does not want the detail.

The team itself, which is the hardest case, since they already know and the only value is perspective across the week.

Pick one and say so in the digest itself. A digest with a stated audience can be edited; one without cannot, because nothing can be argued out of it.

Separate digests beat one combined digest, even with overlap, since two short relevant ones outperform one long one containing both.

What to leave out

Raw activity counts. Commits, messages, tickets moved. These feel like content and inform nothing.

Anything the reader will see elsewhere through their own notifications.

Routine work. The steady state is not news; only the exceptions are.

Anything without a consequence. If nothing follows from a line, it is a line the reader has to skip.

Vanity metrics, which people learn to discount and which then cast doubt on the rest.

Per-person breakdowns, unless there is a real reason. A digest that reads as individual output tracking changes how people behave in ways that are hard to reverse.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the tracker, the repository, the support desk and Slack can feed one digest.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: who it is for, what counts as noteworthy, and what should never appear.
3. Authorize the connections — the sources you want and the channel or email it goes to.
4. Describe the exceptions: a quiet week, a missing source, anything confidential.
5. Send it to two people for a fortnight and ask them what they skipped.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The shape that gets read

One sentence at the top saying whether the week was normal. Most weeks are, and saying so lets a busy reader stop there.

Three to five items, maximum. Not sections — items.

What changed, then why it matters, in that order, since the reader is scanning for relevance.

Names of people to talk to, which converts a digest into something actionable.

Exceptions in their own place — what went wrong, what slipped, what needs a decision.

A link to the detail, once, for the person who wants it, rather than the detail inline.

Summarising without flattening

Do not average away the important thing. A week with one serious incident and forty routine changes is a week about the incident.

Preserve specifics. "The payment retry bug" is useful; "several bug fixes" is not, and summarisation tends towards the second.

Quote where a quote is better than a paraphrase, particularly for a decision.

Keep uncertainty. "Probably shipping Thursday" should not become "shipping Thursday", which is the most common and most damaging summarisation error.

Do not invent connections between unrelated items in the interest of a narrative.

Have a person read it before it sends, for the first month, which catches the flattening while it is still cheap to fix.

Timing, channel and length

Monday morning is worse than Friday afternoon for a weekly, since Monday competes with everything else arriving and Friday is when the week is fresh.

Match the channel to the reader. Slack for the team, email for people outside it, and the same content in both is usually wrong.

Keep it under a screen. If it scrolls, the bottom is not read, so the bottom should contain nothing that matters.

Same time every week, because a digest arriving at variable times is never built into anybody's routine.

Skip quiet weeks. Sending "not much happened" is better than padding, and padding is what teaches people to stop opening it.

Thread the detail rather than expanding the message, which keeps the surface small while leaving the depth available.

Retiring it, and the review that makes that possible

The digest that nobody reads keeps sending because stopping it requires somebody to decide, and nobody owns that decision. Building the review in at the start is what prevents a year of unread Mondays.

Give it an owner by name, not a team, since a team does not notice that something has stopped being useful.

Set a review date when you launch it — a quarter is about right — and put it in the calendar rather than in an intention.

Ask the readers directly at that review. Not whether it is useful, which everybody answers politely, but what they skipped last week and whether they would notice if it stopped.

Try stopping it. A fortnight of silence produces a definitive answer within a day if anybody was relying on it, and silence if they were not.

Cut rather than redesign when it has grown. The usual fix is removing four sections, not restructuring.

Retiring it is a success. A digest that has done its job and become unnecessary is a good outcome, and treating it as a failure is why so many of them outlive their purpose.

Making it survive

Handle a missing source by saying so rather than silently omitting a section, since an absent section looks like a quiet week.

Make it idempotent so a retry does not send twice, which is the failure people remember.

Keep the sources' permissions in mind, since a digest can easily surface something to people who should not see it.

Store what was sent, so a claim about what the digest said can be checked.

Report the outcome to whoever maintains it: sources read, items included, items dropped by the rules.

Limits worth knowing about

Summarisation is lossy in ways that are invisible in the output, which is why a human read-through matters early.

Source coverage is uneven. Work that happens in conversations and documents is underrepresented against work that happens in trackers.

Permissions differ per source, and the digest's own account may see more than its readers should.

Engagement is hard to measure in Slack or email, so "is this read" usually has to be asked rather than measured.

Cross-team digests age quickly as teams reorganise, and nobody remembers to update the source list.

What to build first

The exceptions-only digest: what went wrong, what slipped, what needs a decision. Nothing routine. It is a fraction of the work of a full digest, it is the part every audience actually wants, and it is short enough that people read it — which is the only property that matters.

Two habits make the difference. State the audience in the digest itself, since that is what makes it possible to argue a section out later rather than only ever adding. And skip the weeks where there is nothing to say, because a digest that pads a quiet week is teaching its readers that opening it is optional.

Frequently asked questions

Why do automated digests stop being read?

Because they have no specific reader, so every reasonable addition gets included and the result is a list of everything that happened — which is exactly what the reader could already see for themselves.

Who should a digest be for?

One of: the person who was away, an adjacent team, a manager wanting outcomes and exceptions, or the team itself. Pick one, state it in the digest, and run separate short digests rather than one combined long one.

What should never go in a digest?

Raw activity counts, routine work, anything the reader sees through their own notifications, anything with no consequence, and per-person breakdowns unless there is a real reason for them.

How long should it be?

Under one screen. If it scrolls, the bottom is not read — so anything below the fold should be detail the reader opts into, not something that matters.

When should it be sent?

The same time every week, and Friday afternoon usually beats Monday morning: the week is fresh and it is not competing with everything else that arrives on a Monday.

What is the most common summarisation error?

Removing uncertainty. "Probably shipping Thursday" becoming "shipping Thursday" is both the easiest mistake to make and the one that causes the most trouble downstream.

Should I send a digest in a quiet week?

No. Say nothing, or send one line. Padding a quiet week is the fastest way to teach people that opening the digest is optional.

How do I know whether it is working?

Ask whether anyone has done anything differently because of it. If nobody can name an instance after a month, the digest is a ritual rather than a tool.

How do I decide whether to stop sending a digest?

Stop it for a fortnight. If anybody depended on it you will hear within a day; if nobody says anything, that is the answer. Give it a named owner and a review date at launch so the decision has somewhere to sit.

What should I ask readers at a review?

Not whether it is useful — everybody answers that politely. Ask what they skipped last week, and whether they would notice if it stopped.

Related reading

• Automating Slack standup messages
• Automating Zoom meeting summaries
• CodeWords integrations and templates