Weekly Summary Technique

I’ve written a weekly summary for myself and my teams for years. In this post, I’ll explain why I do and 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 my team 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. Everybody wants to know what’s happening. And, informed leaders can better support you.

Summaries are also “updates without asks”– they keep people in the loop about your progress so that when you need help, people are familiar with the domain you’re working in.

Finally, I find that weekly summaries help me mark time. A week feels like a very short amount of time and my summary helps me remember that. It keeps me focused on the big question: am I doing the work I want to be doing? Am I on the right team at the right company? Etc.

Format and 4P’s

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 held me back? What dangers do I see ahead?”
• Plans: “What am I planning to do to make next week great?”
• People: “Who have I worked with this week? Is there anyone I want to recognize?”

Example

Here’s a version of a weekly report I recently submitted. It’s a little shorter than my typical report, but brevity has merit.

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.

Conclusion

That’s it! Consistency beats format. If you keep a routine like this, I’d love to hear about it.