Entering my second decade in software development and moving up in various leadership roles, I’ve been exposed to many different incentive plans to help “boost morale and increase performance”. In my experiences, people were trying to do the right thing and give people more of the carrots and less of the sticks. However, most times you wind up establishing the wrong incentives that could in fact backfire so greatly it changes the cultural fabric of your company. Below I outline what I’ve found to be anti-patterns in bonus structures for engineering teams and what a better approach could look like.
To make sure we level set on what I’m talking about… This article is referring to any compensation package that may involve a bonus structure whereby meeting certain criteria you get additional money paid out to you.
These are based on my experiences, feedback from teams I’ve run and my own personal beliefs on the subject. These are based on personal observations that any devised system will ultimately be gamed. This also applies more towards engineering teams since sales team goals are a different beast.
“Your bonus is based on hitting goals you commit to”
This one is pretty common in “agile” type shops where you’re committing to hitting targets or OKRs (objectives and key results) every 2-4 weeks. While good, in theory, it goes against everything it means to be agile unless when a change in the landscape occurs your bonus targets for that period also change. For example: “I promised Project A but if I spend a couple days helping our sales person get around a bug, they could land a huge deal for the company. If I help our sales person I’ll get a pat on the back, but my team will miss our bonus. I’ll help sales later.”
Perceived Incentive: “Pad as much as possible to not have a chance of missing the date, commit to as little as possible and make your boss challenge everything you say, Avoid helping across teams”
Result: A culture of mediocrity due to no one pushing hard to meet deadlines because they’re padded so much and everything takes 50-80% longer to get delivered. If I think I might miss my dates I ship anyway even if I know it will fail in production. Hey, I shipped! This anti-pattern promotes silos and limits cross-team communication.
“Your bonus is partly based on hitting cost cutting or COGS metrics”
This one is based on keeping costs down. COGS = Cost of Goods Sold. Otherwise known as cost control measures. In a fast growing tech company, this might be the most dangerous one. There are so many factors at play that would require a highly detailed model of the world. For example, if you said costs can’t grow past 20% this quarter, but we get a sudden boon of customers, or we have to scale for a big sales event or promotion, how do you tie that back to the original commitments? It’s highly tedious and error prone. Other examples would be not developing a feature unless it has a certain expected dollar amount of return. The analysis of that alone will cripple you.
Incentive: “I will take as little risk as possible, I will overload as many servers as I can and not run anything over capacity and will accept much high latencies to protect our bonuses. I will not try out new ideas because I don’t want my teammates to be punished if I have to spend money temporarily to do that until next year.”
Result: You have a culture that incentivizes complacency and dissuades innovation. New features will never get approved because COGS have to get adjusted every QTR to account for new projects. Those adjustments will be wildly inaccurate and you now need a COGS review board for new initiatives. Don’t let finance dictate growth in a growth phase. COGS come into play most effectively when you have a solid business in the exploit phase.
“Your bonus is partly based on production status”
This one is based on the idea that service uptime, the number of production bugs found or other service level metrics tie into your bonus structure. While at a company level this makes sense at the employee level it falls apart pretty fast. Many things are out of your control, such as someone cutting your data center’s primary and redundant fiber pipes while doing routine maintenance with a shovel (it happens!). Did I do a bad job or were other incentives in place for to not consider a more fault tolerant architecture like COGS?
Incentive: “Never push code unless mandated by your boss, do not take risks, pad your estimates another 200% to factor in longer times in testing and QA cycles, push off acceptance to some other group to get blamed for uptime if possible”
Result: You definitely do not have a ship-it culture, you have a culture of fear of change. Deployments slow down, new projects stagnate, no one wants the responsibility to touch production.
Let’s tie all those anti-patterns together with the data center pipes being cut example from above and you can see how these start to de-incentivize employees.
“Yes, we had a production outage so my bonus will get dinged because I didn’t hit our uptime criteria. I was hitting your cost-cutting goals by not running multiple data centers and I didn’t push out the fallback code because I was too scared to touch production and potentially cause issues and lose that part of my bonus. I did notice I could have moved a backup server to the other datacenter but I would have missed our deadline for Project A and we would have missed our OKR bonus.”
So now you can’t win because you set up a system where we will fail at some tier.
Whenever a bonus structure is proposed you have to look at what the actual incentives are. As many have learned from the book “Freakonomics”, decisions can have odd repercussions that the original authors did not intend, “The Cobra effect “
Some of the better approaches I’ve seen that didn’t have the incentive downsides:
Profit sharing / sales-based bonuses
When the company does well everyone does well. It can get everyone moving in the same direction to help attract and retain customers by getting everyone caring about success. Some have mixed feelings on that one but I’ve seen it work more effectively. It’s not about creating one-off features just to land a deal, it’s about helping the sales team feel like engineering is a partner and everyone is rowing in the same direction.
Put it into salary
When recruiting is all said and done and it’s time to make an offer the #1 factor is usually base salary. A bonus is seen as just that, something that may or may not be paid out based on some criteria. If you want to increase your chances of winning against competing offers put that bonus into base salary.
Thought based bonuses.
If this is all too complex for you, perhaps get rid of bonuses altogether, raise salaries and offer more spontaneous rewards. The greatest bonus I ever received was after a successful launch of a project after working a good deal of hours on it. My boss came to me and said: “Take 3 nights at the hotel of your choice with the family and we’ll cover everything.” Now this wasn’t the biggest monetary bonus I had ever gotten but it stuck with me the most. There was actual thought into how that launch must have affected my family life and how I needed some face to face with them again. He could have just given me a check and be done with it, but he put some thought into it. Even if it was a little thought, it was something. (thanks, JB!)
Another nice bonus is autonomy. If someone has been a consistent performer give them a chunk of time where they get to work on whatever project they feel interests them most. Do they want to improve a query? Refactor something? Hackathon up a new product? Go for it, time is your bonus.
I’ve also seen gestures like letting employees expense nights out with their spouses, babysitting included if they have kids, blocks of days off, gift cards for going above and beyond, and other various perks. Did I do a great job at something? Send a note to the CTO for a hive five. At the end of the day it’s about recognition.
Your top performers would be your top performers regardless of bonus structure. Top performers are internally incentivized. Increase their pay so they don’t have to worry about money issues and focus on retaining them.
You need to incentivize risk and stretch goals. No one will stretch if they are hit with a stick if they don’t make it a full 100% of their commits, 100% of the time. When you look at those incentives there are no upsides for stretching and taking a risk. Why make stretch goals when if you don’t hit that 90-100% goal you only get a stick?
You’re telling people to set mediocre goals because there’s only downside to taking risks. What about those who don’t strive to be bold and innovate, no matter what system you set up? Don’t fear letting people go. If you have a consistent low performer it’s cheaper for the company to let them go rather then keep shifting them around to other projects. The larger the company the more time you can invest in improving someone but small companies don’t have that luxury and each headcount needs to have a significant impact.
As John Doerr who brought the OKR model to Google says:
“Don’t tie the OKR goals to bonus payments, except for sales quotas. We want to build a bold, risk-taking culture.”
Some references that also cover this topic:
Joel On Software – Fog Creek Compensation
John Doerr on OKRs
The Surprising Truth on What Motivates Us (only 10 mins)
Ted Talk – Dan Pink The puzzle of motivation