How I Distribute Context at Scale - The Week in Review
Keep your teams in sync with an async documentation practice
A challenge you run into in most organizations is getting high fidelity context distributed across the organization quickly and effectively. How quickly you distribute information can have real impacts on how well your teams navigate rapid change and uncertain times. One of my main principles is to distribute context and decision-making - and one of the primary tools I use to do this is the Week in Review.
In this post I’ll describe how I organize my Week in Review, the different formats I’ve used in the past, and some of the things I’ve leveraged the document for. You’ll want to customize this for your team, org, company, and mission - a few examples are provided below.
What is a Week in Review?
Think of the Week in Review (WiR) as an opportunity to share context across your teams. A lot of the topics I put in my WiR are things that I might bring into a staff meeting or share via email. The intention is to collect and distribute context that is useful to my directs and their teams in as timely a way as possible.
You can make this document as light or heavy as you’d like depending on your organization. The most important outcome is that you are passing along context to your team in a timely manner that helps them make decisions and get involved in the right conversations.
Why maintain a Week in Review?
Besides distributing context, which I think is reason enough to do this, there are a number of other benefits to this practice. Here are a few surprising benefits I've found:
Awareness: The act of putting this together each week helps you build awareness of what's going on across your teams. You are sharing context, but you are also mining it and keeping an eye out for it because you know you will want to share it.
Engagement: Some team members engage with the written document more actively than a staff meeting. They are also able to engage at times that work better for them, and have more thoughtful questions and responses to the items I share.
Visibility: While questions from staff will often come up after the fact in 1:1 meetings and aren't visible to the rest of the team, questions asked in the WiR are visible to everyone. That is additional context that everyone can benefit from.
Performance Reference: When I maintained these for smaller teams we would call out individuals who had significant accomplishments. These served as really great reference points for promotions and performance reviews in the future.
Historical Reference: I've had countless times where I needed to go back and reference when something happened, or get details about a project, problem, or other initiative. I've found important context in my WiR document months or even years later.
For some teams I've maintained four or five years of history in a single document. Going back and reflecting on where a team came from and what they achieved over that timeframe is valuable to have.
Organizing the Week in Review
Doing this takes work, and my first piece of advice is that when you start this practice you need to set aside time to ship it each week. When you begin doing this, your teams will likely find value in the information. When you don’t ship it, they’ll notice. I recommend blocking out a few hours each week to collect, organize, and ship the review. Personally, I find this easiest to do when I’m not likely to be interrupted and have a solid chunk of time - but you’ll have to figure out what works for you. Look for ways to automate this too - there are new tools each week that could help with this practice.
Collecting information
If you are familiar with Getting Things Done, then you are familiar with the idea of quick capture. If you aren’t, the idea here is that you need a fast and low-friction way to capture items immediately when they come up. I personally use my todo list capture mechanism for this, but any tool that allows you to capture context, deadlines, links, articles, or other types of information that you can later put into your WiR will work. The tool isn’t important. What matters is that you capture the information when it comes up and flag it for inclusion in the WiR.
In Todoist, I have a project set up for the Week in Review. Todoist makes it easy to use their quick capture keyboard shortcut and I can drop a URL, or a quick reminder, and use #WeekInReview to drop that into the project. I use this for Slack threads, documents, email messages, tasks from meetings, etc. Anything that needs to go into the Week in Review starts here for me. If something comes to mind when I’m away from my computer, I can use my phone to easily capture it in the same way.
Structuring the Week in Review Document
Here is an example of how I’ve structured this document - tune this to work for your team. It’s worth asking your team what is working for them as you go.
I have always used Google Docs for this. I think the features in GDocs are really helpful for enabling collaboration and engagement. My main advice is to use what your team will engage with - this document is for them.
Week in Review Template
Here is a template you can use to start - make a copy of this and modify as needed:
Week in Review Template - Google Docs
The first tab in that document has my instructions and an example note I might send to my team to introduce the Week in Review.
In the document I have at least two tabs to start:
Week in Review
This tab is the actual Week in Review where final versions are placed
Week in Review Collection
This tab is for my team to share items that they think are worth sharing with the rest of the team
The Week in Review Collection tab has only the upcoming week, and each week I clear it out and set it up for the next week.
Week in review Collection Tab
This section has contributions from the team, and at the end of the week I will use the collection tab to draft my final week in review update. Once I have it in the final form I move it into the main tab and it looks largely like what you see above.
Week in Review Tab
The main difference between the collection document and the main document is that the main tab maintains a running list of each week’s updates in reverse chronological order, the most recent at the top. I insert each new week at the top - the H1 heading is the date.
Alternative Formats
Different teams will have different areas of focus, and I use the headlines to steer what the document should represent. When running more operationally focused SRE/Production Engineering teams I will include an “Incidents” header.
In the past the WiR has included sections like:
Asks and Deliverables - Anything that has come up over the last week that the team needs to take action on - anything with deadlines and deliverables goes into the WiR as a reminder. This is primarily where I put the more operational deadline type asks on the team so that it is referenceable and authoritative.
Updates and Progress - Updates on strategic programs, ongoing projects, issues that the team has been waiting for clarity on, budget updates, staffing updates, etc - all the operational information you’d normally cascade in a staff meeting can go in here.
Issues / Incidents / Challenges / Unexpected events - I think of these as items that the team can learn from or should be aware of so that they can raise or maintain awareness with their teams. In particular, when I’ve run SRE/Production Engineering type teams - documenting any incident that came up was important to keep resilience top of mind and to guide our customers (product development teams) to do the same.
Wins and Celebrations - The WiR is a great place to acknowledge the hard work your team is doing and highlight individual contributions. You can cover progress on key objectives, valuable increments that have shipped, and even wins with customers where they’ve found success using the thing you shipped to them.
Organizational Context and Opinion - Sharing the broader movements you see across the organization, whether strategic context sharing, changes in direction from the business, your perspective on how the landscape is shifting and how teams can prepare, or any other useful context you think the team should have based on what you are seeing week over week. This is a helpful place to constantly stream your thoughts to your teams and help them know what’s on your mind.
Industry Trends and interesting reads - This is one of the areas that gets the most engagement from my teams. I will share interesting articles, videos, podcasts, reports, or general perspectives across our industry.
Also note that my teams have used this themselves for sending out updates - this approach isn't just for managers:
Project Updates - I've had technical ICs send out weekly updates on big projects to let people know how it is evolving, using the same running weekly document format.
Periodic Reporting - I've had teams use this format to track weekly/monthly/quarterly reporting of things like availability, incidents, quality, etc. Anything where an ongoing record is useful can use this format.
Play with the format to work for your team - there is no right or wrong here, but there is definitely useful and not useful.
If weekly seems too frequent for your situation, consider doing it less frequently. This has been successfully implemented as a Monthly Review as well.
Week in Review Email
This part is pretty simple - each week when I’ve written up the week in review and dropped it into the main document I will email out a quick summary. I do not copy/paste the entire update into the email - I want the team to look at the document, not just read my email and move on. That email looks something like this:
Subject: My Organization Week in Review for Week ending July 11th
Week in Review for week ending July 11thGood week of progress - the User Dashboard shipped, super proud of the team getting that out. I have a budget review ask of you, and there’s one incident from this week that your teams should review. A few interesting reads, but overall a quiet week.
Thanks, Aaron
My goal in sending the email is to signal that there’s something there to read and comment on. I expect team members to add comments, make corrections, add their own context worth sharing. Ideally they would have added it to the collections doc but in practice, most context doesn’t get added until I send the email out and that’s completely fine in my view. I don’t add a lot of detail about what’s in the WiR - I want them to go read the doc, not my email.
When you miss a week
Sometimes life catches up with you and you don't ship the WiR - I've done this quite a few times, it happens. Don't sweat it too much, but there are some practices that I've found help me tackle these moments.
Try to cover all the period you missed - I will usually date the section for multiple weeks if I skipped a week and put in the effort to try to find items from the prior week that I should have included.
Acknowledge the change, but don't apologize - I think any good team should see that we're human and sometimes things slip. This practice is one of those things that can definitely slip and nobody gets hurt - pick it up the next week and move on.
Don't stop shipping because you missed a few - You took 3 weeks of PTO and missed a few of these? Pick it up the next week. You got busy and couldn't ship for 2 weeks, pick it up on the 3rd week. Just keep shipping as best you can.
Model the behavior you want to see from your teams. We all have to prioritize differently sometimes.
Changes as you scale up
As your team grows, the WiR will change as well. I've found that the level of candor I would put into the WiR for a five-person team had to be more carefully considered for a 30 person team. Are you comfortable sharing the document with your entire organization, or do you want to share more timely information with only your directs?
For small teams I will typically share with my whole team, but as the organization grows and my directs are primarily managers, I will restrict the WiR I produce to be for my directs only. This allows me to share more candidly and they can make decisions about what is appropriate and relevant to cascade down to their teams.
Adding stakeholders
One powerful addition as your team grows is to share the WiR with your manager, your peers, and your other stakeholders. This can become a powerful tool to provide transparency to the teams around you about what is going on in your own organization. You might be surprised how many people will pay attention to it in this format, and how much they'll appreciate getting visibility into topics that would normally be limited to your staff.
Confidential Information
I tend to avoid putting anything really sensitive in the WiR as my team grows. It's too easy for people to copy/paste material out of the document. I also do tend to share this document with stakeholders, other managers, peers, etc, which makes it challenging to share anything confidential. I don't think this reduces the value of the activity at all.
Automating this with AI
I think this is the type of activity you could definitely automate and I would encourage you to experiment with doing so. I've tried putting this into Gemini and having it generate the content in various tones or adding humor. At the end of the day, I personally prefer to just write it out because I think it helps me. If that's not you, automate it.
Collecting up the items you share is easy to automate and LLMs are pretty good at understanding the context of each item and writing up a brief summary. You could even have an agent prompt you for a weekly summary that you write and it takes care of the rest. There are lots of options here, and this is a great opportunity to play with your favorite vibe coding app and see what you can build.
Wrapping it up - the Week in Review
I hope you find this practice useful. If you put it into practice for your own teams and find it valuable, please let me know how you implemented it. Did you make changes to what I've described here? What did you find that worked better or worse? I would love to hear about your experience.
Thanks this post makes a lot of sense. I use slack for a lot of this, including its Canvas function to inline my notes into my directs slack channel. Rather than pulling people in with an email I am trying to make looking at it part of their workflow when they check slack messages. I will also pull Week In Review topics into my direct's meeting, either as conversation starters or topics to ask people about.
I've debated how much of this to do in a meeting vs how much to do async. In previous roles I have done more of the async model, but I have found a lot more engagement when I do it in a meeting. My thinking is it creates space for people to ask questions as well as, by not recording it, implicitly keeps it private.