Starting an Engineering Management Book Club

For the last several months some coworkers and I have been running an engineering management book club at work. It’s awesome. Not only do we get to read and discuss great books on management and leadership (the secondary goal), but it’s also become a valuable support system that many of us didn’t realize we needed (the primary goal). While some of us are new to leadership roles and some are veterans, I think it’s safe to say there’s one thing we all agree on: leadership is often lonely. Traveling upwards on a power hierarchy is unavoidably isolating.

Jason Wong wrote a blog post on the notion of cultivating a “first team mindset” at work. In the midst of the gazillion tweets/blog posts on management I’ve read it’s one of the ideas that’s stuck. The premise is that as you climb the corporate ladder your “first team” - your support system - must become the peers at your level vs your team of reports. Jason obviously isn’t saying to stop caring about your reports, but rather I think he’s making the point that supporting the team that reports to you is natural and easy. (Almost) Everyone does that. But supporting your team of peers - the coworkers who presumably aspire to the limited set of leadership roles that you also aspire to - is much less natural, but much more important. Because in the absence of strong organizational first teams at leadership levels companies devolve into political infighting and communication silos that hurt company output, which in turn makes everyone worse off.

But practically it’s hard to build this first team when you don’t actively work together. A “first team mindset” is easier to envision with a handful of Directors or VPs that often find themselves in meetings together, but what about frontline managers from disparate parts of the company? It can often feel like you’re so busy putting out fires or responding to the needs of your reports that you don’t have the opportunity to create a support network at your level.

To make matters worse, when I first became an engineering manager I had no idea what the hell I was doing. I think that’s often true. My instincts on what to do and what to avoid were entirely based upon the past experiences I had being managed. I tried to emulate the good managers and avoid the behaviors of the bad managers. The existential problem with solely drawing on personal experience is that everyone’s personal experience varies. It feels ridiculous to be a bad manager just because you’ve always been managed poorly.

Fortunately it was mostly okay because I was absurdly lucky to have some incredible managers, and while that grew some of my instincts it didn’t cover every use case. I still regularly encountered novel situations where I didn’t know how to proceed.

While some companies offer management training in various forms (including classes on psychological safety, unbiased feedback, hard discussions, etc), I haven’t worked anywhere that’s offered classes on engineering management, which I think has its own unique challenges. What do you do when a team doesn’t want to use Project-Management-Software? What are some indicators that I can use to evaluate if my team is being productive? And the king of all management questions: how do you determine your priorities?

To be clear: these are still incredibly hard questions. But the first engineering management book I ever read - High Output Management by Andrew Grove - blew my freaking mind. I still think about the diner analogy when evaluating bottlenecks in my team’s workflows. I still believe that the single best measure of a leader is the output of the org underneath them. It’s hard to say the extent to which that book impacted my views on management but it’s safe to say the impact is significant. A lot of what I read in Grove’s book became implicit in how I think about work.

It also opened the door to the immense personal value of reading management/leadership books. It’s been great to be able to use the wisdom contained in books like High Output Management, Resilient Management, and An Elegant Puzzle to guide me through past and future circumstances. Fortunately while the specifics of the technologies change the people problems of building great software are timeless. Reading books is a great way to have more ownership in your own development regardless of your current circumstances (e.g. no training, a bad manager, etc).

An engineering management book club is the best of both worlds. It allows members to build their first team while leveling up their management practice. I can’t recommend it enough.

I’ve now organized a few iterations of book clubs so here are some pragmatic tips for doing it yourself:

1. Do it earlier in the day, 1x per week. If most of the company wakes up at 10am, start book club at 9am. This has two benefits: (1) It minimizes the impact of sudden, inevitable, and critically important meeting conflicts that occur during typical work hours, and (2) the big meeting rooms are easier to schedule on a recurring basis.
2. Cap a given book club at a size you feel comfortable with. For us that’s 10 members. Too big a club and it’s hard to have space for everyone to contribute, too small a club and any absences make it feel pointless to hold the session.
3. Designate a facilitator per book. The facilitators job is intentionally light weight: manage the meeting invites (and cancel book club during holiday weeks) and ensure the meeting starts/stops on time.
4. Read one chapter a week. It’s tempting to read more than one chapter a week but I’ve found it difficult in practice, especially at larger group sizes. Besides, even if the chapters are short the goal of book club isn’t to deeply study the contents of the book, it’s to facilitate and engage in the conversation the book creates.
5. Start with a simple introductory ice breaker each week. I typically use: “What’s on your mind?” Another good one: “If you really knew me right now, you’d know that…”.
6. Pick a book together, majority rules. Create a doodle, crowdsource book options, and timebox the decision to one week.
7. Diverse book clubs are better. “Diversity” here has various angles: engineering domain (e.g. product vs. infrastructure), titles, gender, race, reporting lines, etc. The one caveat to this is that our book club is explicitly targeted towards Team Leads/Engineering Managers and above.
8. Agree on pre-defined social rules. Defined social rules up front help ensure the group dynamics you want. When you send out the initial invite to join book club include acceptance of the social rules as a requirement for joining.

Here’s a modified copy of an email invitation I’ve sent previously:

Hi,

A few TLs/EMs and I are interested in starting an engineering management book club. This email is to gauge your interest in joining us!

Group parameters

• 8-10 members, composed of TLs+/EMs+.
• We will use our first session to get to know each other and crowdsource books to read, which we’ll then collectively vote on during the week. The second session will be discussing the first chapter of the book we select.
• There is a primary facilitator (it’s me) whose responsibilities include managing calendar invites, adding descriptions to those calendar invites, and kicking off discussion and keeping it going (often as simple as “so what stood out?”). This facilitator role can change over time.

The commitment

• Starting [START DATE], we will meet weekly from 930am-1030am on Wednesday mornings in a room on 10, 11 or 12 in the NYC office. We will likely take breaks for several weeks during the holidays. We will end promptly at 1030am.
• This will be a closed laptop meeting (be present!).
• You commit to reading the assigned reading beforehand. We’d prefer to spend time in discussion, not recap.
• We’ll commit to having Vegas rules. Participants should be able to safely express their opinions on the topics we discuss without fear of reprisal, with the caveat that the discussion follows typical and expected levels of decorum appropriate for group office discussions (aka don’t talk shit about specific people).
• You are responsible for buying/expensing your own book.

The ask

• Can you commit to joining and attending the book club? If you are interested, please reply to me directly. You will eventually be added to a recurring calendar invite beginning [START DATE].

This invitation will close in two Fridays from now.

Thanks! Happy to answer questions.

P.S. We’d like to keep this round of invites closed to those on this list to keep the book club below a certain size, so please do not forward this invitation to others.

A couple of other thoughts that may be helpful:

• We’re not draconian about attendance or showing up on time because life happens and the NYC subway is far from deterministic. Out of respect for everyone’s time we make it a point to start and end in a timely fashion, regardless of if everyone is there or not. If you miss a week you’re accountable to keeping pace with the rest of the group for the following week.
• As a facilitator I try to be mindful of meeting times and I’ll let people know when we have 10 and 5 minutes remaining.
• Initially I thought I needed to come up with prompts to keep discussion going but in practice I’ve found it unnecessary. Instead I simply start each session with, “so, what stood out?” and the discussion takes off on its own from there.
• More often than not we don’t actually discuss much of the chapter contents. That’s totally okay. The chapter often triggers thoughts and reflections on what’s going on in people’s lives and teams, which in turn allows other people to share their experiences and opinions. And it’s through that process of sharing and learning from each other that the first team builds every week, which is the actual goal of book club.