Book Reviews

Go To Hopkins & Company Homepage

Go to Executive Times Archives


Go to 2003 Book Review List


Leading Geeks: How to Manage and Lead People Who Deliver Through Technology by Paul Glen


Rating: DNR (Do Not Read)


Click on title or picture to buy from



All Geek to Him

If to a hammer, everything looks like a nail, to Paul Glen, everything about geeks requires special handling, and he tries to tell the rest of us what to do in his new book, Leading Geeks: How to Manage and Lead People Who Deliver Through Technology. Take my advice: don’t read this strange book, and if you do, don’t follow Glen’s advice.

Here’s an excerpt (pp. 66-71) from Chapter 4, “The Nature of Geekwork”:

The Problem with Problems


Geeks love problems. Whether puzzles, philosophical conundrums, math problems, or broken machines, geeks find comfort, validation, excitement, and joy in solving problems.

Problems provide more than just motivation and amusement; they have become the primary organizing metaphor driving geekwork. Every plan, every activity is conceptualized as a solution to a problem. In this model, problems become the initiators of action; without problems, nothing happens. This problem-solution worldview dictates that technology be designed to resolve technical or business problems or to exploit opportunities (which are also conceptualized as problems).

Marketing literature provides the most unmistakable evidence of this phenomenon where the word solution has now joined the pantheon of the overused hyperbolic phrase. It's no longer acceptable to call a product a product. Every product is now pitched as some sort of solution. Slogans like "Bimbah, your e-mail solution" or "Symacule, your database solution" are thrown about, begging the consumer to ask, "A solution to what?" The answer is, "To some problem that you may not even know you have."

Although I poke fun at the marketing abuse of the problem-solution model, it has proved to be a robust and useful approach to technical management. For geekwork that is inherently ambiguous and difficult to define, problems offer relatively clear direction and boundaries. Out of all the possible things that one might do in a day, solving a particular problem provides focus and urgency to work and helps to prioritize tasks.

But like all other metaphors, problem-solution has limits and problems of its own. The model is very sensitive to the quality of problem formulation. A solution can only be as good as its problem. If problems are not carefully selected, well defined, and articulately communicated, the solution developed will be of limited value. If you ask a bad question, you'll get a bad answer.

In addition, problems carry emotional baggage, toting along negative connotations wherever they go. If you've got a problem, something's wrong. There's an implied inadequacy or failure that's occurred somewhere. The pervasive negativism can contribute to the cynicism that's so common in technical groups.

Perhaps the most troubling problem with problems is that some essential geekwork cannot be represented in the model. Not all work can be conceptualized in such a linear way. In the problem-solution worldview, work occurs in a clear sequence: identify a problem, solve the problem, and then move on to the next problem.


Problems can exist in only one of two states: solved or not solved. Once a problem is solved and its solution implemented, you're done. Resolved problems don't require attention,

Many things in life don't really work that way. But to geeks, work that doesn't cleanly conform to the model is rejected, devalued, or forced to conform inappropriately. For example, most human relationship issues aren't easily represented in this format. Relationships require ongoing communication, negotiation, and dispute resolution. You can't just ignore a business relationship until some problem develops. It must be maintained. Some things need to be managed on an ongoing basis and can't be reduced in this way.

One of the most common expressions of the limits of the problem-solution conceptualization of geekwork is the initiative that's launched whenever an operational issue or limitation is discovered. Frequently, these are attempts to apply the problem-solution approach to a human problem that doesn't lend itself to these types of one-time resolution. For example, most geek groups have occasional spasms of activity to try to improve communication or quality. They put together a team to oversee the initiative, hold meetings, plan seminars, build technical infrastructure, and encourage information sharing. But invariably these efforts lose energy and die from neglect. The ongoing work of maintaining these efforts doesn't conform to the problem-solution model and is invariably abandoned when a new problem arises that conforms better and seems more urgent.


Done Is Hard to Do


