Everyone so often, I get asked if I would consider offering a team of engineers who are working on a critical feature a spot bonus. The idea is to incentivize the team with the bonus, presumably to hit a deadline, which is similar to how sales teams offer spiffs.
My answer is always “no”. I'll offer a few practical reasons for why that is, meaning I will shy away from my own subjective reasons for not implementing this structure.
The first objection I have to this approach is unlike sales, this approach lacks objectivity for software development. Consider a BDR that is spiffed on the number of meetings they can schedule in a period of time. The outcome can be objectively measured: did the rep meet the target or not? It’s much harder to do that with software development.
Let’s for a moment assume that I wanted to spiff an engineering team working on a critical feature. The team would get a bonus if they completed the work by some deadline. What’s the definition of completeness? Is the team rewarded once they finish coding the feature? What about tests? What happens if they rush the feature out to attain their bonus, yet omit all tests which then results in catastrophic failures? What if the customer, or end user of the feature, requests additional functionality?
“Show me the incentive, I'll show you the outcome.” Charlie Munger
Yet another reason why this is a bad idea is the reward needs to be commensurate with the effort. I’ll offer another sales analogy to highlight this one. A sales-person that wins a $1M deal will be rewarded more than one that wins a $100K deal. Sales operate on commissions (and bonuses and myriad of other incentives). The more you sell, or more generally targets you attain, the more money you make.
Let’s go back to the example I gave about wanting to set a bonus for the team working on a feature. Should all developers on this team share the same bonus $ amount? Or should that be allocated by effort? Even writing that makes me wince, it’s a terrible idea.
Let’s extend this example further. Consider that we now have two teams working on critical features and we wanted to offer a bonus for each team. Should they both get the same $ amount? What if the first feature is far more complex than the second? What should we do if the second feature is simpler, yet dramatically improves customer satisfaction?
The third reason I give is one of uniformity. Sales compensation is applied uniformly to the entire team. All reps are commissioned and earn their bonuses based on their attainment against sales targets. “All” being the key word, not some members of the team. Now consider an engineering organization whereby some members of the team are occasionally rewarded because they are working on critical features. The remainder of the team will obviously feel left-out. Why is it that they are also not rewarded? Is their work less important than the folks getting a bonus? After all, isn’t everything that the engineering team working on important and prioritized accordingly?
I don’t have any objections to bonuses, I think they are one of many tools that should be used to compensate and incentivize groups and individuals. I do, however, have issues with using them in this specific setting whereby an engineering team is incentivized to complete a task with monetary rewards.
Sales opportunities will often times come attached with idiosyncratic feature requests from the prospect. That’s normal and will happen as the company starts to scale, especially as it targets enterprise customers. These exceptional asks are where I often get asked to offer my teams a post bonus. My experience, outside of the reasons I outline here, is you should be able to address those without the need to offer monetary rewards that in the long-run can very well lead to bad outcomes.
As more sales reps are hired and as they ramp up, sales opportunities, or deals, start to flow in. However, not every incoming sales opportunity is perfect fit with the startup’s current product. There will inevitably be some % of opportunities that require some features that the current product doesn’t fulfill. As the deal flow increases, so will the number of deals that are contingent on some feature enhancement increase.
If you’ve successfully used this incentive structure at your organization, I’d love to here how and whether some of the points I raise are actual objections or me just being a pedantic purist!