Originally published on my blog.

TL;DR

In this post I'm going to show you:

• how we implemented the book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few learnings, comments and (as I usually do in my book posts) quotes

Those interested in some data metrics, scroll to the end of the post, after the quotes :)

What book did we read?

We read the book called The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford. This is a book that, arguably, everyone in IT should read.

The book is really awesome, and here's the Amazon rating:

If you don't trust Amazon for some reason, here's the Goodreads rating:

The rating score of 4.25 out of 5 from almost 19k votes is a lot on Goodreads.

How did we do it?

We started reading the book on Jan 21st and finished it on Mar 11th. So, for 6 weeks we read approximately 50 pages per week and then discussed it in our mobile dev team meetings.

This is only 10 pages per workday, in case you were wondering. Here's a short post on the math behind reading 30 books per year in case you're interested.

What did we learn?

We learned that there are 4 types of work:

• business projects
• internal projects
• changes
• unplanned work

We learned some new phrases like FUBAR and MOADF, and we learned that everyone needs idle time, because if no one has idle/slack time, WIP (work in process) gets stuck in the system just waiting.

Also, we learned that getting the whole company working together to the same common goals only works if people know what the goals are. So, it's good to have OKRs/KPIs/yourVersionOfGoalTracking publicly available and set by each department and their team members.

What discussions did the book start

The book also spurred some exciting discussions about:

• how could we get to the single-piece flow
• how to deal with unplanned work
• what to do when asked to deploy something on Friday
• what are our bottlenecks
• how does our WIP look like
• what ticket management systems we used in the past, etc.

What we didn't quite like

There were some things that we didn't like:

• the ending was too happy-go-lucky; we expected something more along the lines of a Game of Thrones ending
• Bill's wife
• Brent was too realistic, gave few of us scary flashbacks
• Bill didn't treat developers with respect. I quote:
  • “Developers - I had forgotten how quirky they can be. To me, they seem more like indie musicians than engineers.”

Characters

Speaking of characters, it seems like we all liked the Eric character, which could be described as a mix of Doc and Jack Sparrow. That also knows a lot about process and IT and also surfs not only the internet.

Since every good novel has to have a villain, this one did as well. We liked the fact that Sarah got what was coming for her in the end. And we even toyed with an idea of who would play this character in the “The Phoenix Project” movie. Here are a few options that were mentioned:

Some quotes

As usual in my book posts, here are some quotes that we liked:

• “Until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.”
• “He has a well-deserved reputation as one of the most fun people in the company to travel with. The size of his expense reports proves it.”
• “Practice creates habits, and habits create mastery of any process or skill.”
• “A good day feels like my staff panicking about the size of the commission checks we’re going to be writing them”
• “I’ve realized that having people give you honest feedback is a rare gift.”
• “You need to get everything in version control. Everything. Not just the code, but everything required to build the environment. Then you need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on-demand. That’s how you reduce your setup times and eliminate errors, so you can finally match whatever rate of change Development sets the tempo at.”
• “Developers - I had forgotten how quirky they can be. To me, they seem more like indie musicians than engineers.”
• “Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.”
• “Effectively managed IT is a significant predictor of company performance.”
• “IDC, the analyst firm, says that there are 11M devs and 7M operations people on the planet.”
• “To tell the truth is an act of love. To withhold the truth is an act of hate. Or worse, apathy.”
• “In these competitive times, the name of the game is quick time to market and to fail fast.”
• “Turning around, he says, “In any system of work, the theoretical ideal is single-piece flow, which maximizes throughput and minimizes variance. You get there by continually reducing batch sizes. “You’re doing the exact opposite by lengthening the Phoenix release intervals and increasing the number of features in each release. You’ve even lost the ability to control variance from one release to the next.”

Show me the data!

So, it does seem that we liked it and had fun, but how do you measure that?

This is how much we liked the book on a scale from 1-10:

Funny piece of trivia was that iOS devs used floats, and Android devs used integers. 💪

This is how much we liked the book club implementation on a scale from 1-10:

And, finally, this is how likely we want to do this again in Q2 on a scale from 1-10:

I promise I didn’t set this graph up on purpose to look like this, but it does look kinda cool. 😂

Conclusion

We liked this experiment and will continue doing it. I hope you found it valuable and that you also may wanna try out this within your teams. If you have any questions, please ask in the comments section.

And, a question for those that already conducted book clubs in your engineering organizations, what books did you read?