When Nobody Answers Your Progress Update

A clear progress update still needs a plan for a missing reply. Name the decision, agree what can continue and follow the request through to its effect on the work.

7 October 2026 · The Tellenze team

A hand holds a teal disk above an empty ivory ring on a ribbon linking an envelope to blocks, with a small hourglass nearby.

At 10:00 on Tuesday, a product team posts an update about its new document-search prototype. Full-title searches are working. Abbreviations still produce poor results. The team hopes to run research sessions on Friday.

The final line reads: “Any thoughts on whether we should go ahead?”

By Wednesday afternoon, nobody has answered. One engineer assumes the sessions are postponed. Another keeps preparing for Friday. The product owner thinks the message was simply keeping everyone informed.

This is an illustrative scenario, not a customer story. Its problem is less dramatic than an incorrect status report: the facts are visible, but the request has no agreed destination.

A useful progress update needs a path from the information to the next action. That path should still make sense when the reply never arrives.

Give the reader a real choice

Our imaginary team has evidence worth sharing. It has tried the prototype against a safe collection of documents. Searching for complete titles finds the intended documents; several common abbreviations do not. The test notes show which queries worked and which failed.

That supports a focused conversation. The team could use supervised sessions to learn which abbreviations people actually use. It could also improve abbreviation handling before asking anyone to try the prototype. Both choices have a cost: the first needs careful session design, while the second delays that learning.

The product owner, Maya, owns this choice. A clearer update addresses her directly:

Maya, should Friday's supervised sessions test the current prototype, including its abbreviation limitations, or wait until we improve those queries? The test notes are linked below. I recommend using the sessions to understand people's vocabulary. We need the choice by Wednesday at 14:00 to prepare the sessions properly.

The recommendation gives Maya something to assess. The evidence gives her somewhere to look. The response time explains when her answer can still influence the work.

In a real message, use a calendar date and timezone, and check that the person will have a reasonable chance to respond. A deadline chosen for the sender's convenience can create avoidable pressure.

GitLab's Weekly Async Updates describes a regular practice of recording progress, next steps, blockers and milestone confidence, with relevant colleagues included. It is a useful foundation for shared visibility. A decision request adds another responsibility: make clear who needs to answer which question.

A fallback needs an agreement behind it

There is still something missing from the update to Maya. What happens at 14:00 if she has not replied?

Amy Kennedy's advice on meeting-free stakeholder updates recommends making time-bound requests explicit and stating a default when no reply arrives. That can help people plan. I would add a qualification: the default must fit the authority and agreements the team already has.

Writing “we will proceed unless you object” does not, by itself, give someone permission to proceed.

In our example, the team has already agreed that participant invitations wait for the product owner's session decision. Engineers can continue improving the prototype within the existing scope. The update can therefore add:

If we do not have a decision by then, invitations will remain unsent. We will continue the approved prototype improvements, and I will contact you to agree the next session date.

This makes the consequence visible without converting silence into approval.

Another team might have delegated the session choice to the researcher, with Maya invited to offer advice. Its fallback could reasonably be different. The important distinction is whether a reply is required for the action or merely welcomed.

Resolve that distinction while planning the work. Trying to settle it in the final line of an urgent update is too late.

Keep the facts together as the messages change

The same update will matter to several people, but each needs a different next step.

For the delivery team, the useful message is about sequencing: “The session decision is pending. Keep improving abbreviation handling within the agreed scope. Leave the participant invitations unsent until the decision is recorded.”

For Maya, it is the choice and its consequence: “We need your session decision by Wednesday at 14:00. Without it, we cannot confirm Friday and will agree a new date.”

For people who have offered to test, the useful message is about their time: “Friday's session is not confirmed yet. We will send a confirmed date and preparation details once the session plan is agreed.”

These messages share a single set of facts. They do not give each audience a different version of reality. Internal test notes stay with the team; participants receive the information they need to plan.

In Tellenze, the work-item guide describes keeping questions, decisions, useful progress and supporting evidence with the work. That is a sensible home for the test results and Maya's recorded choice. Short messages can point back to that shared record.

Follow through when the deadline passes

Suppose Wednesday reaches 14:00 with no answer. The sender still has work to do.

First, check whether Maya recorded a decision somewhere the team agreed to use. Avoid chasing someone for an answer that already exists.

If the decision is still missing, update the shared record: invitations remain unsent, prototype improvements continue, and Friday is unconfirmed. Then use the agreed contact route to resolve the choice or arrange another date. The sender owns that follow-through even when someone else owns the decision.

The urgency should determine the channel. A routine research question can wait for a reasonable response window. An issue affecting customers now needs the team's established urgent route.

Google and PagerDuty's Incident Response chapter separates incident coordination, operational work and stakeholder communication into explicit roles. Ordinary project work does not need that whole structure. The useful lesson here is to agree who coordinates the response and how people reach them before urgency makes communication harder.

A reminder with the same vague request will preserve the same ambiguity.

When Maya does answer, record the actual choice and tell the people whose next action changes. If Friday is confirmed, the researcher can prepare the agreed session and send invitations. If it moves, the delivery team and prospective participants need the new plan. The request is complete when its consequence reaches the work.

Leave ordinary updates room to be quiet

Plenty of progress messages need no reply.

Basecamp's Show Progress chapter offers a different approach: make progress and unresolved uncertainty visible so people can inspect the work without repeatedly asking for status.

That is useful when the team can continue under an existing agreement. “No decision needed; next check after the query fixes” can be an entirely adequate update. Adding an artificial request would spend someone else's attention without improving the plan.

Try this with one real update that does need an answer. Before sending, ask the named reader what they understand they must decide, and ask a teammate what they will do if the response is late. If the answers conflict, fix the agreement as well as the wording.

After the response window, follow the request to its outcome. Was the choice recorded? Did the affected work change? Did anyone mistake an acknowledgement for a decision?

That small experiment can reveal whether the missing piece was better writing, a clearer owner or a conversation that the update was never going to replace.