📖 Celebrating a milestone in the technical reading group I co-lead at work by writing down how we function and things I learned along the way.
We went past the 100 meetings marks in two-and-a-half year 🥳.
During that time, we covered 12 books, 21 research papers and 24 blog articles.
In 2022, we launched a reading group at work with Sébastien, an avid reader and eager to exchange ideas about his readings. We both wanted to be able to learn from our reading, but even more so to meet people from other teams, shares our thoughts and have interesting discussions.
Our department has a “learning” policy, where each week we can dedicate around four hours to explore any topics we want as long as it is helpful for professional development. Some colleagues were taking classes, building tools that do not fit into the roadmap or to learn new technology, or anything else that made sense to them. We decided to invite people for one hour each week to discuss about books and articles we read.
From the start, we had several choices to make to organize the group, and some other choices came later one. They all had lasting effects even today. Those choices were definitely impacted by organizational constraints and by our own goals.
The constraints we had at the time were:
Our goals:
At the time, we were full remote. It would have been easier to organize asynchronous discussions, this would have allowed more flexibility and reach more people. This is also the way most technical reading group function from my experience.
But we really wanted to try to connect with people from our department and enable exchange between teams. Moreover, live discussion allow for a more intimate setting were people feel more free to share their opinions, anecdotes or even to voice a minority opinion on a subject (when it’s (not recorded)).
The tradeoff here is that the barrier to join is higher (less flexibility, active engagement), but the quality of discussions and the human connections are better.
From the start the goal was to start the group with minimal structure, run a few sessions, get feedback, changes as needed and see where that would lead us.
As said above, we started without too many preconceived ideas on that, and what we currently do evolved over time.
We decide in advance which article or which books and chapter we are discussing (like “Next week, chapter X, Y from book Z”).
In the call, we usually start with a few minutes of informal chat, and then we start with “who wants to share notes/impressions/question/anything about chapter X?". Then we let the discussion flow from there. Everybody shares whatevery they want to share, it sparks discussion (or not), and sometimes it takes us far away from the content of what we were reading but it’s totally fine.
If the conversation dies down, we ask if anybody else wants to share something on the current chapter. Otherwise we go on about the next chapter. Rinse, repeat.
When we finish a book, we take a few weeks of break, ask people if they would recommend the book we just finished (we’ll come back to that later in takeaways, especially write down the essentials) and launch a vote for what we read next.
We are doing a weekly meeting, but we take break at the end of most books, and we cancel when we are missing most people (holidays or intense work period mostly). In the end we usually manage around 30 sessions per year.
Keeping it weekly helps with the discipline and motivation, even if we only commit to discuss one or two chapters at a time. When we have a big gap between sessions, we can feel it’s hard for everybody to get back into the flow.
Since we are doing live meeting and not asynchronous one, some people that could not join were asking if we could record so they could follow the discussion on their own time. This is a valid request but we declined after discussing it with the group. We liked the open-minded, relaxed and authentic discussions we were having.
Recording put pressure on people. You might not want to say something silly, voice discontent, share a personal anecdote (or many other reasons) if you know it’s recorded and any people in the organization might watch it. Additionally, it is very low commitment for the people asking us to record since they might watch it (but most likely would not do it regularly) but require more commitment for us.
The tradeoff here is that we might have reached a larger audience, but we would have lost authenticity in the content of what was discussed, which was not worth it for us.
Below are the takeaways from this experience. Most of it is transferable to many volunteer activities.
Make it happen on a regular schedule, for extended periods of time. It takes time for people to show up and stick to any activity. So by making it a regular occurrence, people that wanted to join were having an easier time to manage their schedule to join us.
Having a page with essential information about the group was very useful for us. We started with a short wiki page with only a few lines. Current book: <title>, next session <date>, we are discussing chapter's <X,Y,Z>. You can reach <name> or <name> for questions. It allowed to have a persistent reference page that people would know they could look up if they needed to, even when we shared messages about it in an ephemeral messaging application (our Slack channels for instances).
Over time, that page grew to contain a FAQ section, and is used to record the history of every book and meeting we had, as well as maintain a list of potential article/books the group would like to read next. That way we can record easily and transparently when someone makes a suggestion, and when the time comes to choose a new book, it’s easy to pick a new one.
We even keep a list of the group’s favorite book (see links). We use a system of emojis to sort our readings:
Talk about your event regularly, you never know when people might join. For us, it means that at the start of each new book discussion we send a message in various communication channels (Slack before, now Microsoft Teams). We give a link to our wiki page and to our community channel in Slack/Teams so people can contact us or share readings with us.
By connecting to people that like to read and learn, as well as by broadcasting our group’s activity, we get a ton of recommendation internally by people that don’t join our discussion but enjoy reading. They get to see what we already read and what we are planning to read (see takeaway on keeping a wiki page), and in return they share what they read recently and that they found interesting.
We even have some people writing technical blogs that shared their articles with us!
As with the example of people asking us to record our session, you cannot please everybody. That can be hard to accept. But you need to draw a line sometimes to protect the group integrity, and not drive away people that are participating regularly.
Since our group is relatively small, we could discuss issues and requests with everybody when needed, which helped too.
Something I did not consider for a long time was to let people that did not read the current chapters to join our group discussions.
But we tried it at some point, and it forced us to do a summary of the current chapter, which sparks discussion sometimes as we did not remember the same content. It also leads to people able to share anecdotes or ask question on the topic at hand, which fueled discussion and was interesting for everyone.
It also helps people that want to “try” a reading group session before committing on joining us for a full book. They don’t have to read anything, they can just join us and see for themselves if the format suits them.
There is a limit to it. If the majority of people did not read the chapters, it can feel a little bit strange and shift the balance towards passive consumers of the meeting instead of being actively engaged in the activity, and that should be avoided.
By writing down an agenda for each meeting, what we read and what we enjoyed, I was able to put together a quick summary of our activity (same as I shared in the introduction “more than 100 meetings over two-and-a-half years […] we covered 12 books, 21 research papers and 24 blog articles.").
This allowed to share those statistics more widely once per year or when we hit a milestone, which gave even more visibility to our activity and helped interest more people.
I did not expect how much impact this would have, but it turns out people love stats.
As a side effect of running a reading group, I got to meet like-minded people that I would not have had the chance to meet otherwice, because they were on very different team, or not even in engineering.
As a bonus, here is the list of our group’s favorite books/articles over the years (from most recently discussed to least recently discussed):
Being part of a technical reading group has been a very positive experience and running it as well! If you have any books to recommend, feel free to share them!📕