Leading Geeks, by Paul Glen

This book echoes a lot of beliefs that I hold true, and validation is always a pleasant thing. You’d think I liked it because of that, but I found it a tough read. The style is very dry and overly structured: the premise is broken into a few large sections, each section split into main topics, each topic contains a list of items, each item detailed. While functional decomposition is great for software, it makes for a tedious book! Plus, when an item touches on something covered elsewhere, a simple “Chapter Ten will discuss this” is written and tying the points together is an exercise left for the reader. In a few places this would happen multiple times on the same page, a habit I found really irritating.

That said, the basic theme is one with which I wholeheartedly agree: successfully managing software developers is much more complicated than simply handing out requirements and posting deadlines. A leader of technical people needs to provide a comfortable environment where people can be creative and productive. Insulating the talent from corporate politics while singing their praises up the chain and managing the ambiguity that is inherent with software are other major facets. Finally, something that good leaders understand is geeks don’t suffer fools gladly; amusingly this is often directed at the leaders themselves!

A hodgepodge of other facets this book discusses: power is useless for manipulating geeks; creativity can’t be controlled; and dates not tied to anything in reality will never motivate a team. All of these I believe are closer to the truth than not, but I wouldn’t call them infallible, either. For instance, while developers tend to respect knowledge over power, we’ve all been through enough layoffs to understand who really holds the cards. Interesting discussions.

While Glen mostly gets it, he has some odd opinions on seating. He feels that team rooms are bad for concentration and lead to productivity loss. Cubes, though, can be a good thing if they are all the same because there isn’t any status attached to having an office. I think that the team should be able to make this sort of call; some groups I’ve seen strongly prefer a bullpen and it clearly helps the project to have them all together. Others want offices and a conference room for group meetings. Nobody wants cubes—nobody. Cubes are the worst of both worlds: they give the illusion of privacy without actually granting any, yet replaces natural collaboration with prairie dogging. Of course, I’m currently stuck and miserable in cubeville right now so maybe this passage simply rubbed me the wrong way.

I think if you are a non-technical person that finds yourself in charge of a software team, this book can provide some solid insight into the world of developers. Individual contributors that are promoted to managers could benefit from reading this too; hopefully they will pick something up about how different leading is from doing. Experienced supervisors, though, might be a bit bored.

First Sentence:

I hope that you have begun this book with a head full of questions:

• What’s different about leading geeks from leading anyone else?
• What can I do to better leverage my organization’s investment in these expensive, valuable, and temperamental employees?
• What makes geeks so different to manage?