Run a better book club

[!info] This whole “how to run a book club” came from a DM from Michael Margolis on 2025-10-17 when we were planning a book club at Medium for Designing Data-Intensive Applications.

Be clear about the PURPOSE. AKA “Start with Why”

Why are you doing a book club at all? WIIFM (the participant, and the org)?

To level up how we, as engineers, design, debug, and reason about large-scale systems. Not just to build them, but to build them to be efficient, sustainable, and easy to reason about.

DDIA gives us a shared language for thinking about tradeoffs: consistency vs. availability, latency vs. durability, fanout vs. cost, local correctness vs. global truth.

 The goal isn’t to memorize theory, it’s to connect the dots between the systems we already have (medium2, Conduit, EMR, DynamoDB, Recs, whatever, i’m just spitting out buzzwords), the design decisions that got us here, and how to level that up.

Set a clear, non-threatening schedule, that respects everyone’s time.

Biweekly is good. 30-60 minutes. 1-2 chapters per session.

Try to keep it to 6-8 sessions. Attendance will drop the further you go.

Define what the sessions are

Get prescriptive about what makes a good session. I’ve run meetings with this format and liked it:

1. 5m: Ice breaker / share-out: What was one a-ha moment, observation, or thing that triggered you when you compare what you read to what we have in production?
2. 30m: breakouts (it’s hard to have a meaningful discussion with 8+ people) around some set of possible prompts. They should ALWAYS include the final “… cool story bro, and HMW apply this at Medium? Do you see any anti-patterns or opportunities anywhere? What might the impact be if we DID change this? What would the tradeoffs be?” <-- that gets them focused and gets them working on collective problem solving towards a shared purpose
3. 10m: Come back together, and each group does a shareout of what they learned, ideas they came up with, and interesting tradeoff discussions
4. 5m: closer: Reflection (opposite of ice breaker) - what’s one thing i learned, what’s one takeaway or idea i think i may use in my work going forward, what’s one idea i want to take to my team, what’s one thing i learned that I wish I knew before? 1. “What’s something that struck you from these chapters?” (keep it more general)

Have a note taker that can capture and synthesize and share this out (anonymously, so folks feel safe to be ignorant)

Share all this out ahead of time

As part of the purpose, I like to lay out more of the why at a meta-level, so people can read the book with these things in mind.

My actual intro message for DDIA was:

Hello friends 👋 Welcome to the book club for Designing Data-Intensive Applications!

Why are we doing this book club? Our primary goal is to level up how we--as engineers--design, debug, and reason about the systems we build and maintain at Medium. Designing Data-Intensive Applications gives us shared language for thinking about tradeoffs (consistency vs. availability, latency vs. durability, cost vs. correctness, etc.) and reasoning through complex problems.

The goal of this book club is not to memorize theory. It’s to connect the dots between the systems we already have, the design decisions that got us here, and how we need to go about leveling that up.

By the time we’re done with this book, my hope is that you’d agree with these statements:

• I have a stronger mental model how how data should move through Medium, and what it should cost
• I have a deeper intuition for understanding and debugging complex systems
• I have a better design vocabulary and larger toolbox of design patterns and practices, and I can better design systems and better communicate these designs
• I am more cost-aware of the tradeoffs of my designs, and can better reason about how to explore various tradeoffs and communicate these tradeoffs
• I feel an increased sense of ownership and stewardship of the design, performance, and cost of our systems

This channel and the calls we’ll be on are a place we should all feel comfortable asking questions. It can sometimes be intimidating to raise your hand and admit that you don’t understand a concept, or how that concept applies to us here. Let’s change that! Decisions, tradeoffs, design is easy to learn and hard to master. Let’s help each other--and the org--level up.

What’s the schedule?

DDIA is 12 chapters. We’ll read this book in 12 weeks, and we’ll meet every other week for an hour to discuss what we’ve read. In between our meetings we can (should!) still chat about what we’re learning and how it applies to our actual systems right here in this channel.

We’re starting on November 3 (which gives you just enough time to order a fresh copy)! But no meeting that week, just reading. I’ll set up some calls at times that seem to work with most people here, but we can (should!) use this channel for discussions outside of the calls.