Hard Sales

Source: BusinessBalls.com

Source: BusinessBalls.com

When you are a pro-programmer, you will know “Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.” (Joel Spolsky) [The Iceberg Secret, Revealed] Hence, you live by the WNA-paradigm (give them what they Want, Not what they Ask for). However, the good people over at sales live by the opposite CAR-paradigm (the Customer is Always Right). This seems contradictory, and it is. It is also a recipe for success. A successful company will utilize abstraction layers . . . you know where paradigm shifts take place. Like: connection oriented TCP, based on connectionless IP. Client orientated CAR-sales, based on system orientated WNA-development is a prerequisite for a successful company. (Did I just say “car sales?”) As an abstraction layer, sales has to provide a CAR interface to the customer, based on the WNA interface you provide.

Let’s see what that means in practice. Guss the customer, has two questions. “Can you implement this feature list? How long will it take?” It is sales’ job to make Guss hear: “Yes we can. As long as you have.” Now the magic paradigm shift happens and sales asks development: “What can I provide, so you can find out what Guss actually wants? Could you build a mock-up GUI suggesting 3 weeks worth of features?” Providing the sales layer is hard, sales is hard. But you have it hard too, you have to give Guss what he wants based on previous work and C#.net, good luck with that. As long as everybody does their abstracting, hard sales and hard programming will work out fine together.
You might be surprised to hear that there are some companies out there, that practice soft sales. The sales department does not do any abstracting, they simply try to force the CAR-paradigm on development. Forcing square pegs in round holes. Key indicator are: Sales gives you a list of features and asks you how long it will take to implement them. Than they keep asking how long it will take, until you supply the right answer. If you don’t give the right answer, they start bombarding you with quasi technical terms interlaced with “Why don’t you do this?” Preferably in e-mails that are (B)CC-ed to The Boss. This way they can play the blame game, either way. You will fail to make Guss happy, either because you did not object strong enough to the proposed technical solution, or you are incapable of implement it in the allotted time you agreed upon. If by a miracle–and 15 hour workdays producing error prone and non-reusable code–you succeed, it was all thanks to that wonderful technical advice you got.
So the lessen to remember: Watch out for empty abstraction layers, especially in real life, especially if they are called, (account) manager.