There’s no single platform team that consists of only web engineers at SoundCloud, even though we consider ourselves to be part of the “Web Collective.” Instead, all web engineers are split into smaller, cross-functional teams across the organization. This structure definitely has its advantages, but it’s also left engineers in a situation where platform-specific experience and knowledge about platform-specific best practices are more difficult to access than they would be if we were all on the same team. New employees in particular can have difficulties breaking into unfamiliar tech stacks and SoundCloud internal frameworks.
We did and do still have forums to discuss technical challenges at SoundCloud to share knowledge across multiple teams: Technology Open House is a good example. This is where engineers from the entire organization come and learn from each other every week. While we enjoy these meetings, we as the Web Collective wanted to try out a slightly different format with topics dedicated to our platform. More specifically, we wanted to reduce the pressure to present as much as possible and instead give space to unprepared thoughts and raw ideas. We encourage all questions, and the environment fosters a culture of being able to ask questions that might feel silly or trivial to the people asking them.
We tried it out, it immediately felt natural to us, and it turned out to be extremely helpful, so we wanted to share a bit about the structure and format and our observations.
Meeting Structure
The Web Collective Knowledge Sharing meeting is an hour long, and it takes place every Friday at 16:00. This is one hour before our company-wide demos or all-hands sessions that we have on Fridays as well. Fridays are usually also days where developers take their self-allocated time (SAT) to work on their own projects, and since most of our web developers are based in Europe, the majority of us are winding down for the weekend at that point. This allows for a pretty relaxed atmosphere.
Even though this session primarily focuses on web topics, we occasionally also have non-web developers join to share more about web projects they’ve been involved in. This is because it’s important to us that the guest list stays as open as possible and that everyone feels welcome, no matter which platform they primarily work on.
People who are presenting don’t have to follow a specific format. We do this to keep a low as possible barrier of participation. Some people like to have slides prepared, while others like to use only some prepared browser tabs, or don’t prepare at all and just run through a piece of code they want to share. We found that by allowing low-key presentations, more people are presenting. There are also no limitations on time other than the one hour allocated for the meeting. (Of course, people shouldn’t and don’t use the full available hour when they know that there are other topics on the agenda.)
We often find ourselves using most of the time for the meeting, even for days with a light agenda. The Web Collective is pretty good at turning a single question into an hour-long discussion, albeit one that’s both enjoyable and valuable.
Speaking of agenda, there’s no fixed agenda for the sessions, and topics are often proposed in the meeting itself. We do keep a document with proposed sessions, and it’s good practice for presenters to add their topics to the agenda, but it’s also totally OK to jump the queue in case someone has an urgent need to (e.g. they’ll go on vacation afterward or the topic has a time constraint). These lax rules around the agenda also add to the casual environment of the meeting.
Things We Do in Knowledge Sharing
The flexibility of the meeting has allowed us to morph it into whatever we needed it to be.
One thing we regularly do is review PRs together. “I worked on this pull request the other day, let me show it to you…” or “I saw an interesting pull request, can somebody walk us through that?” is something we hear a lot during Knowledge Sharing. We find this really helpful for more complex PRs, because sometimes the collective spots details that other reviewers missed.
Every so often, Knowledge Sharing also means introducing the collective to new tools or codebases: Sessions that start with “We created a new app and integrated it into soundcloud.com, here’s how it works…” or “We have a new shared component library. It’s in its early days but here’s where we are right now…” are helpful for everyone to stay up to date on what’s new.
We also had times where we talked about processes and how we could improve them. A few months ago, for example, we were getting bombarded by automated alerts on Slack, and an engineer kicked off the session with “I feel like alerts are getting too noisy and out of control. Should we appoint a point person to deal with them?” Another conversation about how we do releases started with “Here’s an open source tool that could simplify our release processes. What do you think?”
Other times, we use Knowledge Sharing for technical deep dives. For example, an engineer who worked on our webpack config began a conversation with “I had to dive into how code splitting works for soundcloud.com and I can now explain it!” Other times, an engineer who worked on our famous waveform started with “We are making changes to the waveform and I found that it’s really well architected. Here are interesting patterns that we use there…” And another one who was profiling React went with “I measured the performance overhead of rendering many React roots and here’s what I found…”
Questions and open rounds are frequently on the table when the agenda is empty. In these cases, Knowledge Sharing is used as an opportunity to seek out expertise and feedback from others. For example, we recently had meetings that started with “It looks like we’re always running into issues with feature flags. What can we do to fix them?” and “Can anybody explain how tracking works? How exactly would I implement firing a click event?”
Observations
We’ve observed that developers have adapted a sharing mindset and are actively sharing their work and asking peers to share in this new forum. We’ve talked about a vast variety of topics, which results in an increase of the bus factor of the team.
With our current remote work setup, this meeting also helps make the platform team feel more connected. There are few opportunities to connect to platform peers in such a laid-back environment, and even before we started to work remotely, this meeting was one that web peers always looked forward to, making it even more important now.
Another thing we noticed is that the barrier to asking “basic” questions has gone down; people aren’t afraid to ask questions they might otherwise be scared to ask in other scenarios. And with engineers from all the different engineering levels present at the meeting, it has become a valuable forum for getting answers to these questions.
What’s Next?
There are some points that we want to improve upon, though we haven’t yet found the best solutions to these issues yet.
For example, sometimes it’s unclear to peers if they should have a discussion on Slack or whether they should propose a topic for the next Knowledge Sharing session. To date, we haven’t found a great guideline for this. However, when someone asks if a discussion should happen in our Knowledge Sharing meeting, it’s a great indication that it should be discussed there as well, even if it’s just in the format of a summary of the Slack discussion.
And this is a great segue to another issue: We haven’t yet found a good way to document the outcomes of these sessions. Semi-randomly, colleagues add their notes to the agenda document, but a lot has already been “lost.” We should definitely take on a better documentation cadence: Maybe declaring a dedicated note-taker for each meeting or encouraging presenters to sum up their findings in the agenda document afterward would be a good start. However, we don’t know if this would be detrimental to the casual environment of the meeting. But we’re sure we’ll find a good balance there.
Nevertheless, we’re very happy with the current setup of the meeting, and we plan to keep our weekly cadence to share knowledge.
If you have a similar setup at your company, we’d love to hear about it to understand what has worked best for you.
Photo by Papaioannou Kostas on Unsplash