In geekwork, done is very hard to do. On the surface, it seems that finishing a project should be simple. In the problem-solution world, you are done when the problem is solved. But in practice, the only project teams that have no problem distinguishing "almost done' from "done" are the ones that never even come close to finishing. For those that do try to reach closure, figuring out what done really means is quite difficult and requires hard choices made with incomplete information. With no physical reality to indicate completion, it becomes a political decision.

The ambiguity arises out of four distinct and opposing constraints on technical work. The first demand is that a technology solves the problem it set out to address: that it provide a sufficient scope of features to satisfy its requirements. But it's never completely clear what represents the minimum acceptable set of features.

The second constraint is quality: that the technology be delivered at a sufficient level of reliability that its features can be used to solve the problem that it seeks to resolve. In every project, scope and quality must be balanced and compromised in order to complete the work. But measuring quality is difficult and often subjective.

The third constraint is budgetary. Projects frequently overrun budgets, and toward the end, it's never really clear how much more money will be needed to finish. Due to the ambiguity in other factors, budget estimates are rarely right.

The final, and often the most important, constraint is time. Competitive business pressures or regulatory requirements often weigh heavily on the schedule of a project. But toward the end of projects, the irreconcilable demands frequently lead to rather animated discussions about when done is done.

Declaring a project complete ultimately becomes less a technical decision and more a political one about striking the appropriate balance between the competing demands for quality, budget, schedule, and scope. A project is done when the managers concerned forge a consensus that the project is complete and that the constraints have been balanced in accord with overall organizational goals.

One of the most challenging parts of building the consensus of completion is establishing whether the problem has been solved. This difficulty usually goes beyond just establishing whether the technical scope is sufficient. Toward the end of a project, it often becomes clear that the problem that was intended to be addressed was, at the outset, inadequately understood or, worse, unstated. Establishing whether you have solved an ill-defined problem is nearly impossible.

Finishing a project requires intense commitment and significant effort, so select final deadlines carefully. If you ask a group to push hard to meet a date and work long hours, ignoring their families and forgoing personal interests, don't change that date for anything short of a disaster. If a group makes the extraordinary effort to meet a deadline and you change it without a very good reason, that group will never again commit to meeting a date. They may give lip service to deadlines but won’t truly sign on for what it takes to meet one.


You Can't Control Creativity


Many of the constraints that geekwork imposes on leaders and geeks stem from the fact that it is fundamentally creative, innovative work that cannot be controlled in the traditional sense. Inspiration rarely works on a schedule, rarely arrives at the exact moment that the project plan prescribes, and can't be hurried, pressured, or “incentivized.” Innovations can't be scheduled, and insight can't be managed. Although they call it computer science, most geekwork looks more like art than science.

For most leaders, the inability to control the work of subordinates proves frustrating. This is usually the same for managers from both technical and nontechnical backgrounds. They feel out of control, insecure, or incompetent, none of which is conducive to becoming an effective leader. Some respond by pressuring geeks to try to answer questions that they simply can't answer honestly, like, "When are you going to know how to solve this problem?" A geek who hasn't even identified what the flaw is with a system has nc idea when it will be fixed, but many managers don't feel comfortable not knowing. Others respond by deciding that since they're "in charge," they will dictate the answer to the unanswerable questions: “I’ll just tell the users that the database will be back up at noon.'

Both of these approaches may make managers delude themselves into believing that they have control of the geekwork, but all they've really accomplished is forcing a rift between themselves and geeks.

The real source of the problem isn't that the manager isn't in control, but that he assumes it is his job to do so. As long as a leader believes that he can control geekwork, the inherently uncontrollable, he's going to be swimming upstream, fighting reality.

There may be worse books than Leading Geeks on the business shelves this season, but thankfully, I haven’t read them (yet). Unless you’re really enthused about the excerpt above, I recommend that you take a pass on Leading Geeks, and keep doing what you’ve been doing.

Steve Hopkins, March 25, 2003


ă 2003 Hopkins and Company, LLC


The recommendation rating for this book appeared in the April 2003 issue of Executive Times

URL for this review: Geeks.htm


For Reprint Permission, Contact:

Hopkins & Company, LLC • 723 North Kenilworth Avenue • Oak Park, IL 60302
Phone: 708-466-4650 • Fax: 708-386-8687