Weekly Summary Technique

“What did you do this week?” I’ve written a weekly summary for myself and my teams for years. In this post, I’ll explain how I use this tool.

Why Write a Summary?

Why write a weekly summary? I have two reasons: it helps me think through my work, and shows people what I’m working on.

Taking thirty minutes to pause, reflect, and plan helps me sharpen my thinking and transition from week to week. Many developers keep a rubber duck on their desk for this reason. Rubber ducking lets you talk through your problem at the speed of speech, and is excellent at exposing shaky assumptions. Weekly summaries codify this into a predictable, shareable routine.

Here’s an explanation of weekly summaries from Becoming an Effective Software Engineering Manager by James Stanier:

“In the same way that you can ask questions to get an insight into your manager’s world, there’s also a way that can open up yours to your manager while also helping you pause, reflect, and plan. Every week, take thirty minutes to note down the main activities that you and your team have been involved in, how you feel about them, and what decisions you’ve taken or need to take.” – Becoming an Effective Software Engineering Manager, pg. 59

Summaries also keep your team and management in the loop. In the Army, I spent a great deal of time on the radio giving reports to leaders of all kinds. When things are moving, everybody wants to know what’s happening. And, informed leaders can better support you.

Summaries are also “updates without asks.” They associate your voice in the company with good, bad, and neutral news, and they prime people to help you when you need it by keeping them informed about what it is you actually do here.

Finally, I find that weekly summaries help me mark time. In a career, a week goes by quickly. My summary helps me remember that. It keeps me focused on the big questions, like: am I doing the work I want to be doing?

Who’s the Audience?

When I was an individual contributor, I wrote summaries for my team and made them public inside the company via a Google Doc. As I became more senior, I wrote them for my manager and did not make them public. “Who is the audience?” begets another question: “Who needs to know what I’m doing on a weekly basis?” There’s value in that being a lot of people, and also value in it being one or two. You get to decide.

No matter who I’m writing for, I try to imagine that anyone in the company could read what I’ve written. That doesn’t mean I can’t be candid. It’s a reminder to chose my words thoughtfully. And to do enough leading outside the meeting that my analysis shouldn’t be surprising to anyone.

What’s the Format?

Consistency beats format. Consistency beats format. Consistency beats format. Say it with me!

Write it up, give it a quick pass for content, spelling, and grammar, add the correct GIFs, and ship.

I’ve tried a variety of formats for my reports, and I’m currently using one called the 4P’s: progress, problems, plans, and people. Here’s my explanation of each:

  • Progress: “What did we accomplish?”
  • Problems: “What’s holding us back? What dangers do I see ahead?”
  • Plans: “What am I planning to do next?”
  • People: “Who have I worked with this week? Is there anyone I want to recognize? Is anyone struggling?”

Example

Here’s a version of a weekly report I recently submitted. It’s a little shorter than my typical report.

Week #N Weekly Report

Progress:

We launched the “big feature”! This had been our focus for weeks and all other news seems trivial in comparison. It was the culmination of lots of hard work on internal and contract dev teams, and much support from across the company. I think this is going to have a massive positive impact on the user experience. Well done, everyone!

My contributions this week were PR reviews and delivery of features to staging and production.

I opened a PR that reduced the time a test runs from 1 minute 35 seconds to 59 seconds. Still not great, but a lot of little changes like this will get our test suite into a more usable condition. (PR link)

Problems:

I think we hit a point over the last few weeks where our PR-opening was outpacing our capacity to deliver. We got through it. I think adding a “PR Approved” column in Jira helped expose hidden work.

Plans:

Continue to deliver work while “nudging” our team toward best practices when I am lucky enough to have opinions to share.

Continue hacking on tests when I get downtime. I think they are a huge opportunity to improve the devexp and velocity at our company.

People:

Truly outstanding work this week from everyone on our team. I think we built something to last.