Team Building With Technical Book Clubs
How I approached team building and professional development in a pandemic
How can I best help a new engineering team grow professionally when I’ve never met them in-person? This was one of many challenges in front of me when I changed teams and lines of business after the pandemic pushed us into working from home. When I accepted this role, one of the areas my senior manager asked me to guide the team on was engineering best practices. The length & severity of the pandemic added a new wrinkle: building rapport with direct reports that I had yet to meet in-person.
Team building through reading
With my previous team, and in past companies, I’d used lunch and learns as both informal training sessions and to provide opportunities for engineers to present on topics they found interesting to their peers. This approach proved particularly effective at one company where most of my engineers were not formally-trained in computer science. But the combination of a team where every engineer already has a computer science degree, my senior manager’s feedback on where guidance was most needed, and concerns about the Zoom fatigue a fully-remote working environment could cause, a different approach seemed necessary.
Depending on the presenter, with lunch and learns the flow of information generally goes one way--presenter to audience--with limited opportunities for Q&A and other engagement. Before COVID-19, this approach was more effective because when done in-person they provided chances to socialize both before and after a talk.The fully-remote environment imposed by the pandemic took away the socialization aspect that helps make lunch and learns work well. In researching team building ideas both inside and outside of Capital One, I came across the idea for a technical book club idea on one of our numerous people leader Slack channels. Other teams in different lines of business at Capital One had been running technical book clubs and gotten good feedback. What ultimately sold me on the technical book club approach was this Medium post from a group of engineers at Zendesk. Three key takeaways from their experience with technical book club included:
- Learnings from books with broader applicability can be turned into tech talks for a broader audience.
- They’re a way to “level up” your team(s) in a particular area in a [psychologically] safe environment
- Cross-team book clubs help build social connections and collaboration
Selling myself on the idea was just the first step--I then needed to convince my new team, as well as my manager, because I intended to follow this piece of advice from the Medium post:
Try not to run book clubs at lunch time--if the material is important then you should use work time for it.
After one-on-ones with each of my engineers, and with my manager’s blessing to use an hour per week of work time for it, we moved forward with our technical book club.
Beyond the systems my team owned and the fact that half the team members were still at the beginning stages of their software engineering careers, the key reason I chose the book club approach over lunch and learns was the structure. Lunch and learns are not unlike episodic television shows in that each session stands alone with little or no connection to the sessions before or after it. I felt a book club would be more like serialized television, with each chapter in a book building on the one before it.
Technical book club logistics and actions
Whether you’re talking about a cooking recipe or recipes for successfully running a technical book club at work, you must decide whether or not to adapt it. My team followed the Zendesk Engineering book club recipes fairly closely in some cases, but not in others.
Logistics for running a technical book club
- Recurring calendar invite. We chose a weekly cadence, which set a good rhythm and consistent expectations for preparation and discussion both for the week’s moderator and the rest of the book club’s participants.
- Book club Slack channel. Especially with the recently-added support for bookmarks, the stand-alone Slack channel provides an ongoing thread to share links to resources referenced in books we’re currently reading and update meeting logistics.
- Wiki page for additional resources and summaries. We use Confluence internally, and the page tree we’ve built over the past few books includes discussion questions, chapter summaries, links to external resources, and discussion notes, as well as lists of books we’ve considered and rejected as book club topics.
- GitHub repo for programming books. None of our book club selections so far have been programming books, but it’s a recommendation we will follow in the future for the right books.
Our technical book club in action
- A different chapter discussion leader each week. This approach ensures a range of different viewpoints are brought to each discussion. Sharing the responsibility of leading discussions has also provided more opportunities for each member of my team (as well as myself) to flex our presentation and communication muscles.
- Pre-discussion chapter summary. The more members of our book club who write their own chapter summary prior to discussion (and whoever has discussion moderation duties that week typically shares theirs on Confluence), the better discussions we tend to have. This practice makes it easier to write discussion questions in advance. It also helps book club guests, who may not have read the chapter beforehand, to engage in the discussion and still learn from it.
- Book club meeting cancellations & changes. This is where we’ve diverged most significantly from the Zendesk Engineering book club recipe. We have cancelled and rescheduled book club meetings in the past in order to respond to production incidents and meet delivery deadlines. We’ve also taken a brief hiatus between each book to discuss prospective book club selections and choose one collectively before moving forward.
- Keep the book club (relatively) small. Because we limited the scope of our book club to our team, we’ve never had double-digit numbers of participants in our discussions.
- Go beyond the book if it helps the team. As mentioned previously in Book Club Logistics, links to external resources are a significant part of our written record when it comes to chapter discussions. Recorded conference talks can be a great way of reinforcing the points a particular book chapter makes.
- Technical book clubs can have cross-functional audiences. I include our data analyst and our scrum master in our weekly book club invite as optional attendees. My skip level manager provided a lot of helpful context during one discussion she was able to attend, and even weighed in on one of our book club selections. When I asked current and former team members about the top 2-3 benefits of our team’s technical book club, one of our former data analysts had this response:
I really like that it is an opportunity to talk about software engineering! It is sort of hard to find those opportunities within the data analyst job family, so I think it is great for other job families to be able to attend these sessions to improve in this area!
Outcomes from our technical book club
Here are some more perspectives about the benefits of our team’s technical book club.
Book club helps to provide additional lenses in which to think about our system that leads to a productive conversation about how to improve it.
It helps me in building my communication skills as a non-native speaker [of English] and learn [the] team’s perspective on the topic we are discussing.
I’ve really appreciated that it gives us a space to talk about the craft of software engineering. In our day-to-day work we’re usually thinking about features, bugs, tests, and timelines--the opportunity to talk about the work we do without being bogged down by the specifics of a particular project has been very informative.
Book club provides a space I feel comfortable expressing new ideas or thoughts without judgement. This helps me to continue to clarify and expand my learning/thought processes.
One of my personal principles for engineering leadership is to promote a culture where everyone has opportunities both to learn and to teach, so Christine’s and Roshan’s responses are an encouraging confirmation of that principle in action.
As we’ve read and discussed different books, the team began to see ways to improve the design of the software we own. The realization that the primary system we own is a monolith came directly from reading Chapter 5 of Building Microservices. The steps we took to split that monolith were very much informed by the approach recommended in that chapter. What we’ve read so far of Eric Evans’ Domain-Driven Design led directly to our use of immutable dataclasses in our Python code. Giving each engineer multiple opportunities to present to their teammates seemed to improve their skill, confidence, and willingness to present to other audiences. These weekly meetings also gave me another opportunity beyond 1-on-1 meetings to build rapport with my engineers. Keep in mind, even after all this time, I have yet to meet any of my engineers in-person, but I still feel as connected with them as I have with any of the teams I’ve worked with in-person.
The pandemic and Zoom fatigue have created new challenges to team building--especially when you have yet to meet in-person. Instituting a technical book club has been a great way for my team to build our teamwork and engineering skills while working remotely. Tackling logistics and modifying the book club framework to our team's needs took some planning but the results we’ve seen so far are definitely worth it. Other teams in our department have reached out to us for guidance on starting their own book clubs. I’m looking forward to seeing what we learn from our third book, and how those learnings manifest themselves in enhancements and advancements to our work.
