Book
Reviews
|
|||
|
Go to Executive Times
Archives |
|||
|
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 amazon.com |
|
||
|
|
|||
|
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: http://www.hopkinsandcompany.com/Books/Leading
Geeks.htm For
Reprint Permission, Contact: Hopkins
& Company, LLC • 723 North Kenilworth Avenue • Oak Park, IL 60302 E-mail: books@hopkinsandcompany.com |
|||
