Free Article By Paul Glen of C2
Consulting
Every month we add to this collection of articles from the free monthly
newsletter IT Professionalism.
You are also free to print these articles in your newsletter or magazine if
you follow our Reprint Policy.
To subscribe to it, click here.
The Truth About "Useless" People
(This article originally appeared in
Computerworld USA.)
Every so often, someone will ask me what to do
with "nondelivery" people. The question goes something like this: "How do you
deal with people who can't execute? They are good at technical analysis,
documentation and strategy, but not delivery. I can't afford them." What the
questioner is politely trying to ask is this: "What should I do with useless
people?"
It's a question that sometimes rubs me the
wrong way, and I'll try to explain why. Once you dig into the query in more
detail, you find that it actually can have one of two very distinct meanings.
In the reasonable version, the questioner is
asking about a few intelligent and talented employees who are simply unable to
finish anything. These are the people who are seemingly paralyzed by ambiguity
and are incapable of moving forward until every possible question has been
answered.
Helping ambiguity-challenged people is quite
hard. When I have encountered them, my impression has been that they have a
deep-rooted emotional need for complete information, one that's not easily
overcome by repeated pleas for progress, a bad review or even being fired.
The best you can do for them is to gently let
them know that perfection isn't required in the first draft of a piece of work
and that its purpose is to help figure out both the best questions to ask and
the answers to those questions. Relieved of the burden of perfection, they can
more easily produce drafts.
In my younger days, I had a tad of this
tendency myself. I once worked for a project manager whom I questioned almost
constantly for the first six months we were together. When I quit the job after
a year on the project to go back to graduate school, he took me aside at the
farewell party.
"I don't understand you at all," the project
manager said. "For the first six months you were here, you were such a pain in
the @#$. After that, we rarely spoke, and you became by far the most productive
person on the project. What happened?"
"I finally figured out what you wanted," I
explained. "We don't see the world the same way, and nothing you asked for made
sense to me, so I had to ask a million questions. Once I figured out what you
were trying to do, I just got on with it. I didn't necessarily agree with your
approach, but that was fine with me, as long as it was a coherent one."
The question's other possible meaning is a bit
more irksome to me. In this version, the questioner has a few employees who are
quite talented and can finish their work, but they specialize in things that the
manager doesn't consider "real work."
These employees are the people who neither code
nor test. They do the things that we learned little about in engineering school.
They write requirements documents, design architectures, and produce user and
production support documentation. They negotiate with the customers rather than
writing code themselves, they build consensus about what should be done.
Here, the questioner needs to rethink his
conception of what useful work is. These people do a great deal of the heavy
lifting that's truly necessary on a project. If their manager thinks that
projects can be completed successfully without building consensus or writing
user documentation, he probably needs to expand his definition of project
success.
Delivering technology isn't our job. Making our
organizations run smoothly and efficiently is. Technology is the means to that
end. And if users need documentation to apply our technology, then writing that
documentation is "real work" in my book.
Ten years ago, I used to have these
conversations all the time about project managers. Clients didn't want to pay
for them. Project managers didn't code, so no one knew what they did. Clearly,
they weren't real workers.
Luckily, this discussion about project managers
is much rarer now. Today, few would think of starting a significant project
without one, and the success rate of projects is inching upward in our industry.
Just remember, if we were to go to a conference
of chief financial officers (or even of programmers), we might overhear someone
asking a similar question: "What should I do about my CIO? I have no idea what
he does. He doesn't produce code, and we can't afford him."
