Why Users Are Never Satisfied

Users are never satisfied. Given the present circumstances, they never will be. Naturally, there’s an unending supply of theories about why and just as many surefire fixes floating around the pages of this and other magazines. But the real reason, the real solution, is known to but a few. And there are fewer still willing to lick the frozen pump handle, so to speak, to get things fixed.

I know the real reason. I learned it from a moon-faced young man who sat next to me on one of those steaming summer flights between Dallas and St. Louis. He taught me all I needed to know about users, and we never exchanged a single word.

The flight was a good 30 minutes past departure time. Tepid air barely whispered through the nozzles overhead. As usual, the plane was nearly full except for a scattering of empty center seats here and there, including the one next to me. I was just about to congratulate myself on my well-deserved good luck when I noticed him sidestepping slowly up the aisle. Immediately, almost unconsciously, I fell into a rhythmic, silent chant of “Please, please don’t sit next to me! Please don’t sit next to me!”

It never works.

Now, over the years, I’ve developed the ability to watch people without looking at them. Believe me, if you fly a lot, this is an important skill because if you make eye contact with the person next to you, you are obligated to talk to him. And your chances of sitting next to anyone genuinely interesting are about one in a million.

We finally pushed back and began to taxi when I noticed, out of the corner of my well-trained eye, that my new seatmate had begun to pray. I call it praying, but it was, in fact, something far more emphatic, more desperate. This was power praying. His eyes were squeezed shut, his hands clasped together so tightly that his fingernails turned blue. He was petrified. We were still only taxiing. He was scaring the elderly lady sitting on the other side of him.

Now, I’ve been driving cars since before I could get a license. I’m not a great driver. I drive too fast, and I daydream a lot. But in all of the thousands of hours I’ve been behind the wheel, I’ve never had a passenger behave the way this guy did. That’s pretty strange when you think about it because you have a one in 80 chance during the course of your lifetime of being killed in a car wreck. Your chance of being killed in an airplane is only one in 3,286. That’s how much safer it is to fly. As a matter of fact, the sandwiches the airlines hand out represent a greater threat in that our chances of choking to death are one in 3,096. I’m not sure what the odds are on food poisoning. The reason for his behavior, of course, was his sense that whatever was going to happen now was out of his control. The operation of a car isn’t a mystery to anyone over the age of 8, and in a pinch, a passenger could always reach over and grab the steering wheel. Control of the airplane, on the other hand, is in the hands of a complete stranger locked away in a little room in the front who follows arcane and secretive procedures while mumbling indecipherable incantations into the radio.

As far as most of the people at your company are concerned, your IT staff operates in a similar fashion, somewhere apart from the “real” company, in an inner circle of highly specialized and unattainable expertise. Your IT people, for mostly defensive reasons, sport attitude and spout lingo carefully crafted to signal to any gathering of coworkers the clean divide between the hip and the hopelessly square, between those in possession of the right stuff and those who aren’t even sure what the “stuff” is.

It’s worth noting how successful we as a profession have been during the past 20 to 30 years in establishing our place in the business universe and, in the process, raising expectations and tensions. Somewhere along the line, the data-processing department magically became information technology. That’s pretty big headed when you consider that bits and bytes are no more information (coherent explanations) than individual bricks are the Washington Monument.

What the vast majority of users don’t realize, and what many of us are loath to point out, is that there is really no “stuff” to get. The whole notion of “stuff” is a kind of well-meaning hustle based on the belief that understanding technology is just as important as exploiting it effectively—that technology is, somehow, the strategy. The recent rash of dotcom failures would seem to soundly disprove that point of view.

In light of this, is complete user satisfaction attainable? I’ll go out on the skinny branches here and say, maybe. It’s certainly worth a try.

Years of hits and misses and no small amount of help from wiser heads have helped me distill a short list of rules for interacting with and managing users. These are things most of us intuitively know but few IT organizations (or CIOs) consistently act on or do well.

First, and certainly the most difficult for the central control freaks out there: Give away as much control over IT as you can. Most of the time, you should not care what your development people are building and in what order as long as your users are behind it. But you should always care how they’re building it and to what standards. Carve up your development teams, and hand them over to the departments or regions they support. Have the manager of each new development group report solid line to the general manager of the user department and solid line to you.

Allow the GM to dictate the what, when and budget of each project; with you serving more as a consultant, you’ll dictate the how so that you can make some sense of it all. The architectures and the technologies do exist to make this work very effectively. This act of sharing control, inviting others to sit in the cockpit, has the effect of reducing stress by demystifying the process, educating other stakeholders on the challenges of development and eliminating the need for secret IT organizations that pop up around large companies when users get desperate. (Continued on Page 183)

(Continued from Page 178) Second: Cultivate personal relationships. They help get you over the rough spots. Expending precious personal time to develop relationships, familiarity and intellectual common ground generally pays off big in the end. This isn’t about trading on friendships. If you’re like me, you can count your real friends on one hand and they’re probably not coworkers. This is about empathy for one another’s challenges, the confidence to speak frankly and the willingness to work together to fix the crisis du jour.

Third: Don’t lie, but don’t scare the tourists. When things come up, give the information that users ask for quickly and accurately, and give them the information they’ll need to operate until you can get things under control. Sharing anything else is confusing, scary and time-consuming. I want to know that my doctor is going to operate on my liver and why. I don’t want to know all of the things he’s going to have to move out of the way to get to it.

And finally: Never let them see you get angry with your people and never let them see you sweat. If you panic, so will they, and even if you do succeed in righting the airplane, you’ll never have the confidence of your users or supervisors again. Nervous users are unhappy users.

It occurs to me that some of what I’ve just laid out will not come naturally to most CIOs. Many are too set in their ways, or they simply lack the imagination, confidence and poise to do these things effectively. But what’s the alternative to bringing users into the inner circle, to leveraging their expertise and allowing them to shoulder some of the burden for quality results? More user surveys?