7 Secrets for Scaling a Technical Book Club
How to help your growing team grow its book club
Our weekly technical book club is one of the things that I think makes our engineering team at the Flatiron School special. Since I joined the team over three years ago, I’ve been a keen participant, and I have honestly learned so much with some of the coolest and smartest people.
If your goal is to level up as an engineer, there’s really no better way to grow besides reading a bunch of technical books (aside from pairing, pairing is great for learning and knowledge sharing).
Our team itself has grown in my time here, and one of the challenges has been building our book club for scale. What worked for eight engineers did not work for 20, and especially not 30. But we’ve weathered the challenges with experimentation and iteration and achieved decent results. So whether you are looking to start a technical book club or if you’re trying to scale an existing one, here are some tips and helpful hints.
1. Assemble a task force.
As our team grew, it became clear that we needed a group of people who cared deeply about book club to drive it forward. A task force doesn’t have to be super intense, but it does have to handle regularly some of the administrative tasks that go into running a larger scale book club. (I am on this task force now, and I have dubbed it The Illiterati.) We come up with new ideas for how to run our book clubs, schedule and book rooms, provide book suggestions, procure books, send out the occasional survey, analyze the results, and iterate. Our goal is to provide a framework for our book club, and then each iteration of it essentially runs itself, at least for nine weeks.
2. Cap the number of participants per meeting at 10.
At one point when our engineering team had reached about 20 people in size, I remember sitting in a packed conference room with the rest of the team and desperately trying to get a word in about the book 99 Bottles of OOP by Sandi Metz. It was impossible! Between the remote folks and the in-person attendees, we simply had too many people to foster a meaningful discussion.
Thus, we of The Illiterati recommend capping the number of people per book club meeting or session at 10. Or at least don’t stray too far from 10. The conversation simply gets harder to manage when there are too many people in the room (or on the call).
As a team, we hold three book club sessions concurrently, for three different books, each with a maximum of 10 people. They are usually scheduled during the same time, but if groups can’t meet at the preordained time, they are free to reschedule on their own.
3. Do a Pitch and Pick Session.
For a while, The Illiterati decided on the books we’d be reading, since everyone loves a good secret society deciding things behind the scenes. The rest of the team, however, was not as jazzed as we were about certain topics and participation fell.
So, now we have initiated a “Pitch and Pick Session” to kick off every round of book club. Since we cap the number of participants at 10 people, we ask that a passionate representative (often representing one squad) pitch a book they would like to read to the wider engineering team. This way, we get a larger variety of suggestions that may be more relevant to certain subunits of our extended team (Elixir specialists, microservices aficionados, aspiring managers, etc.) Good vibes, excitement, and jokes tend to come out of this meeting too, so I think it’s good for overall morale.
We then invite participants to vote on their favorites, and then divvy up groups accordingly and make a Slack channel for each one. We’ve tried both real-time voting and rank-choice voting. Both work, but rank-choice voting better accommodates anyone who can’t make the live meeting. Allowing participants to vote with their feet instead of sticking with their domain squad has also given us more opportunities to work with and learn from other members of our team.
4. Provide remote-friendly options.
Booking rooms for book club meetings during business hours can be difficult, so when all else fails, try a remote-first book club. We’ve done this with varying degrees of success, but regardless, a remote-friendly option should be top of mind. Although our book clubs all meet over the lunch hour, we do block off time on the calendar so that no one forgets. The smaller size of each book club also helps with ensuring our remote team is able to participate fully in the discussion.
5. Nominate a leader every week.
A book club without a leader will stagnate. We like to ask volunteers to lead the discussion and take notes each week. The leader for the week does not have to know all the answers, but they are responsible for taking notes and coming up with good discussion questions. They are also responsible for making sure that there is a leader for the next week’s meeting.
(Bonus tip: Keep your notes in a publicly accessible place. We sometimes read the same book again, so having a set of notes to reference the second go around is enormously helpful.)
6. Host time-scoped book clubs instead of book-scoped ones.
In the past, we read a chapter a week of a book and kept reading one book until it was done. This is fine for completionists, but more practically, it leads to people getting tired of the book. (I remember reading Confident Ruby by Avdi Grimm and wondering how the book wasn’t over yet, especially chapter four. You know what I’m talking about.) By week 12 of a book, most of the participants will probably want to call it quits, but they’ll slog through it, just to say that they did it.
Now, we timebox our book clubs to be nine weeks. Some groups still aim to finish the entire book in nine weeks, but others opt to finish as much as they can in the same timespan. Our rationale for doing this is pretty similar to having time-scoped sprints instead of feature-scoped ones: you get more value and have aligned expectations around timing. After the nine weeks are up, we kick it all off again with another “Pitch and Pick” session.
7. Get buy-in from leaders.
It helps to have management buy-in, but perhaps equally or more important is buy-in from your senior developers and other influential people on the team. Without key participants taking book club seriously, you won’t get the results you want. In our experience, some of the key benefits of a technical book club are gaining technical skills, yes, but also developing a shared vocabulary on the team, which helps with writing readable code and maintaining it, as well as designing wider patterns and systems that everyone can understand.
So, as long as you can persuade the most persuasive person on your team to join book club, you should be set! If that’s you, great! If it’s not, find someone who can help you be the standard bearer for book club. Trust me, it’s worth it.
Suggested Reading List
Here are some of the books we’ve loved over the years!
- 99 Bottles of OOP by Sandi Metz
- Confident Ruby by Avdi Grimm
- Practical Object-Oriented Design in Ruby by Sandi Metz
- You Don’t Know JS (series) by Kyle Simpson
- The Road to GraphQL by Robin Wieruch
- Designing Elixir Systems with OTP by James Edward Gray and Bruce A. Tate
- Programming Phoenix by Chris McCord, Bruce Tate, and José Valim
System and Code Design
- Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four
- Design Patterns in Ruby by Russ Olsen
- Working Effectively with Legacy Code by Michael C. Feathers
- Microservices Patterns by Chris Richardson
- Building Git by James Coglan
- Domain-Driven Design by Eric Evans
Teamwork, Process, and Management
Want to work on a mission-driven team that loves punny task force names and reading great books? We’re hiring!