Sales Vs Engineering

Inspired by comments made in CultureDifferences and DeathMarch


The only contrast so far on this page seems to be "engineering good; sales bad". The assumption that this is always the case seems to be a CulturalSmell?. There are bad examples on both sides of sales and engineering, but in the end we need both. It may be more constructive to talk about the differences between engineering and sales when they exist in a functional organization (as opposed to the dysfunctional case). What things are fundamentally different, and how can you help bridge the gap from the engineering side?


Over the years working in the IT industry I've noticed, over and over again, something that causes immense amounts of problems and intra-company issues.

This is the separation between the guys who sell the product (whatever it is) and those who actually have to do the job. While countless jokes have been made over the years about Marketing and Sales staff, most of them do contain a grain of truth. I've more than once had to explain some fundamental aspect of computing to a sales guy, and I have also been subsequently asked to explain why the company is losing money, to which my own answer can only be "because sales sold them the wrong deal".

Aside from the usual gripes (Sales get commission even on bad deals, Management believe sales staff more easily than the actual qualified staff, etc.), can anyone out there explain to me how this is healthy for a computing (or any other) company, and how to change it to a better working industrial environment? - SkArcher?

the guys who sell the product (whatever it is)

But that's not marketing, that's sales.

how this is healthy

Not quite sure what you're complaining about, but if it's that sales people are different from the developers, I think it's because the skills are different. Do you buy your cars from the factory workers who made it or the designers or the production engineers?

Sales in this context refers to deal making and customization, not the unpleasant experience of buying a vehicle from an dealership. Auto salesmen do not call up engineering to say, "I promised Mr. Smith that his new SUV would have FIVE-WHEEL drive and only cost him $5,000. You guys can do that, right?"

You can take an analogy too far. Try, then getting a builder to construct an extension to your house. You don't deal with the people who have to do the job there, either. You deal with someone expert in "deal making and customisation" - a sales person.

Ah, but in the case of a house, there is (most cases) an explicit change fee, and the schedule is adjusted for every change. Typically, in software companies, these things are an exception rather than the rule. Salesmen there will promise more functionality in less time, for no more money.

Then you need better sales people. I won't say it doesn't happen where I work, but we do have project change control (and the mechanism for additional fees).

You would appear to work an a mythical place, from my experience. I know that I've never had a schedule moved out because the customer asked for more features.

"I have not experienced this" is not the same as "mythical"! Perhaps, but can anyone else support the assertion that most/many sales departments do consult back with engineering before committing to a sale and/or schedule?

That's not been asserted. Only that sometimes the sales people in my company do.


This sounds like more of a management problem than a sales problem. At my company:

If the sales staff can (re)direct engineering work without accountability; you've got more serious problems than an out-of-control sales force.


Well, "sales staff" that is "without accountability" is very common in the software industry, in the sense that they are only accountable for selling not delivering, and for very good reasons too.

In many tech companies making the quarterly sales target is far more important than making delivery targets. Often this does indeed lead to "more serious problems", like eventual bankruptcy and waves of accounting related (revenue recognition) lawsuits...

The root of the problem for software practictioners is that while making the quarterly sales target as a rule brings bonuses to executive management, delivering usually does not, thus "sales staff" is in control, not the poor SoftwareLabourers that are tasked with delivery.

If software companies were required to put in their quarterly reports the value of projects delivered that quarter rather than the value of orders booked, things would change pretty radically. But I guess that there is very little chance of that.


See Also: DeveloperVsIt


EditText of this page (last edited April 11, 2005) or FindPage with title or text search