Engineering Weekly Report

Produce a weekly engineering status report that a team can send to stakeholders, their engineering manager, and the team itself. The format is fixed week-over-week so readers know exactly where to look — shipping progress at the top, decisions in the middle, risks and next steps at the bottom. The report must be readable in under 2 minutes. Avoid prose walls: use bullet points, status tags, and short tables. If metrics are not provided, leave the metrics section with data needed] markers rather than fabricating numbers.

Required Inputs

Ask for these if not already provided:

• Team name and report period — team name plus week number or date range (e.g., "Platform Team, Week 21, May 12–16")
• Work items shipped this week — what was completed and released or merged
• Work items in progress — what is actively being worked on, with rough percent-complete if known
• Blocked items — what is blocked, who owns the block, and what is needed to unblock
• Key decisions made — any architecture, process, or priority decisions made this week
• Decisions needed next week — any decisions that need to be made soon and who needs to make them
• Risks and escalations — anything that threatens next week's commitments or needs leadership visibility
• Next week's top priorities — the 3–5 things the team plans to accomplish next week

Optional but useful:

• Key metrics — reliability (error rate, p99 latency), velocity (story points completed), or other health indicators
• Team health notes — PTO, new joins, attrition, morale signals worth noting
• Sprint or iteration number — if the team runs sprints

Output Format

Engineering Weekly Report — Team Name]

Week: Week Number] | Date Range, e.g., May 12–16, 2025] Author: Name or Team Lead] Distribution: e.g., Eng leadership, Product, Team]

Shipping Progress

Shipped This Week

| Item | Description | Impact | |------|-------------|--------| | Feature / Fix / Infra change] | One-line description] | Who benefits / what it unblocks] | | Feature / Fix / Infra change] | One-line description] | Who benefits / what it unblocks] | | Feature / Fix / Infra change] | One-line description] | Who benefits / what it unblocks] |

In Progress

| Item | Owner | Status | Target Ship | |------|-------|--------|-------------| | Work item] | Name] | ~40% / On Track / At Risk] | Date or Sprint] | | Work item] | Name] | ~70% / On Track / At Risk] | Date or Sprint] | | Work item] | Name] | ~20% / On Track / At Risk] | Date or Sprint] |

Blocked

| Item | Blocked Since | Blocker Description | Owner | Needed To Unblock | |------|--------------|--------------------|----|-------------------| | Work item] | Date] | What is blocking progress] | Name] | Specific ask — decision, resource, dependency] |

If no items are blocked: No active blockers.

Key Metrics

Metrics reported as of Date]. Prior week in parentheses.

| Metric | This Week | Last Week | Trend | Target | |--------|-----------|-----------|-------|--------| | Error rate (5xx) | X%] | X%] | ↑ / ↓ / →] | < threshold] | | p99 latency | Xms] | Xms] | ↑ / ↓ / →] | < threshold] | | Deployment frequency | X deploys] | X deploys] | ↑ / ↓ / →] | target] | | Story points completed | X] | X] | ↑ / ↓ / →] | sprint target] | | On-call page volume | X pages] | X pages] | ↑ / ↓ / →] | < threshold] |

Metrics notes: Any context that makes the numbers meaningful — e.g., "Error rate spike on Tuesday tied to downstream dependency outage, resolved by EOD."]

If metrics are not provided: replace table rows with [data needed — provide metric values for this section].

Decisions

Made This Week

| Decision | Rationale | Owner | Stakeholders Informed | |----------|-----------|-------|----------------------| | Decision description] | Why — 1 sentence] | Name] | Yes / No — who] | | Decision description] | Why — 1 sentence] | Name] | Yes / No — who] |

If no decisions were made: No major decisions this week.

Needed Next Week

| Decision | Context | Deadline | Decision Owner | |----------|---------|----------|----------------| | What needs to be decided] | Why it matters, what happens if delayed] | Date] | Name or role] |

If no decisions are pending: No decisions pending.

Risks and Escalations

| Risk | Likelihood | Impact | Mitigation | Escalate To | |------|-----------|--------|-----------|-------------| | Risk description] | High/Med/Low] | High/Med/Low] | What we're doing about it] | Name/role if escalation needed] |

Escalations this week: Any item that needs immediate leadership attention — call it out explicitly here, do not bury it in a table row. If none: "None."]

Team Health

| Item | Status | |------|--------| | Team capacity this week | X of Y people at full capacity] | | PTO / out of office | Names and dates, or "None"] | | New joins / departures | Name, role, and date, or "None"] | | On-call this week | Name] | | On-call next week | Name] |

Team notes: Any morale, workload, or team dynamic signals worth surfacing — keep this factual and constructive. If nothing to note: omit this line.]

Next Week's Priorities

The 3–5] things this team will ship or meaningfully advance next week.

1. Priority item] — One sentence: what done looks like and who owns it]
2. Priority item] — One sentence: what done looks like and who owns it]
3. Priority item] — One sentence: what done looks like and who owns it]
4. Priority item] — One sentence: what done looks like and who owns it]
5. Priority item] — One sentence: what done looks like and who owns it]

Capacity risk: If the team is at reduced capacity next week (PTO, incidents, etc.), note it here so stakeholders calibrate expectations.]

Appendix: Sprint Scorecard (if applicable)

| Sprint | Committed | Completed | Completion Rate | Carried Over | |--------|-----------|-----------|----------------|--------------| | Sprint N-1] | X pts] | X pts] | X%] | X pts] | | Sprint N] (current) | X pts] | X pts — partial] | X% at midpoint] | TBD |

Questions or corrections: Slack channel or email] | Next report: Date]

Quality Checks

• ] Every blocked item names a specific owner and states what is concretely needed to unblock it — not just "waiting on X"
• ] Decisions-needed table includes a deadline and a named decision owner, not a vague "TBD"
• ] Metrics table is either populated with real numbers or explicitly marked [data needed] — no fabricated metrics
• ] Next week's priorities are written as outcomes ("ship X", "complete Y migration") not as activities ("work on X")
• ] Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row
• ] The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it
• ] Report period (week number and date range) is clearly stated in the header

Anti-Patterns

• ] Do not fabricate metrics — if data is not available, mark the field as [data needed] rather than estimating; stakeholders making decisions on invented numbers is actively harmful
• ] Do not write next week's priorities as activities ("work on X") — they must be outcomes ("ship X", "complete Y migration") so stakeholders can evaluate whether the team delivered
• ] Do not bury escalations inside a risk table row — anything needing leadership attention must be called out explicitly in the Escalations section
• ] Do not list blocked items without naming a specific owner and a concrete unblocking action — "waiting on X" is not a blocker entry, it is a placeholder
• ] Do not write a report that exceeds two printed pages — length signals the author has not done the editorial work of deciding what matters to stakeholders