For the past 18 months at 99designs we’ve been running a book club for our tech leads. What started as an ad-hoc process to jump start quality in our code review has grown into the key component of our senior staff development.
I chose a book club because as a largely self taught dev manager books were where I developed all my foundational skills. I thought that in trying to scale out those skills across a broader team the natural shortcut would just be to get the new tech leads to read the same books, rather than just have me regurgitate them in 1:1 meetings.
In this post I’ll just quickly explain how we do it, which books we’ve done to date and why, some books we’re aiming to do, and share some general thoughts on the process.
How it works
The tech leads here have a fortnightly scheduled catchup where we review ongoing work, discuss any inter-team issues, and the CTO and I hand out high level guidance.
These meetings have a standing agenda item of “review book club chapters” where we discuss the chapters set for review. There’s nothing fancy about the format, we go around the circle and each tech lead speaks to what they found of interest in those chapters, ideally tying it back to things that we’ve done before at 99designs to make the ideas a bit more concrete. As the facilitator I’ll usually go last and point out any interesting ideas that may have been passed over, and to try and tie back what we’ve learned to the higher level direction the CTO has set if possible.
We aim to review two to three chapters each meeting, which works out to roughly 30 pages. While 30 pages isn’t a lot to read, it is a lot to talk about (and if you’re reading something that doesn’t give you much to talk about in 30 pages, you probably need to be reading something better).
At one point we tried to increase the pace we were getting through the books, but we discovered an inverse correlation between the number of chapters read and the quality of discussion. Once the quality of discussion dropped off, the motivation to participate in those discussions also dropped off, which then finally lead to fewer people doing the reading.
What we’ve read
Clean Code by Bob Martin was our first book. I chose this book to start us off for a couple of reasons.
The first was that I wanted to open with something technical to help ease the transition from engineer to manager for everyone in the group as for most of our tech leads the promotion was quite fresh and I didn’t need to scare any of them off.
The second was that we needed to build up a common vocabulary for what good code looked like. As a polyglot shop we’ve got a lot of variety in programming background and style. That diversity has been a great boon in the quality and quantity of new ideas our team gets exposed to, but the cost of cohesion in our architectural style.
We used clean code to get alignment between the leads on definitions, which then provided the base for us to agree which principles of clean code we should be applying day-to-day in code review and system design.
High Output Management
High Output Management by Andrew Grove was our second book, and the first management themed one. I’d decided the next step in training our team leads was to build up an idea of middle management from first principles.
If you’re new to management and don’t understand the nuts and bolts of your new day-to-day activities this book is a great go-to. It covers performance reviews, 1:1 meetings, measuring unmeasurable things, planning, meetings, training, and everything else.
While originally written in 1983 it holds up really well. Fans of Spotify’s guild’s and tribes model will find it eerily foreshadowed in the chapter on matrix management.
We’re back to a technical book with Release It! by Michael Nygard. In a pure engineering sense there are two things that make a good system: ongoing changes to the system are cost-effective, and the system keeps doing what it’s built for without too much care. Clean Code gives a good foundation for the first, but doesn’t speak very well to the second. Release It (for me) is the definitive guide to designing web apps that stay up.
99designs has always been pretty good at the reliability aspect of software engineering, so the main benefit of this read through was putting names to practices that had organically grown here. The other helpful part of this book was around capacity planning. As a fast growing startup it’s too easy to be purely reactive – release it can give you a pretty useful framework to get back in front of the scaling curve.
If Michael Nygard ever sees this: please, please write a “post-cloud and post-JVM” second edition. A lot of what’s in the book is timeless, but a bunch of chapters have not aged well.
Making Things Happen
Back onto the management track with Making Things Happen by Scott Berkun. With our tech leads largely on top of managing the purer engineering elements of their work, the next step is doing all that to a schedule.
As our product offerings become more and more integrated the art (s) of project management: requirements negotiation, stakeholder management, and schedule alignment become more and more important to keeping our pace of development high. Scott’s book provides a no-nonsense, approachable, and pragmatic guide to humane product management. As such, it’s an excellent intro for the most reluctant project managers of all – former engineers!
Practical Object-Oriented Design in Ruby is probably my favourite book on software design to date. It does a great job of explaining OO principles and has a strong focus on design as an iterative process rather than achievable end state. The only reason I usually recommend Clean Code before this is that Clean Code is a bit easier to mechanically apply to code review. To me Clean Code stops you from making a mess of your system, and POODR helps you create new opportunities in your code.
The Essential Drucker is not quite as useful as High Output Management for giving a framework for management, but chock-full of useful bits to do with the day-to-day of management. Will be good for rounding out what the tech leads have learned so far, and also goes to show how many “modern” ideas of management aren’t that modern.
When starting the book club I genuinely, but mistakenly, believed that if I can get everyone to read the books I’ve read we’ll have 100% agreement on how to build software and we’ll get alignment for free. That is not what happened.
What happened for me, running the team and the bookclub, is that I got to take a bunch of people with different backgrounds and skills that I didn’t know very well onto my home turf – books. By using the books as a kind of common ground it let me understand everyone’s individual perspectives in sharper relief.
What happened for the tech leads? They read some good books, learned some new tricks, and I hope got a better understanding of perspective as an engineering manager from the source of all my own training.
Since instituting the book club amongst the tech leads we’ve also had some trickle down benefits. Some of the product teams run their own bookclubs, and there are a couple of cross-team opt in book clubs too, the most notable being our React article-club. I’d strongly recommend starting one yourself.