Pilotless

Weekly engineering status report template

Most small teams don't need another meeting to know where things stand. They need one short page, once a week, that says what moved, what's stuck, and whose move it is. This guide gives you a template for that page, shows how to fill it from GitHub by hand, and includes a worked example.

Why a written weekly status beats another meeting

Meetings cost engineers more than they look. Paul Graham's essay Maker's Schedule, Manager's Schedule argues that people who make things work in blocks of at least half a day, and that a single meeting can wreck an afternoon by cutting it into pieces too small for hard work. That's an essay, not a study, but most engineers recognize it.

Interruptions have a measurable cost. In a lab study, Mark, Gudith and Klocke (CHI 2008) found that people made up for interruptions by working faster, at the price of more stress, frustration, time pressure and effort. Google's code review guide makes a related point: it tells reviewers not to interrupt focused work because getting back into flow can take a long time. A written status is read when the reader chooses, not when the calendar says so.

Visibility of work is linked to performance. DORA lists visibility of work in the value stream as a capability that, together with related lean practices, predicts software delivery and organizational performance. A weekly report is a low-tech way to give a small team that visibility.

It leaves a record. Our opinion: a status meeting is gone when it ends. A written status can be searched, linked from a PR, and compared with last week. Four weeks of reports show you which problems keep coming back, which no standup will do.

It forces an owner onto every problem. Also our opinion: saying "the auth refactor is kind of stuck" in a meeting is easy. Writing it next to an empty owner field is uncomfortable, and that's the point. Many teams decide they need a manager when what they really need is for "nobody owns this" to be visible.

What a written status doesn't do: it doesn't replace 1:1s, career conversations, or sorting out disagreements between people. Those need a human and a conversation. The report just keeps the routine status traffic out of those conversations.

The template

Copy this into a GitHub Discussion, a pinned issue, a wiki page or a doc. Keep each section short. If a section is empty, write "None" rather than deleting it, so readers know you checked.

# Engineering status — week of YYYY-MM-DD

Author: @handle · Period: Mon DD – Fri DD · Repos: org/repo-a, org/repo-b

## 1. What moved
<!-- Merged PRs and closed issues that matter. Group by goal, not by person. -->
- [Goal or area]: what changed, link(s)
- [Goal or area]: what changed, link(s)

## 2. Stale or blocked (with owner)
<!-- Every line needs an owner and a next step. "Owner" = who has the next move. -->
| Item | Waiting since | Waiting on | Owner (next move) | Next step |
|------|---------------|------------|-------------------|-----------|
| #123 PR title | YYYY-MM-DD | review / author / external | @handle | ... |

## 3. Unowned
<!-- Open issues or PRs with no assignee, no reviewer, or no CODEOWNERS match. -->
- #456 issue title — proposed owner: @handle?
- #789 issue title — proposed owner: ?

## 4. Needs a human decision
<!-- Things no tool or process can settle. Name who decides and by when. -->
- Decision: ... · Options: A / B · Decider: @handle · By: YYYY-MM-DD

## 5. Next week
<!-- Three to five commitments, each with an owner. -->
- @handle: ...
- @handle: ...

How to fill it from GitHub by hand

All of this can be done with GitHub's built-in views and search qualifiers. Add org:your-org or repo:owner/name to each query, and replace the dates with the start of your week.

1. What moved. Open each repository's Insights → Pulse. GitHub's Pulse view lists open and merged pull requests and opened and closed issues, and shows the last seven days by default. Across repos, search:

Group what you find by goal. In our experience, "Checkout v2: three of five steps live" says more than a list of twelve PR titles.

2. Stale or blocked. Search for PRs that are waiting:

For each one, write who has the next move. Don't assume it's the reviewer. In a study of long-open PRs at Microsoft, more were waiting on the author than on reviewers.

3. Unowned. Search is:issue is:open no:assignee for issues nobody has picked up. For PRs, check whether anyone was requested; if your repository has a CODEOWNERS file, an unowned path usually means a gap in that file. Propose an owner rather than just listing the gap.

4. Needs a human decision. No search for this. Skim the comment threads on the stale items: when two people disagree, or a PR is waiting on a product call, it goes here with a name next to it.

5. Next week. Pull from your board or milestone, and keep it to a few items with owners.

Post it on the same day every week, in the same place. Our opinion: consistency matters more than polish.

Example, illustrative

This is a made-up example to show the format. The team, repos and people are fictional.

# Engineering status — week of 2026-10-12

Author: @sanne · Period: Mon 12 – Fri 16 · Repos: acme/api, acme/web

## 1. What moved
- Checkout v2: address validation and saved cards merged (#412, #418). 3 of 5 steps live behind flag.
- Reliability: retry logic on webhook delivery merged (#405); closed #377.
- Docs: onboarding guide updated for new local setup (#420).

## 2. Stale or blocked (with owner)
| Item | Waiting since | Waiting on | Owner (next move) | Next step |
|------|---------------|------------|-------------------|-----------|
| #398 Split invoice service | 2026-10-05 | author | @joris | Split into two PRs as asked in review |
| #409 Upgrade ORM | 2026-10-08 | review | @lena | Review by Tue, or hand to @mo |
| #415 Rate limiter config | 2026-10-09 | approved, not merged | @mo | Merge after Monday deploy |

## 3. Unowned
- #366 Flaky test in payments suite — proposed owner: @lena?
- /infra/terraform has no CODEOWNERS entry — proposed: @mo + @sanne

## 4. Needs a human decision
- Decision: drop IE11 support in web app · Options: drop now / drop in Q1 · Decider: @sanne · By: 2026-10-21

## 5. Next week
- @joris: land checkout step 4
- @lena: ORM upgrade reviewed and merged
- @mo: add CODEOWNERS for /infra

Generating the digest part automatically

Sections 1 to 3 are mechanical, which makes them the boring part. The Pilotless GitHub App is free and generates a weekly status digest from your repositories. The weekly digest lists stalled PRs and unassigned issues. Nudging and flagging them in their own threads is coming next. It's one option. You can also keep doing it by hand with the searches above, or script it against GitHub's API. Sections 4 and 5 still need a person: the app doesn't make decisions or set priorities for you.

Install the free GitHub App

Sources