Debugging Teams is a guide to team management and leadership for those software engineer types who don't really want to do that stuff. I quite like doing that stuff, so I guess this isn't really intended for me, but it's a fun, short (150 page) read. It's not even 150 real pages - it's got a bunch of cartoony illustrations in there that don't really add anything, perhaps because reading words is hard, or you like to be treated like a baby, or they wanted to pad out a really short book.
On the other hand, the text itself has no filler. Unlike many management books, as well as having a main thesis, it's packed with specific advice, examples and suggestions, so that it's actually relatively dense. The main idea is that even if you don't want to do leadership stuff, you're still better off doing it than leaving it to chance and dealing with the fall out; a stitch in time saves nine. The core of their advice is to encourage a positive team culture, specifically one centred around Humility, Respect and Trust - which allows people to be open and honest and learn things and contribute without feeling under fire.
The authors have management experience from both open source (specifically Subversion) and Google. Indeed, a subtitle of this book could have been "How engineering management works (or is supposed to) at Google". Reading this book as a manager at Google, this part was slightly preaching to the choir, but good to refresh. The OSS side was... interesting. Now that we have a large number of significant, long-running OSS projects, culture in open source projects is being recognised as a big thing. In the short term, a few bright people can make a project, but over the long run, with contributor turnover, it's all about having a culture that encourages people to join and develop. This book is a great resource for people trying to work out how to run such a project.
To change tack for a moment, recently I went to see "The Book of Mormon" with my wife, on her birthday. In effect, the message is that a positive and helpful culture can more than make up for a lack of... rigorous rationality. This seems to mirror the message of the book - rather than try to have a perfect crystal of software, go for a positive community of practical people delivering something people want to use, and maybe you'll actually get some success.
Recommended if you want to know how Google engineering management is supposed to work, or if you want to make a piece of OSS people want to work on.