Customer Reviews

Leading Geeks: How to Manage and Lead the People Who Deliver Technology

5 star:		(14)
4 star:		(4)
3 star:		(3)
2 star:		(1)
1 star:		(3)

 

 

There's excellent advice and concrete suggestions for a lot of the important things about leadership, particularly for those at the top of the hierarchy. Everything from the concrete pieces such of the work environment like the office space to the fuzzy pieces like the vision, mission, and keeping the team working well together are dead-on.

The management sections (chapters 10 and 11) delve deeper into management and organizational practices but aren't effective. IT describes methodologies at a high level ("waterfall" is usually bad, "RAD" is usually good), but goes into enough detail that you start to get lost in the descriptions of them and miss out on what is trying to be conveyed about what makes a good or bad methodology for a team. A similar thing happens when "project roles" are mentioned. There's also a pretty nasty technical error -- it describes the Microsoft Solutions Framework, then states that it's used internally at Microsoft. If so, I've never seen it, and it's not identical to our best practices.

Still, don't let that get you down. The first nine chapters make this well worth reading.

This was a clear, concise book illustrating a number of simple concepts in managing scientists and engineers- also known as Geeks. The book clearly illustrates- through narrative and example- that beliefs, values , work and motivation of Geeks is unique, and what techniques work and don't work in motivating these creators of technology and innovation.

This book should be read by both new and seasoned managers and supervisors that have or will be managing technologists, scientist and engineers. Leading Geeks has clearly illustrated why I have succeeded/ failed in managing geeks in the past and given me new insight into what makes them tick.

(Each chapter is concluded with a summary and Key Ideas. Read these first for a Chapter Road map.)

The geeks Paul Glen talks about in Leading Geeks are those employees involved in the creation, maintenance, or support of high technology from help desk technician to system designer to CIO.

I can sympathize with technical people who resent the term "geek". I don't like it applied to myself -- but I understand the harsh reality that books need eye-catching titles. If you can get past the title, the contents are sane and sensible.

Glens point is that the general management techniques enforced by most corporations are nearly always wildly inappropriate and self-defeating when used on technical staff. As obvious as that might sound to most technical workers, companies continue to teach a command and control approach using bribes to coerce staff into certain behaviors. As Glenn says, what is usually a magnificently effective technique for dealing with salespeople, is nearly always a disaster when applied to the introspective personalities common in IT.

If youve ever delivered a morale-raising talk to developers and received only sniggers and eye-rolling in return, Paul Glens book will explain why.

Also recommended:
Peopleware by: Tom DeMarco & Timothy Lister published by Dorset House Publishing ISBN: 0-932633-05-6

I feel that I have been a "geek" for the last 8 years. I am in the process of moving into a position of leadership and am striving to gain information on the most effective method being a leader. I had hoped that this book would give me insight on what it takes to lead "geeks", but I found that the knowledge in the book was very superficial and did not give me any greater knowledge on what to do to assume my new position. I felt that McConnell's "Rapid Development" was much closer to hitting the mark when it comes to giving insight on "geekdom". My recommendation is to look for another book if you are looking to understand the mind of the technologist.

This book hits the nail right on the head. I have seen too many otherwise-excellent managers fail miserably to motivate technical teams. It is all the more depressing since 'Geeks', as Paul Glen calls them, are very low maintenance people once you figure out how to deal with them. What more, they are more and more central to our organizations' competitiveness. Glen's easy-flowing style makes it possible to get to the essential points quickly. I would recommend this book to anyone whose organization has to deal with technology - now-a-days, that's everyone.

While not about learning or teaching per se, this book provides extensive and detailed insight into the motivations, thought processes, beliefs, and behaviors of technology workers, an important part of the economy and the adult learning population. Specifically, it investigates and supports the theory that technology workers, or "geeks," are motivated differently, think differently, and learn differently than other adults. It then develops a model of how technology-focused knowledge work adds value to organizations and economies. Finally, it presents some prescriptive approaches for understanding, motivating, managing, and leading technology workers. Sources include the author's primary research and extensive references including many well-known scholars and practitioners. Findings include the conclusions that technology workers are different from other workers; technology work is different from other work; and power is mostly useless in affecting technology workers' productivity. Well-documented and substantiated; a seminal practitioner-focused work.

