Weekly project status meetings: Speedy edition

When you’re managing multiple months-long projects with multiple engineers—especially if they’re cross-functional—it can be a challenge to keep up to date with the progress your engineers are making on their respective project.

This was something I was grappling with for a while at Spot, as I have 9 engineers working on several cross-functional projects at any given time. I have been slowly tweaking my process a bit to figure out what works best, and I believe I’ve found a happy place for keeping up to date without adding meetings for the sake of having meetings. The format is a bit similar to a standup, but for a specific project with a very crisp focus.

There are two components to this: the sprint schedule and the weekly update document. We use Notion at Spot, so both of these components live there.

Within an ERD (or engineering project plan, whatever you call it at your organization), I work with the engineering team to create a clean outline for what each engineer will work on for each sprint, and this regularly gets updated throughout the course of the project. This looks something like this:

This is something that should be readily kept up to date. I’ll cross off the tasks as they are completed and will often link directly to the PRs so I can go back as a reference.

The second component of this is the weekly sync. This should never take more than 15 minutes and involves the EM, engineers on the project, and PM. Every week the structure is the same, like this:

Bill:

• Updates

• Blockers

• Questions

Ted:

• Updates

• Blockers

• Questions

Any other important information:

• Point 1

• Point 2

• Point 3

I turn this structure into a dated template so every time we meet I just add a new block and the format is right there ready to use. Updates and blockers are pretty straightforward; for questions, these are typically for either the EM or PM, and I write out both what the question was and what decision was made as a result so we always have a paper trail for that.

For any other important information, this may include logging updates to the timeline, general decisions being made (e.g. rollout date or plan), and anything else that’s pertinent to this meeting that’s worth remembering for the past.

This format is really helpful when you’re conducting a project postmortem to see where perhaps things fell apart or what went really well.

This structure has been incredibly helpful especially for cross-functional projects that may require resources from two different teams. If you use something similar I’d love to hear about it, and if you adopt this I would also love to hear about that as well!