The challenge from the business side is to evaluate reliably how to measure "10x" in this context. While there is widespread agreement that some programmers are significantly more productive than others (maybe even 10x as productive), there is much less agreement on how, exactly, such productivity is measured.
With sales, it's very easy: you count Dollars In The Door. Maybe you also count something like New Customer Logos Acquired or something like that, but generally speaking it's just cash. The salesperson brought in new marginal cash, and you're paying some portion of that back to him/her.
With code, it's hard to know what to measure: lines of code? Features produced? Ratio of LoC/bugs discovered? Mean time between when a piece of code is written and when we recognize that it needs to be refactored? It's just a much messier process.
None of this is to argue against incentive comp for engineers. It's just to point out that in sales, you're measuring and paying for output. Output is much harder to measure in engineering than it is in sales, and compensation is fuzzier as a result.
Sales deals can be quite complex to measure as well.. IMHO is just that sales guys tend to be better negotiators, so they ask to get rewarded properly o go somewhere else with their skills.
Almost any process that measures human output will be gamed (optimizing for measured output rather than overall success). It's basically impossible to game sales without resorting to outright fraud, whereas there are all kinds of ways to game individual engineering output measurements, in ways that do not align with the business objective.
Sure. That's all true. But it doesn't change the situation.
There are difficulties, but there are difficulties in any job. It's still the job of management to evaluate the performance and contribution of their employees.
The more rote the process, the worse it will be, since, as you say, it will be able to be gamed. As a general rule, I've found larger organizations are worse at it because they have more rote processes, with complicated matrices, charts, etc.
I've been a cog at small, medium, and large orgs. I've been team or project-level management at small and large orgs. I was happiest being management at the small level. Much less politic-y stuff and more freedom to manage the way I saw best. I enjoyed being managed most at the mid-level company. Less room for managerial whims that small companies can suffer from. (Yes, I know I'm playing both sides on that. Heh.) And less of the 7,000 item Employee Evaluation Form Of Doom that big companies have.
It's hard, no doubt. But a manager saying they can't accurately evaluate their employees is literally saying, "I can't do my job." Any manager should always have a very, very good idea what's going on with their employees and their contributions.
Sure you can game sales to some extent. You can game the specific commission system. That's why it's very important for the specific incentives of the commission system to match the specific goals of the company.
It is not hard to understand, but it is hard to measure.
Do you reward writing more code, better code, code with less bugs? There is no one axis to measure along where as in sales you just measure the sale price.
People hand the company money when sales do their job. No one hands the company money because you wrote an extra 1,000 lines of code this week down in your cube on B2. Just like the janitor who doesn't get paid 10x as much if he spends some extra time scrubbing the bathrooms.
Sales need something to sell. Jobs are paid based on the perception of how difficult it is to find someone to do it. CEO's are paid ridiculous amounts because the perception is almost no one can do the job. Janitors are paid little because the perception is almost anyone can do the job. The result of this is that many buildings are cleaned poorly, so nxt time you see a dirty bathroom, don't blame the janitor, blame the person hiring the janitor. The supply of good janitors is much more restricted than it appears, but that's because the person hiring typically can't see the value in paying more.
For programmers it's the same. Good programmers can make or break a business by building software which sells itself, or by building software with 10 times less effort, turning loss into profit, but many people hiring the programmers don't see it that way, so many programming jobs underpay, and many people paid to program have no business being anywhere near a keyboard.
The coder may be a cost saver in some cases, but not necessarily all; if that sales guy is selling software that the coder wrote, then the coder is just as much of a profit generator (actually more) as the sales guy who just sold the product that someone else made. The manufacturer and salesperson are both important. Generally speaking, the value of these positions is about even; specific situations may slightly favor one position over the other.
I worked a while as an "engineer who accompanies the sales guy to potential clients". Not really a sales engineer, as I didn't do actual salesman-y stuff and didn't manage accounts or anything. More as the guy who answered tech questions, gathered requirements, communicated back to the engineering team to get feature request time estimates, that kind of thing. More a 'liaison to the salesguy' than anything, though I would sit in on sales meetings.
It was fun, really. Lots of travel, lots of meeting people, lots of finding out what they really wanted us to be offering.
Anyway, I learned a lot about the art of sales, and while I was admittedly jealous of the money our salesguys made (some in 7-figure-land), I also learned it takes a specific kind of person to do it well.
And I could easily see why so many of them were such heavy drinkers. Combination of having to be very social and having the pressure of the revenue riding personally on your shoulders. I think as engineers you don't feel that pressure so directly. Certain execs in a startup, sure, but they're also part sales, in a way.
With sales, it's very easy: you count Dollars In The Door. Maybe you also count something like New Customer Logos Acquired or something like that, but generally speaking it's just cash. The salesperson brought in new marginal cash, and you're paying some portion of that back to him/her.
With code, it's hard to know what to measure: lines of code? Features produced? Ratio of LoC/bugs discovered? Mean time between when a piece of code is written and when we recognize that it needs to be refactored? It's just a much messier process.
None of this is to argue against incentive comp for engineers. It's just to point out that in sales, you're measuring and paying for output. Output is much harder to measure in engineering than it is in sales, and compensation is fuzzier as a result.