Oscar Funes

Published on

Sending weekly updates

I’ve been reading Lethain’s book for Staff Engineers, and within it, there was this idea of sending a weekly update.

The goal described in the blog post is to send an update that your manager or peers can read in 5 minutes and takes 15 minutes to redact.

I found that idea intriguing because as I’ve moved through the engineering ladder, the harder I’ve found to communicate what I work on. I felt the practice would force me to keep track of all the ways I interact with the different project stakeholders and other contribution methods.

For the past month, I’ve been trying to use the weekly update practice for my work. The process I follow is relatively simple, I write down a bullet point list of things I work on during the week, then convert that list into a readable document that I share through my work’s SharePoint instance.

First Iteration

The first couple of attempts were a verbatim copy-paste of the word document. But as I was reviewing the documents the week after, I started to think about who is the target for this document? Well, my manager and my peers

What is the value I want to provide to my manager and my peers? I usually work with multiple engineering teams and primarily in meetings with Product and Engineering managers.

I wanted to provide an overview of my work and insight into problems I observe throughout my week.

Second Iteration

So my third attempt was a more summarized view of my work week and adding a miscellaneous section for sessions outside the usual domain I work with.

But later, as I was reviewing three weeks together, I started wondering about linking all these updates through some narrative and retrospective.

I wanted to add a narrative flavor so that a given project could be read from beginning to end. I also wanted to add some retrospective thoughts because we sometimes lose this with the day-to-day tasks we’re all doing.

Being long enough at a job gives you certain visibility into how your decisions affect the long-term system you’re working on.

Conclusion

I’ve been finding this weekly update practice an excellent thing to do to end a week and retrospect on what is going on with the different projects I engage in.

Another exciting thing, when writing everything down in this way, is that you’re forced to think about how you want to communicate what you do. Like attending a meeting specifically may not be a good thing to put in the update, but the outcome or next steps might be, also your opinion from the topic, or similar.

I’ll keep doing this to form a habit. But also, I’ll start sending the updates as a “newsletter” type of thing, similar to what the original blog post alludes to.

I feel that sharing widely will definitely bring more benefits to this process.

Happy coding!