Management consultant Paul Glen's thorough discussion of geeks brings you brain-to-brain and eye-to-eye with high-tech, specialized knowledge workers. Don't blink: you need these people, so you need to know how to fit your management style to them. Glen describes their primary personality traits and attitudes: commitment to logic, interest in problem solving, independence and, to put it politely, occasionally under-developed social skills. The author, who doesn't seem to mind describing an entire subset of the labor force as if each worker in it had the same personality, explains what geeks need from a manager. You need to nurture motivation, provide internal facilitation, furnish external representation, and manage task, structural, and environmental ambiguity. We suggest this organized, authoritative guide to those who manage knowledge workers. If it's all geek to you, here's the codebook.

In 1785, the great composer Joseph Haydn heard for the first time the 6 string quartets that the 29 year-old Wolfgang Mozart had composed in his honor. Afterwards, he said to Mozart's father, "Before God, and as an honest man, I tell you that your son is the greatest composer known to me either in person or by name. He has taste, and, what is more, the most profound knowledge of composition." What do Mozart and the geeks of Paul Glen's book have in common? For both composers and geeks, intrinsic motivation, not external pressure or rewards to innovate, is essential to the creative process. Most of Mozart's works were composed as commissions--he was paid to produce them on a rigid timetable. Music critics point out, however, that the so-called "Haydn" quartets are possibly the greatest music that Mozart composed--and they were written for his personal pleasure, not for money, as a gift to the great Haydn. Leading Geeks is great book for anyone who has to manage technical professionals or work on teams with them. Paul Glen--himself a self-confessed "geek"--has a deep understanding of the mindset and psyche of IT and engineering professionals, and he demonstrates this throughout the book. I particularly liked the early chapters, which set the stage for understanding and motivating the "geeks" of the title. Glen has a wry sense of humor that you will enjoy, and he knows his subject well.

In "Leading Geeks", Paul Glen puts to paper a strategy for leading IT people that I personally have been following but have never been able to articulate.

Framing reality and managing ambiguity is indeed the major part of the job. It is our responsibility to help our teams "make sense of the cacophony of hype, facts, opinions, rumors, ideas, and concepts that swirl around the workplace". We have to provide some "fixed point in the distance to help guide day-to-day decisions and provide a coherent context to the nearly endless stream of confusion".

Finally someone acknowledges that the "seemingly endless supply of motivational material testifies to its futility". It is not so much that we need to motivate our creative and technical employees, but rather we should strive to not *de-motivate*, and nurture the elements that allow it to occur.

Glen says that we are trying to encourage effective *thought* as opposed to *behavior*, given the creative nature of geek work. Although he recommends projects as the optimal format, he says innovation is difficult to manage and schedule. On the subject of project and engineering methodologies, the "one thing that most of them have in common is that they are ignored." Yet compliance must be a balancing act, because while we rarely follow methodologies to completion, without them we descend into chaos. This is good advice that we hardcore project and process managers need to always keep in mind.

He also provides excellent insight into the thought patterns behind smart, creative people.

I have a few nits that prevent a rating of five stars.

- I did not like the continued use of the word "geek". Although once used, I understand it is very difficult not to keep using it to refer to the particular subjects at the heart of his book. And the author uses the term with affection and even reverence and he admits he himself is a geek. Still, on the whole, the moniker doesn't work.

- The book plays slightly towards the stereotype. While that characterization does cover a large portion of the "geek" population, there is a sizeable body of geeks who are not introverted and that understand and are interested in business and other traditionally non-geeks things.

