Paul Glen: Check your work, or else

Computerworld - I often wish I had a time machine so I could go back and prevent technical people from taking their first step toward client relationship hell -- where all interactions are tainted by the sense of mutual discomfort and mistrust that often emerges when geeks mix with business people.

It frequently starts with one small, wholly unnecessary misstep.

One of the most common complaints I hear from business people about us geeks is that we deliver things that don't work. You might be thinking that I mean "don't work" as in "don't meet some unarticulated requirement that users become conscious of after using what they asked for." Unfortunately, I'm talking about basic stuff like reports without data, buttons that don't do anything or unintelligible error messages.

For us geeks, these are trivial events, since they are usually easy to fix. It's just a small oversight: a misplaced comma or a typo in a variable name. We don't even feel embarrassed, since small adjustments are part of implementing technology.

But you probably have no idea how badly relationships can be damaged when these things happen, because end users have an entirely different experience of that same small glitch.

Imagine it from their point of view: You just told them that their long-awaited technology is ready for them to try. Excited and relieved, they begin to fantasize about all the productivity they're about to unleash. Then -- Bam! -- instant failure.

What seems like a minor setback to you is a major, emotionally charged disappointment for them. Think about the sequence of thoughts and feelings they experience:

1. Self-doubt. "Oh crap. I broke it. Maybe I'm too stupid to use this."

2. Anger. "They told me this was done! What kind of bozo would deliver this?"

3. Resentment. "They're just wasting my time because they're too lazy to test this and they expect me to do their job."

From then on, every encounter with us is tinged with the memory of that bad experience. And every human mistake we make is further evidence of our incompetence. It truly is the road to hell.

Having been on both sides of this situation, I can tell you that this usually happens because of our good intentions. Most IT people are earnestly eager to please their business partners. We respond to their constant sense of urgency with a zeal to deliver quickly, which often leads to inadequate testing and sloppy, silly mistakes.

We can easily avoid such situations by taking these steps:

1. Set expectations. If they want to see it before it's ready, tell them that they're likely to find bugs and tell them what to do when those bugs appear.

2. QA your work. Have someone else check for you. A quick look with fresh eyes goes a long way.

3. Be available. Don't just toss something over the wall. Wait by the user's desk or connect via video chat while he does his first inspection. If something goes wrong, he won't feel so alone.

In the end, we must transform our eagerness to please into eagerness to help. These might sound the same, but they're quite different. Trying to please often leads to unrealistic promises, half-thought-out solutions and poor quality. Helping often means delivering difficult truths, managing expectations, sharing challenges and limiting the scope of what we take on. In the short run, being helpful often means displeasing our business partners, but that's what they want and need from us.

Paul Glen, CEO of Leading Geeks, is devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. His newest book is 8 Steps to Restoring Client Trust: A Professional's Guide to Managing Client Conflict. You can contact him at info@leadinggeeks.com.

Read more about Management in Computerworld's Management Topic Center.