fkr

The book I’ve finished on New Years Eve was Debugging Teams so what’s better than to kick-off this year with a review of it. It helped that I was asked on twitter to post my thoughts on it as well ;)

I’ve mostly read the paper variant of it (since Lenz sent me his copy). Partially I read it digitally.

Debugging Teams was written by Brian Fitzpatrick and Ben Collins-Sussman. One piece of software they’re known for is Subversion. The book was initially published in 2012 under the title Team Geek, the second edition was released in 2015. With 155 pages a fairly quick read.

The book is structured in six main chapters, each covering one major item that relates to fostering better team culture. The book manages o tackle the subject of team culture in a scope that makes clear that team culture is much more than just the simple interaction in between team mates. This already becomes clear from the main subjects of each chapter:

• The Myth of the Genius Programmer
• Building an Awesome Team Culture
• Every Boat needs a Captain
• Dealing with Poisonous People
• The Art of Organizational Manipulation
• Users are People, Too

The introduction starts with a quote which establishes the base line for the book:

Engineering is easy. People are hard.

(Bill Coughran)

The book manages to be an easy read, sprinkling interesting quotes and stories. Furthermore the style of the book is supported by sketches and graphics presented in a “comicy style”.

Debugging Teams builds on top of the core concept of HRT - Humility, Respect and Trust. With Chapters such as ‘Dealing with Poisonous People’ and ‘The Art of Organizational Manipulation’ it covers topics that can be nerve wrecking for some people and the way the authors give Hands-on advice can be helpful.

The introduction contains the usual paragraph on the targeted audience of the book and the authors recommend this book not solemnly for software engineers but any person that “works on any sort creative endeavour with other people”. From the style of the book I’d say that the book is a very good read for people that have not read a whole lot on the subject of managing organizations or who so far have not dealt a whole lot with the non-technical aspects of working with teams. However for experienced engineering managers this is still a worthwhile read - expect to find items that you’ve read / heard elsewhere. The chapters Building an Awesome Team Culture as well as Every Boat Needs a Captain give a good intro into managing by covering a fair share of important items. Most of them are covered briefly, so my recommendation would be to go into more depth with further literature. Concepts such as Servant Leadership, Mission Statement and efficient meetings structures are touched and the Leadership chapter covers some of the important antipatterns. I’ve never worked in a large organization so parts of chapter 5 (The Art of Organizational Manipulation) were a tad difficult for me - especially since I don’t like the concept of manipulation ;)

Florian asked me on twitter (as quoted in the intro here) to give a review of the book. He phrased it in this way:

Please share how you liked it - I am a bit in doubt since it’s by the SVN guys. They started sharing their community experiences and standards when noone else did - i read that stuff with a lot of interest - but back then they also weren’t stellar examples of humility.

Personally, I was not that close to the SVN community to judge it from back then. At a couple places in the book the authors attribute that certain aspects raised back then, were valid after all. From my personal history, I’d say that if you one has a track record of not being a good example and this lead to lot’s of learning, these learnings are worth to be shared ;) When I look back on when I started working with teams and became a manager (the first time round when bytemine had employees in 2004/2005) I was terrible at that. A lot of the items and advises I share now with my directs (who are engineering managers themselves) could just as good be advises I give to my younger self ;) Actually this learning experience that I go through is what allows me to discuss with others and share my thoughts.

Generally the book is very google-centric. Well, I guess since both authors spent lot’s of time there this makes sense, but for me the book does a lot of ‘google here’ and ‘google there’.

Take-a-way

What are my key take-a-way’s from this book? Once I’m finished with a book, I try to go over it and see what I can take out of it for the future. Either quotes, techniques, methods, anything. For Debugging Teams these are:

Interview for culture, before the other aspects

Often the hiring process is as follows (or similar):

1. First round, check the basics
2. Go deeper, cover technical stuff, see whether the applicant is up for the job
3. Cultural fit

When the aspect of “interviewing for culture” is covered the example is given that companies actually put the ‘interviewing for culture’ even before the technical aspects, since “they don’t want to even consider people who would fit technically but not culturally”. I like that.

I usually consider the ‘cultural fit’ to be a ‘cultural add’. Since I not only want newcomers to the team to fit into the culture, but also would love for them to add something to the culture.

Team culture as yeast

In order to transport the concept of how to grow a good culture the authors give the sourdough example - this is a good analogy for growing a good culture.

Team culture comes from the beginnings and if one manages to foster the culture it will start to grow by itself, fostering more of the desirable culture. If the starter culture is weak, don’t expect any wonders coming from it.

Want to read this book?

As stated in the intro. A friend of mine sent me this book and since I like passing books on, I’ll pass this on. You want to read it? Drop me a mail, and I’ll mail this copy to you. There are only two small things I ask:

• Once you’ve read the book, post a review somewhere on the internet. Doesn’t matter where, just somewhere.
• Pass it on afterwards.

Feedback?

Feedback is very much welcome - see contact.