- Finally, while the first 200 pages provided good practical advice, chapters 11, 12, and 13 just fall off the map into academia and theory. It is almost as if a different author penned those chapters.

Those nits aside, I strongly recommend "Leading Geeks" to managers of computer, engineering, and creative employees.

In his book, Leading Geeks, Paul Glen gets a lot right, but also hits a few off notes that perhaps are more reflective of the challenge in speaking about knowledge workers in general than in any intentional oversight.

Let's get my biggest gripe out of the way early - the term geeks, though used lovingly by Glen, does his goals a disservice by conjuring a stereotype at the same time as it excludes a whole variety of knowledge workers who otherwise would be prime candidates for his management principles. John Ivancevich and Thomas Duening chose to avoid the word "geek" by replacing it with "Einstein" in their book Managing Einsteins - a choice that I'm not sure is much more palatable. Both seem to reduce the knowledge workers they're describing to something more foreign or capricious than is now the norm - the image of pocket protectors and the priests of the room-sized mainframes seem dated.

By declaring geeks to be "knowledge workers who specialize in the creation, maintenance or support of high technology," it seems to me that Glen has shifted his determinant from the work to the tool. Though our high tech tools of the day certainly impact the work and the personalities of the workers who use them, I think it's still the case that the "geek" personality that Glen speaks of is often found nowhere near the creation of high technology, but still operates with many of the same management concerns.

A case in point. I work at a college leading the IT department. We'd legitimately be geeks under Glen's definition, but also in the group is our Institutional Researcher. As an employee, he's a user of technology, but in a similar way to a carpenter who uses a hammer - the work is a creative process that utilizes tools for another purpose. Yet the Institutional Researcher could equally fall into Glen's group of "highly intelligent, usually introverted, extremely valuable, independent-minded, hard-to-find, difficult-to-keep technology workers who are essential to the future of your company." Glen may feel that he's talking about my network administrator, but as a leader of today's workplace, it seems like I need to have some of the same assumptions about a wider variety of employees who never touch a router or hard drive.

That said, Glen's model for geek leadership - a circular flow that "Provides Internal Facilitiation", "Manages Ambiguity", "Nurtures Motivation" and "Furnishes External Representation" - is sound. Knowledge work - "geekwork" as Glen terms it - is much less driven by a centralized command-and-control structure. As much or more than the specific deliverables, the environment where knowledge work happens is crucial - if creativity is valued, and a clarity of vision is communicated, most other things fall into line.

The other strong point of the book are the 12 competencies that Glen identifies as the way to "measure and guide the productivity of geeks": technical competence, personal productivity, juggling multiple tasks, ability to describe the business context of technical work, forging compromise between tech and business constraints, managing client relationships, managing technical teams, playing positive politics, expanding client relationships, working through others to make them productive, managing ambiguity and managing time horizons. They're commonsensical, but they're solid. Knowledge workers don't always have the interest or commitment to intra-organizational politics, but a good "geek leader" will work to be a conduit between the larger organization and the knowledge worker. The metaphor can be taken too far - it's a rare employee that is completely oblivious to the work environment they're functioning in, so leading geeks isn't like being a UN translator - more, it's a role of stepping back and remembering the institutional context, as well as the personalities involved. The geek personality Glen describes may indeed be impatient with institutional politics, but they're aware it exists. The leader's role is to place those politics in their proper place, so the work gets done with an awareness of the larger need, while still allowing for the creativity that really adds value to the institution.

In the end, Glen's done a nice job. If you're feeling mystified about how to work with a DBA or a web developer, this may be a good book for you to read. If you're trying to explain knowledge workers to a boss more familiar with command and control, it's not a bad tool to reach for. If you're looking for a magic solution, this isn't it - but Glen would be the first to tell you that there isn't a magic solution. I'd reiterate, however, that if you're managing nurses, or a department in a call center, or team of welders, this may also be a good book for you - don't think technology when you think "geek", think "knowledge", and you'll be able to better put this text into your context.