Leading Geeks

From the title of Paul Glen’s Leading Geeks, I expected this book to be asinine and useless. I was half right — it’s asinine but worse than useless.

The author both warns against buying into the geek stereotype and promotes it, sometimes in the same sentence: “We will move past useless sterotypes and look into patterns of geek attitudes, beliefs and behaviors that make them both unusual and unusually difficult to lead and understand.” Is this on the Discovery Channel? Or perhaps on one of Fox’s “When Animals Attack” episodes.

“Geeks are different from other people”. Besides the patronizing and often contradictory characterizations (geeks are introverted, how do you identify extroverted geeks?), there are the useless theories and models: “The tripartite relationship” of Geeks, leaders and geekwork, and the “Hierarchy of Ambiguity”, a pyramid with three layers, environmental, structural, and task ambiguity. Apparently, you just need three different words to produce a model.

The author cites project leader Tom West’s political maneuvering in Tracy Kidder’s The Soul of a New Machine as an example of resolving ambiguity and specifying a purpose for his group (developing the Data General Eclipse minicomputer), but here again the point is muddled. West vocalized different purposes for different audiences, and the ultimate purpose was to get a piece of the “glamor” work performed by another division. Which is not what I would call focus. And in the end, the Eclipse, while completed, was not a particularly successful product. However, Tracy Kidder’s book is a good read and provides at least a better anecdotal portrayal of geeks.

There are other teaser bits of valid information that go nowhere. The author recommends that geek project leaders use the iterative “spiral” project schedule rather than the monolithic “waterfall” method. (Is he talking to the geek project lead here, or is this more like a football commentary, while we watch?) Really, there is quite a bit more to software development methodology than that, e.g. the now in-vogue Extreme Programming (in which paired programming is one of the well-known recommendations, not quite consistent with the author’s statement that geeks like to work alone).

The abundance of software practices and metrics, all produced by “geeks”, refute the author’s blanket characterizations that geeks don’t care about the big picture and that it is difficult to quantify geek productivity (he settles for a qualitative assessment of how well the geek knows his stuff). In fact, he lets geeks off easy when he states that it is unreasonable to ask geeks for time estimates on tasks they are unsure of. That is bad project management, almost as bad as the typical management practice of either dictating or negotiating those estimates. Any engineer, actually any employee, should be aware enough of past experience and comparable efforts by others to make a reasonable prediction. Otherwise, there is no point in trying to manage a project — it’s just an exercise in self-denial.

Which points to what I believe is the real issue in leading geeks — it’s not the “geeks”, it’s the “geekwork”, to use Blum’s terminology. If you hire ten engineers from MIT, it’s still extremely unlikely that you will get any of the hardcore geeks behind the well-publicized pranks — you will more likely get an assortment people with varying social social skills, competence and dedication to their work. The management challenge is in managing an engineering problem, and the succesful manager will be knowledgable in the problem domain, problem-solving methods for that domain, and exercise good judgment, which is not “geek” management. It’s just good management.

Chapter Three, “Groups of Geeks”, begins with “If you want to lead geeks, it’s not enough to understand them as individuals”. The author has it backward — we use generalizations as conveniences (in the context of physics, someone once said “all models are wrong, but some are more useful than others”) and fodder for humor, not as a productive way to deal with individuals.