Paying Software Engineers a Cash Bonus Makes No Sense
Many companies structure their job offers for developers in terms of equity, salary, and an annual cash bonus. This bonus is usually tied to performance, and is at the company’s discretion.
Having a cash bonus structure won’t improve software engineering, and only causes problems:
- The payout cliff event creates a reason to quit.
- Engineers won’t be more motivated by the promise of future cash.
- If you don’t pay the full bonus, it will demotivate or anger the engineer.
Beware the Cliff!
A “cliff” is a guaranteed pay-out on a future date. At many tech companies, you receive a chunk of equity one year after you start; and a bonus at a set time of year. For example, a company could promise a 10% bonus on January 15th if the organization unit meets its goals.
The logic of a cliff is that people will be motivated to stick around to get their bag of loot. But this is a double-edged sword. Some people may see the cliff — which was supposed to be a reward to encourage retention and performance — as the best time to quit and switch jobs. And the kind of employee who is biding time just to get a payoff is likely to be disgruntled (or worse, they might be toxic).
Software engineers are very good as doing this kind of math and planning.
Cash Bonuses Don’t Motivate Engineers
The amount of cash paid won’t correlate with a software engineer’s performance. If you double someone’s pay, they’re certainly less likely to quit, but they won’t code twice as hard. If you pay someone half of what they’re worth, they’ll be grumpy and checked-out because they think you’re an unfair jerk, but not because the cash itself dictated how hard they’ll work.
Software engineers are motivated by having interesting problems to solve, being treated with respect, and a positive day-to-day culture. Their compensation must be reasonable — but this is more related to respect than it is to the cash itself.
Can You Risk NOT Paying the Bonus?
It’s very common for bonuses to be structured as discretionary, so the payout is based on whether the employee or team hits a certain target, or if a manager ranks the employee highly.
On its face, this model makes a lot of sense. Companies should encourage meritocracy and generously reward the top performers as a way of creating incentives and accountability. And shouldn’t companies only give bonuses when they have an especially good year?
But if taken seriously, that means there’s a good chance many people won’t get a bonus because targets weren’t met. For software engineers, this usually means not hitting some delivery expectation or milestone set months ago, even though engineers often don’t have much control over shifts in priority or external dependencies. This leads to unpleasant conversations like:
Manager: You didn’t hit goals X and Y, so no bonus for you.
Engineer: But, I didn’t hit these goals because <thing out of their control>
Manager: <non-helpful but final response>
Engineer: <updates resume, mentally composes resignation letter>
Some companies avoid conflict and always find some way to give everyone their full bonus. This is a de-facto bonus-as-wage, and it will quickly become ingrained as an expectation — but with the problems of a cliff, and with the administrative overhead.
Just Pay the Cash as Salary
Cash bonuses work well for certain parts of the business, like sales, but aren’t a good idea for engineering. Just add that money to the base salary so people get paid a steady wage and there isn’t a weird dynamic of cliffs or whether to pay the bonus.
