Why You Should Start a Technical Reading Group

Duy Tran
motive-eng
Published in
7 min readMay 3, 2023

In this post, I’m going to convince you why you should start a technical reading group with your team by recounting our own experience at Motive. Technical reading groups can be a core thread that builds your team’s cohesion and technical growth.

Here’s what technical reading groups can provide:

  • Motivate free-form discussion and curiosity
  • Drive personal technical growth
  • Build shared understanding of technologies, terminologies and best practices for your team
  • Help build a shared understanding of your infrastructure
  • Provide a low-friction and low-risk environment for practicing team building and leadership

Alongside the many great resources about technical reading groups, I hope this reading adds another perspective.

Growing the team

2022 was a year for Motive to mature our Data Engineering organization. We had hundreds of data pipelines driving customer-critical products and internal analytics, a complex data ecosystem, and a rich roadmap for innovation and improvement of our data technologies.

Our team was also diverse in technical experience and domain expertise. We had fresh grad engineers who had just joined alongside tenured engineers who have accumulated lots of Motive domain knowledge.

In finding new ways to mesh together, here’s what we noticed:

  • There was a lot of knowledge on which we had different levels of views
  • There were new technologies we needed to read up on
  • There was a lack of team building; it had fallen in the shadow of our execution-focused, remote-first work environment

Now was the time for us to lay the technical foundation to continue to grow. This is what drove us to start our technical reading group!

Our format

We started with open reading groups. Any topic could be presented in the form of a blog, video, or technical deep dive. While open reading groups are useful, here is where we found challenges:

  • It was difficult to get team members to curate interesting topics for discussion on a regular cadence.
  • The discussions weren’t always relevant to our current work. While this can be stimulating, there were context-switching costs when each meeting introduced a brand new topic.

This is where we pivoted. A member of our team suggested following a book or class in order to stay aligned. A book helps provide both default structure and relevance for us to build on week by week. We started this reading group based on a single book and then made decisions about the group’s format.

Following are the decisions that come up when starting a group.

Choose a book and a meeting frequency

We chose Designing Data-Intensive Applications by Martin Kleppmann. This book covers design patterns and technologies that were relevant to our Data Platform work. Focusing on a single book gave the group the consistency we needed.

Designing Data-Intensive Applications by Martin Kleppmann

Each month, we met for an hour to discuss one chapter from the 12-chapter book. For this book, we opened it up to our engineering team, but team attendance was mandatory for our data platform team. A core group is important to have month over month, to keep the momentum of the discussion going.

Assign official roles and tasks

We created two administrative roles to keep the meetings going:

  • A facilitator to set meeting invites, send reminders, and keep the discussion moving during our meetings.
  • A note-taker to help document discussions and learnings.

Facilitators properly read the material, make sure there are prompts to discuss, and encourage meeting attendance; this role requires preparation before the meetings. We decided that facilitator or note-taker would be a rotating role between members to help share the responsibility.

Everyone else contributes to the discussions and actively engages. We expected that attendees read the material, but even when they did not, there were other ways to engage during the meeting.

Prompts for discussion covered the material and how it possibly related to Motive. For example, here is a list of some prompts collected for Chapter Two of the book. This chapter covers data models and query languages.

  • Which ORM frameworks do we use at Motive?
  • When have we used SQL vs NoSQL at Motive?
  • What are some cases when you use schema on read vs. schema on write?
  • How is downtime handled for schema migrations in the different data stores that we use?

Here are some useful resources on facilitating:

Set the meeting agenda

For us to have a successful meeting, we set a meeting agenda that allowed us to gain shared context in the beginning and have open-ended discussions the remainder of the time. Meetings started with a 15-minute summary video for any team members who were unable to read the chapter assigned that month. To help guide us, we found multiple options for chapter summary videos on YouTube. Discussion consumed the rest of the meeting.

Discussion format:

  • We started with initial impressions from every attendee.
  • We then followed question prompts. Prompts were gathered before the meeting, but could be added during the meeting. Anyone could chime in, popcorn-style. Prompts were based on the content of the material directly and how it relates to architecture / design in our current Motive engineering architecture
  • Facilitator helped keep the discussion going between prompts and engaged different members.

