By Friday, the team has made progress on the agency's systems. The founder has seen a few messages in chat, but still cannot tell whether the onboarding work will be ready next week.
One automation has shipped. Another is waiting on a decision. A third is being tested. A useful update should let the founder see those differences and act on the decision without reading the entire backlog.
This fictional agency example shows how a weekly update connects progress, blockers, and decisions.
What was planned for the week
The agency wants new leads routed to the right person and new clients handed to delivery with an approved scope. It has five items in a small systems backlog.
Lead routing is the first item. The onboarding packet follows. Duplicate handling is in progress, while a dashboard and automatic reminders remain planned. Each item has an owner and a visible definition of done.
The onboarding packet looks like a straightforward build until Wednesday. The team discovers that some won deals do not identify the person authorized to approve the client's scope. Sales has recorded a company name and a contact, but the receiving team cannot tell whether that person can approve the work.
The delivery owner can describe the missing condition. The founder must decide how the agency will handle it.
GitLab's delivery methodology describes a shared project record, assigned work, and visible changes to scope and priorities. In this example, the backlog holds that detail. The weekly update explains what it means for the next few days.
The update the founder receives
Here is the Friday update:
Shipped: D01, lead routing. Released October 8 after 20 sample leads were checked against the assignment rules. Maya owns monitoring. The backlog contains the acceptance record.
In progress: D03, duplicate handling. Eli is testing what happens when the same lead event arrives twice. The next review is October 13. Until that review passes, any uncertain duplicate goes to a person.
Blocked: D02, onboarding packet. The team needs a rule for deals without a named client scope approver. Building the packet around an assumed approver could send the wrong person a request or create an unsupported commitment.
Decision needed: The founder should decide by October 12 at noon, Eastern Time, whether a named client approver is required before the packet is created or whether a temporary contact may be used with a recorded exception. I recommend requiring the named approver for the first pilot. Sales can collect the missing details while the team finishes the other work.
Next: Review duplicate handling on October 13. If the approver rule is decided by the deadline and the missing records are completed, review onboarding packets on October 15. Dashboard work remains behind that dependency. Automatic reminders stay planned until the manual packet process is accepted.
A useful weekly update connects shipped work, blockers, and the next decision.
Why the decision belongs near the top
“Onboarding automation is 80% complete” would leave the founder with a vague impression of progress. It would also hide the condition that controls the remaining work.
The update names the decision, who must make it, the recommended choice, and the effect on the plan. The October 15 review is conditional. It is not presented as a committed launch date.
GitLab's weekly async update guidance asks teams to describe progress, next steps, and blockers, and to link relevant issues. Use that structure to show the founder what moved, what is blocked, and which decision comes next.
The accompanying document contains the reusable update, the complete example, and the five-item backlog behind it. That last piece lets a reader trace each statement back to the item and its acceptance condition.
For your next update, pick the blocked item with the greatest effect on next week's work. State the missing decision, its owner, and the date it is needed. Keep the revised plan attached to that decision.
Resources
By Friday, the team has made progress on the agency's systems. The founder has seen a few messages in chat, but still cannot tell whether the onboarding work will be ready next week.
One automation has shipped. Another is waiting on a decision. A third is being tested. A useful update should let the founder see those differences and act on the decision without reading the entire backlog.
This fictional agency example shows how a weekly update connects progress, blockers, and decisions.
What was planned for the week
The agency wants new leads routed to the right person and new clients handed to delivery with an approved scope. It has five items in a small systems backlog.
Lead routing is the first item. The onboarding packet follows. Duplicate handling is in progress, while a dashboard and automatic reminders remain planned. Each item has an owner and a visible definition of done.
The onboarding packet looks like a straightforward build until Wednesday. The team discovers that some won deals do not identify the person authorized to approve the client's scope. Sales has recorded a company name and a contact, but the receiving team cannot tell whether that person can approve the work.
The delivery owner can describe the missing condition. The founder must decide how the agency will handle it.
GitLab's delivery methodology describes a shared project record, assigned work, and visible changes to scope and priorities. In this example, the backlog holds that detail. The weekly update explains what it means for the next few days.
The update the founder receives
Here is the Friday update:
Shipped: D01, lead routing. Released October 8 after 20 sample leads were checked against the assignment rules. Maya owns monitoring. The backlog contains the acceptance record.
In progress: D03, duplicate handling. Eli is testing what happens when the same lead event arrives twice. The next review is October 13. Until that review passes, any uncertain duplicate goes to a person.
Blocked: D02, onboarding packet. The team needs a rule for deals without a named client scope approver. Building the packet around an assumed approver could send the wrong person a request or create an unsupported commitment.
Decision needed: The founder should decide by October 12 at noon, Eastern Time, whether a named client approver is required before the packet is created or whether a temporary contact may be used with a recorded exception. I recommend requiring the named approver for the first pilot. Sales can collect the missing details while the team finishes the other work.
Next: Review duplicate handling on October 13. If the approver rule is decided by the deadline and the missing records are completed, review onboarding packets on October 15. Dashboard work remains behind that dependency. Automatic reminders stay planned until the manual packet process is accepted.
A useful weekly update connects shipped work, blockers, and the next decision.
Why the decision belongs near the top
“Onboarding automation is 80% complete” would leave the founder with a vague impression of progress. It would also hide the condition that controls the remaining work.
The update names the decision, who must make it, the recommended choice, and the effect on the plan. The October 15 review is conditional. It is not presented as a committed launch date.
GitLab's weekly async update guidance asks teams to describe progress, next steps, and blockers, and to link relevant issues. Use that structure to show the founder what moved, what is blocked, and which decision comes next.
The accompanying document contains the reusable update, the complete example, and the five-item backlog behind it. That last piece lets a reader trace each statement back to the item and its acceptance condition.
For your next update, pick the blocked item with the greatest effect on next week's work. State the missing decision, its owner, and the date it is needed. Keep the revised plan attached to that decision.