How to get your developers to appreciate your customers?

When you're a developer, sometimes 4-5 organizational levels removed from your actual user, it's easy to fall in love with your code and technology, and forget that you actually develop for your customers.

I've been on that side for years: I used to demonize "whiny customers" with their "bizarre demands" and "crazy deadlines". And if this attitude is allowed to continue (or worse, encouraged) by management, and if those feeling continue to fester, pretty soon the company is divided into 2 camps: those that are in constant touch with customers (support, sales, etc.) vs. those that aren't (R&D, QA etc.).

Everyone thinks he's right and the other side "just doesn't understand" (see Benford's Law).
Field guys seem to think developers ("geeks") forget where the money comes from.
Developers are sure that if the field guys ("idiots who know nothing of technology") would just understand the pressure, technological constraints and crazy deadlines they face, they'd stop making all that noise.

And you know what? Both sides are right. And wrong.

I Started my career as a developer and lived deep inside my beautiful code. Anyone who interfered with my nice implementations and learning new technologies was the enemy.

Then, as a project manager, I started venturing out and meeting my customers (usually during initial deployments or crisis situations) and my eyes half-opened. I started seeing the customer's side, but still resented the fact they tried to screw up with my meticulous MS Project schedules.

My eyes opened all the way in my current position. Today, I'm managing mostly customer facing activities, and let me tell you, Karma is a bitch .
I started identifying with my customers' needs, to the point where I blame developers for "not understanding" the needs of the customers.

But enough about me. How do other companies prevent this internal strife and how do they promote customer understanding and respect amongst developers?

Why not ask Werner Vogels, Amazon's CTO? In a recent interview (quite long, but interesting) he said:

We have a lot of feedback coming out of customer service. Many Amazonians have to spend some time with customer service every two years, actually listening to customer service calls, answering customer service e-mails, really understanding the impact of the kinds of things they do as technologists. This is extremely useful, because they begin to understand that our user base is not necessarily the techno-literate engineer.

(I actually found this quote in this Coding Horror post - read it to get another take on the subject - and keep reading, it because it's good.).

So, getting your developers to do a short tour-of-duty with customer support, once in a while, might cure their misconception. It may even give them great ideas about new features, or code fixes, needed to ease the pains of customers.

On the other hand, I'd recommend a tour of the R&D facility by field personnel once in a while. This would put faces to names of people you only had phone/email communication with before. It would also help explaining constraints (time/technology/personnel) and improve communication.

But most importantly, it would would bring the company together.
Ultimately, without developers, sales people will have no product to sell. Without customers, no one would pay developers a handsome salary to implement another design pattern. All it requires to achieve this change is (as always), smart, open-minded managers.

But this is a subject for another post.