The discussion format above was important because we wanted everyone to be able to participate and engage. Our approach was:

  • Forced minimum engagement: We agreed that everyone speaks at least once about their initial impressions, even if only to say “no thoughts”.
  • Provided multiple ways to engage: Attendees could engage with the reading, the video, and the prompt questions. Discussion was based on the reading, on personal experience, and on the Motive technical stack.

We were mindful not to burden people so much that it would deter them from joining. We found that not everyone participates at a high level or is able to finish the reading every time. That is OK. Sometimes listening is all someone can actively contribute (and they still can benefit). I like the breakdown here, stating that 50% people actively participate, 20% people sometimes participate, 30% never participate apart from listening.

We used the final minutes of the meeting to summarize possible follow-ups to which we may circle back in project planning and architecture discussions.

Outcome

Photograph: 12 months of learning and sharing together 😀

Challenges

Consistent attendance from optional invitees

Consistent attendance outside of the core data platform team was hard. Even with a strong push by facilitators to organize the format and discussion every week, people are busy, it is an optional meeting, and folks do not always join. Scheduling is hard across time zones as well.

Without a diverse set of consistent attendees, sometimes our conversations hit a dead end. We hit some questions where we were missing a DBA or product person to give their perspective.

Retrospectively, we wondered about offering the same reading group multiple times, to see if it revealed different discussions. Different groups might engage the material in different ways. Some outside advice suggests to run a book reading multiple times [Bob Raman 2018] Recipes for Running a Successful Technical Book Club at Work

Fostering active engagement

Engaging folks on the content had its ups and downs. Some chapters were more interesting than others. The video summaries we chose were not that comprehensive. But the video summaries did offer some context for folks to engage without reading. We rarely went page by page in the book as suggested by some outside advice [Nikhil Devraj 2021]. The video and the book offered a balance; we could always call out the text to dive into a section if needed.

Some outside advice also recommended preparing tailored context and summary for a reading group, but we did not have the bandwidth to do this. [Nikhil Devraj 2021] Presenting in a Reading Group. Bringing other outside material and deeper context would have been an interesting tip for us to try [Bob Raman 2018].

Retrospectively, we wondered about other ways to foster engagement. Some attendees may prefer async communication to speaking up in person. For example, starting a discussion on a chat-based collaboration tool could have enabled more engagement.

Benefits

New perspectives

When folks cross-team did join, there were some great conversations, experience sharing (even outside of current job and work), and perspective building. The technical reading group provided a context outside of project execution to have technical discussions. We listened to production war stories and outside job experiences that might not have been shared in another context. Much knowledge and expertise sharing was fostered in the context of a reading group but not in the context of a project.

Flexing new muscles

We also had room for teammates to practice facilitating and note taking outside of project execution. We often have to facilitate and take notes for post-mortems, incidents, and design reviews, but technical reading groups offer another place for different teammates to practice this. Opportunities like this foster growth from different team members in a lower stake environment.

Skill enhancement

When we went back to our project work, we referred back to what we learned in the reading group. The discussions we have in the reading group become part of our identity. We built a shared technical understanding for the team. This technical understanding became the baseline for how we think about our architecture as a team. We all get to engage together with the topic and carry it together through our work.

Culture enhancement

We were building an engineering culture of learning. There was an actual sense of accomplishment in finishing and being part of the reading group. In addition to a technical achievement, it was a culture building activity. These activities help signal what’s important to our team internally and externally. We all loved the chance to learn and grow together. It also allowed us to connect with our teammates in our remote work environment. Together, we were building an environment for discussion and learning across teammates.

Go start a technical reading group!

Technical reading groups can foster growth, learning, and social building. It has been fun get one started at Motive. We hope you find this insightful. Feel free to share with us your own experiences with technical reading groups.

Come Join Us!

We love building things and having fun while doing it. Motive is hiring! Check out the latest Motive opportunities on our Careers page to join our rad engineering team!

--

--