Ask HN: Has any company ever paid developers like they pay sales people?
9 comments
This reminds me of this: http://www.youtube.com/watch?v=u6XAPnuFjJc
Basically, theres research showing that for knowledge based work, you just want to get out of the way and pay enough that they dont think about money. Increasing pay doesn't increase productivity
Basically, theres research showing that for knowledge based work, you just want to get out of the way and pay enough that they dont think about money. Increasing pay doesn't increase productivity
Sales is a hit-driven business. If you close >50% of your potential deals you're on fire and are probably not getting enough quality leads.
Almost every other part of the business (marketing, engineering, professional services, G&A) is expected to perform or deliver at near perfection (say, >90% for a sloppy organization).
The only exception to the non-sales role that allows for a "low" success rate would be R&D.
As others mentioned in the comments, bonuses are typically the way to reward non-sales staff upon completion of their portion of the work. As well, there are usually equity pools that staff participate in.
A commissions incentive structure is incredibly stressful for employees who expect steady, dependable and predictable paychecks with bonuses on top. Commissions incentive structures often attract and encourage aggressive personalities and characteristics.
It may work out if your developers were comprised almost entirely of freelancers, but even freelancers expect to get paid for almost every project they complete. Maybe if your developers were also authors or blog post writers in their previous lives then they'd understand and appreciate the commissions structure a bit more.
Keep in mind, it makes little sense to give developers commission upon deal closure because, unless they directly assisted sales in closing the deal, you're essentially giving them money for no reason. Commission, if you're going to give it, should be handed out to developers after they do their part of the work successfully, in which case how is this different from a bonus?
Almost every other part of the business (marketing, engineering, professional services, G&A) is expected to perform or deliver at near perfection (say, >90% for a sloppy organization).
The only exception to the non-sales role that allows for a "low" success rate would be R&D.
As others mentioned in the comments, bonuses are typically the way to reward non-sales staff upon completion of their portion of the work. As well, there are usually equity pools that staff participate in.
A commissions incentive structure is incredibly stressful for employees who expect steady, dependable and predictable paychecks with bonuses on top. Commissions incentive structures often attract and encourage aggressive personalities and characteristics.
It may work out if your developers were comprised almost entirely of freelancers, but even freelancers expect to get paid for almost every project they complete. Maybe if your developers were also authors or blog post writers in their previous lives then they'd understand and appreciate the commissions structure a bit more.
Keep in mind, it makes little sense to give developers commission upon deal closure because, unless they directly assisted sales in closing the deal, you're essentially giving them money for no reason. Commission, if you're going to give it, should be handed out to developers after they do their part of the work successfully, in which case how is this different from a bonus?
It's also worth pointing out that sales and development have substantially different work cycles. A sales is a binary event, once it's done, it's done. Development on the other hand is (mostly) never complete. There's maintainence to do, features to tweak, bugs to fix and so on.
Let's consider a bug report. Let's assume the client is not paying to get the bug fixed. Which developer then wants the job? Indeed since programmers are incentivized the same way as Sales, they need to "complete" lots of jobs quickly. The faster the better. Which leads to more corners being cut in the first place. Worse code, no-one interested in maintainence - these are not recipes for quality products.
One of the bigger problems with commission based salesman is they they'll sell anything - limiting them to selling only what is already available takes strong management, and the occasional waving of a big stick. Our sales people work inside some tight constraints and are financially penalized when they oversell. This is a reaction to past sales people overselling, angering their commission, but for work which was ultimately unprofitable because they mis-sold the client the wrong product.
Culturally sales people are used to a commission -programmers are not. Sales people sell a lot of things that are eh to sell, and avoid products that are worthwhile, but hard to sell. If programmers were the same way we'd end up with mountains of 99c apps that do nothing as programmed searched for the killer app that takes no risks, but is easy to sell. Oh wait...
A single developer is ultimatlely paid on commission already - but he's also motivated by the health of the business as a whole. The employee working on commission enjoys none of the long-term upside of the business, yet shares in all the short term downside. He'll naturally want to work only on the "hits" and will quickly abandon projects if they're not an inmmediate success.
We could also talk about co-operation (sales is notoriously insular, whereas programmers benefit from being sharing knowledge), the whole concept of "after sales service", and so on, but I think you've got the point.
It's good to ask this sort of question- but in this case I don't see any benefit in paying them on commission, and I predict it would optimize developers in all the wrong sorts of ways, ultimately resulting in very bad code.
Let's consider a bug report. Let's assume the client is not paying to get the bug fixed. Which developer then wants the job? Indeed since programmers are incentivized the same way as Sales, they need to "complete" lots of jobs quickly. The faster the better. Which leads to more corners being cut in the first place. Worse code, no-one interested in maintainence - these are not recipes for quality products.
One of the bigger problems with commission based salesman is they they'll sell anything - limiting them to selling only what is already available takes strong management, and the occasional waving of a big stick. Our sales people work inside some tight constraints and are financially penalized when they oversell. This is a reaction to past sales people overselling, angering their commission, but for work which was ultimately unprofitable because they mis-sold the client the wrong product.
Culturally sales people are used to a commission -programmers are not. Sales people sell a lot of things that are eh to sell, and avoid products that are worthwhile, but hard to sell. If programmers were the same way we'd end up with mountains of 99c apps that do nothing as programmed searched for the killer app that takes no risks, but is easy to sell. Oh wait...
A single developer is ultimatlely paid on commission already - but he's also motivated by the health of the business as a whole. The employee working on commission enjoys none of the long-term upside of the business, yet shares in all the short term downside. He'll naturally want to work only on the "hits" and will quickly abandon projects if they're not an inmmediate success.
We could also talk about co-operation (sales is notoriously insular, whereas programmers benefit from being sharing knowledge), the whole concept of "after sales service", and so on, but I think you've got the point.
It's good to ask this sort of question- but in this case I don't see any benefit in paying them on commission, and I predict it would optimize developers in all the wrong sorts of ways, ultimately resulting in very bad code.
This is a great point, especially the fact that sales are binary and development isn't.
In software consulting, people are generally measured against utilization. It isn't as purely formulaic as commission based sales, but there's usually a utilization target of some kind. If your target is 80%, and you find yourself only 70% utilized, you won't expect a good bonus or raise. If it's 50%, you start looking over your shoulder.
I think in general it's a good idea to tie compensation to the benefit people bring to the business. Giving some kind of bonus to people for the profitability they bring to the firm is great. You just have to be careful that you're not screwing up teamwork or getting people too focused on the wrong things. (You don't want to incent short term profitability at the expense of customer satisfaction)
I think in general it's a good idea to tie compensation to the benefit people bring to the business. Giving some kind of bonus to people for the profitability they bring to the firm is great. You just have to be careful that you're not screwing up teamwork or getting people too focused on the wrong things. (You don't want to incent short term profitability at the expense of customer satisfaction)
I would say it's probably close to impossible to directly correlate a developer's input to an amount of money his effort is worth in the form of a commission.
Also software planning, architecting, developing is such a nuanced process that it would likely be easy for someone who didn't want to pay someone substantially for their efforts to "sabotage" them.
Also I think in the big picture business folks likely wouldn't want to see the reality, which is that developers, in a technology-driven business are likely worth 90% of revenue while everyone else is likely worth something like 10%.
Also software planning, architecting, developing is such a nuanced process that it would likely be easy for someone who didn't want to pay someone substantially for their efforts to "sabotage" them.
Also I think in the big picture business folks likely wouldn't want to see the reality, which is that developers, in a technology-driven business are likely worth 90% of revenue while everyone else is likely worth something like 10%.
I spent a number of years working on a similar product, a B2B base platform that was heavily customized for the larger customers. The packages would typically sell for high six / low seven figures.
One customer wanted a module that wasn't just custom but wholly new, and the whole deal depended on it, so a dev was put on it for about 4 weeks and given a bonus to get it done fast. I never got the exact number, but he told me it was going to be enough to "add that garage on to the house".
One customer wanted a module that wasn't just custom but wholly new, and the whole deal depended on it, so a dev was put on it for about 4 weeks and given a bonus to get it done fast. I never got the exact number, but he told me it was going to be enough to "add that garage on to the house".
I actually like your idea - I think tech work has a low top end, and sales a much higher end (but for other reasons).
Developers are paid for the block of time. Sales people are paid a very low salary, and then can control how much they make by hustling. Developers wouldn't really be in control of how much business they bring in, so I could see it mainly working as a "bonus basis".
Developers are paid for the block of time. Sales people are paid a very low salary, and then can control how much they make by hustling. Developers wouldn't really be in control of how much business they bring in, so I could see it mainly working as a "bonus basis".
In the world of sales, for the most part you make a sale or you don't. With programming, you can tackle the problem in many ways. There's no easy way to measure quality. If you pay just for getting the job done, you're encouraging programmers to complete more tasks faster which would lead to poor quality code, endangering the health of the company as a whole.
I think blunt incentive based systems tend to encourage aggressive tactics.
If someone is going to suffer from the recklessness of a sales tactic, its someone outside the company.
If someone is going to suffer from the recklessness of a tech strategy, its going to be the company.
If someone is going to suffer from the recklessness of a sales tactic, its someone outside the company.
If someone is going to suffer from the recklessness of a tech strategy, its going to be the company.
I would think that most developers wouldn't want to be paid that way. I heard of bonuses if things go successfully, but not straight commission. Most people want steady pay. If not they go into sales or freelance.
I agree with this. Having a large portion of payment being based on commission seems hard to quantify and therefore hard to depend on consistently. It can lead to misunderstandings as a seemingly hefty feature might bring a lower-than-expected commission. Contrast that to sales where its dollar amount of new business is obvious to both parties.
For us, we've brought on developers with the understanding that as their contributions help the business grow, we'll raise their salary/give bonuses accordingly. So far it's been very effective.
For us, we've brought on developers with the understanding that as their contributions help the business grow, we'll raise their salary/give bonuses accordingly. So far it's been very effective.
I work in the B2B space and our sales people are paid a commission on the clients/projects that they sign up. We have a base platform, but the clients/projects that we being in typically require a fair amount of custom integration. So, I am curious if any company has paid developers a commission based off of which projects/clients that they develop against?
I don't know if this is a good idea or how it would work out, which is why I am curious if any company has ever tried this?