Weekly Updates
When creating or joining a new team, I have a set of rituals.
These rituals are usually not “set up JIRA” or “schedule a regular retro.” Many times, the teams are nascent enough where any sort of plannning, estimation, or more traditional “Agile” practices are net negative. Nonetheless, a tool or two to help the team keep focus can go a long way.
Instead of reaching for predictive, forward-looking practices, I almost always employ a retroactive document to summarize the week’s progress. Let’s explore.
The Weekly Update
The weekly update is a long-running document or series of internal blog posts that captures a team’s impact for the current week.
When there is no impact to talk about, we might discuss some of our activity or output. When discussing activity or output, lessons learned or progress can be a good thing to include.
If enough weeks pass where we either have nothing to write about or there is no impact, we need to take a hard look in the mirror. What are we working on, and why is it not incrementally delivering value or helping us learn? Are we in the middle of a Big Rewrite and we don’t realize it?
Focus on Impact and Outcomes
By lasering in on the impact of our work, we keep ourselves focused on delivering value to the customer. Impact means product shipped and metrics moved. “Shipped” is not enough.
Many times focusing on the impact is doing the same work but just marketing it differently.
Let’s look at a few contrived examples of a weekly update blurb:
Bad:
- Completed rollout of Technology X.
- Continue working on Project Y.
- Scheduled team retros for every other Friday.
- Held a discussion on how we want to evolve the design of our code base.
Note: These are not bad activities in themselves, they are just inappropriate to include in a results-focused document. Including them waters down the impact work your team includes in the document. Always ask “Who cares?”
Good:
- Completed rollout of Technology X, which prevents contributing factors seen in the last major outage and has improved performance 5%.
- Completed migration to Technology Y, which makes Common Error Case Z impossible. Common Error Case Z previously resulted in 40 customer touchpoints per day.
- Sunsetted the Big Doodad. This saves $1,000 per month on infrastructure spend.
- Learned from working on Project Z that it won’t actually solve the customer problem. Going back to the drawing board.
Impact and outcomes are almost always measurable. Dollar amounts, percentiles, and more are your friend. Don’t forget to add context to the numbers when necessary. (E.g. Is $1,000 per month a lot or a little for your organization?)
An Opportunity for Intent
The weekly update document is also an opportunity to communicate intent to the wider engineering, product, and design organizations.
Talk about what’s next on your team’s plate. Talk about what you expect the impact to be. By proactively communicating what you intend to work on, you can expect a few types of respones. All of these are incredibly valuable:
- “Oh, you should talk to Team X. They are working on something similar.”
- “Interesting that you’re working on Effort Z with that implementation plan. I think I’ve got a much simpler way we could accomplish that…”
- “Oh, you should talk to Team Y. They tried that 2 years ago and it didn’t work. They might have some advice.”
- “Oh, customers stopped asking for that. We actually don’t need that.”
- “I’m an expert in that and that sounds fun. Is there a free spot on the team?”
Tools to Use
It doesn’t matter. I don’t have a product to plug or a new workflow to expound.
Choose what’s simplest and most idiomatic to your company. At Gusto, that means Google Docs. At your company it could mean Confluence, Notion, or some homegrown wiki. You don’t need much more than a few <h2>
’s and <h3>
’s.
Be visual and entertaining. Include charts, graphs, photos, memes, and bad jokes.
Don’t spend too much time on the update. Each one should take at most an hour when you start. As you get better at it, each one should take about 15 minutes.
Rotate who on the team writes the update each week. This is a good opportunity to improve communication skills in a low-stakes environment. It also encourages a healthy level of awareness of all the different projects that might be happening.
One is a Lonely Number
Even if no one else reads the document, I still recommend teams experiment with the weekly update.
It can simplify the process of writing self-reflections for performance reviews. It can also serve as a pre-written promotion doc.
Most of all, it gives the team something to be proud of. Look back through at the end of a month, quarter, or year and be surprised how much you accomplished. Feel yourselves slowly make unconscious adjustments to how you think about and prioritize work.
Send Me Your Updates
If your team experiments with this, I’d be happy to read a few updates to give a few pointers. (This assumes your company doesn’t mind sharing them.) Send me an email and we’ll take it from there.
Special thanks to Ngan Pham and Allen Holub for reading early drafts of this post and providing feedback.