Each week you’re expected to post your Weekly Update to the main 🔒 Updates P2.
On Friday at 8:00 UTC a Weekly Update post will be auto-published as a sticky, unresolved post. You should post your update as a comment on this post. On Tuesday it will be automatically marked as resolved and it’s unstuck. Aim to have your weekly update done either Friday or Monday.
Why do we do updates: to communicate and share your weekly working experience
What do we want updates to do: highlight issues early; create better transparency between teams and individuals who don’t otherwise have major contact day to day.
Updates are the place where humans go to feel the pulse of the company. They’re enforced to ensure that people who can make a change to your working experience are able to understand what you’re going through and help you in whatever way necessary. Everyone has to write them, but not everyone has to read all of them.
Weekly updates are short summaries of what you’ve already done every week, and should clearly communicate your experience of doing that work to partners, directors, team leaders (ie; people responsible for managing areas of the company) and development buddies. They should also lay out – in brief detail – what you’re planning on doing next week. Because they are designed to communicate and share your experience, it’s expected that the focus of your weekly update should be what you’ve already done, but you should highlight anything which you feel may impact your working experience in the following week if known.
Weekly updates are also a space to do a show and tell. You’re encouraged to share your successes and struggles, but you don’t have to. You’re expected to communicate struggles and issues to your team leaders (ie; in your 1-1’s).
Weekly updates are predominantly about communicating your experience on the projects you’re working on, but they should also be contextualised with anything else happening that week that impacts on you.
A good thing to keep in mind is that weekly updates are a part of your job; they’re a part of your job description.
Consider these to be recommendations for what your update should look like:
- 3 – 4 short paragraphs, or approx 350 words
- Don’t write a bulleted task list; the content of your update should be about your experience doing what you did and not an account of what you did
- Highlight where you are struggling and where you’re succeeding
- Include images, videos and milestones; these are a good way to convey and share how you experienced the week
- Focus on struggles, successes, and highlights
- Keep in mind that the objective is to connect with the rest of the company
- Don’t try and validate your time or report your hours. These should already be communicated in your respective teams
An update should: share highlights, wins and successes, struggles and frustrations. It should be honest. You should aim to communicate how you feel over what you do. In Scrum terms, weekly updates should be more of a project retrospective, rather than a daily stand up (ie; a task list). You can, if you like, include videos, photos or links out to other things which are relevant to your weekly update/working week.
An update should not: be a list of completed tasks, it is not a place to make requests to others, it does not need to be about accounting for time or validating the work you have done. It is not a detail of your day to day, this should already happen in your standups/weekly meetings with your team.
Example of a good update: Jenny Beaumont’s weekly update
Should you read everyone else’s Weekly Update? That’s totally up to you, but it *is* a lovely way to get an insight into the way your colleagues are experiencing work. There are team members who voraciously read absolutely everything, which is very cool, and others who may just skim a few posts. Diving in every few weeks is certainly a worthwhile minimum level of engagement.