This blog-post was originally posted in SoundCloud’s blog. The original article can be found there under the name: Leveraging a Manager Weekly Newsletter for Team Communication.

Below is the replicated article


I started my journey as an Engineering Manager at SoundCloud close to a year ago. This came after working as a Software Engineer for more than a decade, most of which I spent as an iOS Engineer. Since then, I’ve been trying to figure out my role and expand my knowledge on the subject. This entails constantly meeting with other peers, along with reading books I’ve found or that have been recommended to me about how to be a better people manager.

One of these books is “The Making of a Manager: What to Do When Everyone Looks to You” by Julie Zhuo. In this book, the author mentions that during the week, she jots down her thoughts about her team, what she hears others say about it, how the projects are going, etc; basically anything that’s happening during the week that is directly or indirectly related to her team, she writes down.1

Zhuo said she does this to properly digest the daily events — if possible, she writes them as they happen, if not within hours of them happening. Then, at the end of the week, she reviews them, which allows her to digest the different situations and process stuff she might have forgotten or that she remembers but which are a bit fuzzy. For her to cement this new habit, she started sending the resulting compilation to her team.

When I first read this, it struck a chord in me, as a few weeks prior to reading this book, I had started working on my own journaling habit. I did this by leveraging it with Obsidian for my notetaking and daily jots in a way that allowed me to connect topics organically and learn from the patterns that emerged.

Next Steps

Thanks to my nature that pushes me to try new things and introduce changes and tools to my system to see if they can bring me any value, it didn’t take much for me to get in the habit of writing my daily notes in a way similar to Zhuo. As mentioned above, I was already taking daily notes as a reference for my weekly reviews, as well as to not forget what was important during meetings. However, I wasn’t sharing them with the team. After reading Zhuo’s book, the idea of sharing them with the team made a lot of sense and required little adapting on my part, as I was already compiling a daily journal.

Obsidian has a plugin for daily note taking; you can provide a template in Markdown and it’ll be used any time you create a new daily note. So with this in place, I can quickly, and with just one click, be on my daily note.

Screenshot of Obsidian’s sidebar showing “daily notes” as the title along with a list of dates.
Screenshot of Obsidian’s sidebar showing “daily notes” as the title along with a list of dates.

The image above shows a sample of my notes and the format I’ve chosen for naming them (this is also automatically filled by Obsidian). I just set up the date, and then at the end, I include the name of the day (this is useful and important for my newsletter, since I only need to take a look at the notes from Monday to Friday for it).

What Does a Daily Note Look Like?

Honestly, there’s not much magic behind the daily notes. I literally write down anything and everything that happens; later on, when I’m revisiting my notes, I can ignore what’s not relevant or even delete something if I feel like it’s not adding value or it isn’t clear enough.

My template is divided into two sections: Happenings and Grateful For. Originally, it also had action items at the bottom, but since I follow the Getting Things Done principle, I write every action item that comes my way in my tracking system (at the moment, it’s a combination of Todoist and Notion), so it doesn’t make much sense to duplicate efforts.

Happenings

This is where everything goes. It’s usually a list of one or two liners describing things that happened in a meeting, a conversation I noticed on Slack, an email that caught my attention, etc. I try to not write a lot per topic, but I do tend to make a lot of entries (usually ending up with 20 or more per day). The idea is just a single line that will jog my memory and put me in the same state of mind as when the thing it’s describing happened.

Grateful For

This is part of the journaling exercise that has come in handy for the newsletter. Here I try to write two to three things that I’m grateful for each day. The idea is to not have to think too hard, which gives me the freedom to write small things like “Having flexibility today to move some meetings and get more work done.” Wherever it is that I’m grateful for, no matter how minor, I write it down.

Wiring Everything Together for Team Communication

At the end of the week, I go through all my notes related to work and to the team and compile them into a list. Here I try to be succinct and just provide a small update for the team.

This way, I can highlight the strengths and remarkable qualities the team showed during the week, as well as point to some areas where we can do better.

I also copy my manager in the email to take the opportunity to show them all the things the team is doing that might not be as visible (Jira tasks and meetings can be visible for externals, but the other most important topics could go unnoticed) and make my manager aware of all the great things the individuals on the team are doing. The purpose here is to bring to light what the team is doing in a more pointed way by highlighting specific things they accomplish during the week.

I find this important because it reminds me of things that might not be too “flashy” but that were super important. It has also given me a tool to recognize weekly work that the team executed.

Redacted email subject: Week 27 Thoughts about the week. Mentions updates of the projects and focus week. Ways of working, Jira and knowledge sharing approaches. Ends with an overall positive week for Core Clients
Redacted email subject: Week 27 Thoughts about the week. Mentions updates of the projects and focus week. Ways of working, Jira and knowledge sharing approaches. Ends with an overall positive week for Core Clients

One key aspect of this for me is to keep it casual, since the objective is not a report but rather a sharing of one’s thoughts and ideas during the week, and also to let the team know how their work and the team are being perceived by others outside of the group of people that they directly work with on a daily basis.

On that note, it’s important that the email is short and concise; I aim to exclude details that are either too small to bear any relevance or that are just part of the operational overhead of running the team and adjacent projects. I’m trying to keep everyone up to date on the latest happenings of the team but not achieve such a granular level of details that the reader might get lost without active technical knowledge of each and every project.

We’re starting to adopt this technique at SoundCloud outside of my team (other teams, project-specific updates, etc.) and so far, it has proven quite successful. Often, team members feel happy when something they did gets mentioned in the email; they might have not thought it was that remarkable or they might think it went unnoticed, and then reading it in the weekly newsletter definitely brings some unexpected joy. This was expressed to me by a couple of team members during our 1:1s, confirming the hypothesis that highlighting these achievements helps build the team’s morale.

On a parting note, one last detail I derived from this exercise is that while I’m compiling the list of achievements, improvements, and random thoughts, I get to do a “retrospective” of the week. This helps me understand how things are going; define a better trajectory for the team and the projects; and adjust direction more quickly, because I take the time to process things regularly and within a “short” period of time so as to avoid having to go through lots of different events. This obviously has the potential to keep the team on track and informed constantly and regularly. Only time will tell how beneficial this practice might be, but at least for the time being, it’s proving to be quite useful.


  1. Note: It seems a similar concept is also mentioned in the book “Soft Skills: The Software Developer’s Life Manual” by John Z. Sonmez. ↩︎