The Truth About “Useless” People

Posted by on Sep 9, 2010 in Emotion & cognition | 0 comments

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.”

For more information about how you can leverage geeks to get the technology you want, contact or call 310-694-0450.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.