There’s a lot we don’t know about the brain, but we did figure this out: Reward desired behavior, and you’ll get more of it. Give a lab rat a snack for pushing a green button, and he’ll push that button more and more, high school psychology lessons told us.
The corporate world took that lesson and came back with financial incentives for high performance. Do a great job, and take home a bonus.
But those lessons about motivation omit something important: Lab rats push colored buttons — they’re not devising solutions to complex problems. Studies involving creative or conceptual tasks, as opposed to mechanical ones, have shown that attaching large financial incentives actually leads to poorer performance.
That’s right — incentives didn’t just fail to make participants’ performance better, they actually made it worse.
In his best-selling book Drive: The Surprising Truth About What Motivates Us, Daniel Pink broke down these surprising findings and offered alternatives to financial incentives. And the idea resonated: This video about his findings has 17 million views.
So why are companies still using bonuses to incentivize software developers?
Ask agile coach Allen Holub, and he’ll tell you a pretty simple story: Upper managers recreate their own compensation packages for all the teams “under” them.
What those managers don’t understand, Holub said, is that software teams aren’t collections of individual technologists. They’re complex and interdependent — they’re systems. Toss the wrong incentive into a system, and you’re going to throw off the delicate balance that leads to happy collaborators and valuable work.
Why Are Bonuses Bad for Software Teams?
You Compromise Agility
In this story about the benefits of agile, Holub argues that the question, “Is my company agile?” is one that should be taken at face value. An organization can call itself agile if it is agile — in the dictionary kind of way.
An agile team is resourceful and can shift directions quickly and efficiently. Toss in a bonus structure that incentivizes a particular way of working or thinking, and that agility is compromised.
“Typically, you’re being rewarded for hoarding information.”
“The bonus is an incentive that encourages people to work in a certain way, and those ways are hardly ever ways that encourage agility in the shop,” Holub told Built In. “Typically, you’re being rewarded for hoarding information. You are so much more effective than everybody else because you know stuff that other people don’t know.”
You Get What You Incentivize
You’ve probably heard some version of the Peter Drucker quote, “What gets measured gets managed.” Many leaders take that maxim and extrapolate it to individual employees.
But attempts to measure individual performance often lead organizations to build broken incentive systems, software consultant Kevin Rutkowski told me.
When he worked in quality assurance at Dell, for example, software testers were measured based on how many bugs they logged. If a tester logged a bug in a chunk of code that turned out to be fine, that mistake was counted against them. Meanwhile, developers were measured based on how bug-free their software was.
This, of course, led to problems. There were constant arguments between testers and developers over what was and wasn’t a bug. Testers were disincentivized from tracking down large, difficult-to-detect problems in the codebase, because those still only counted as one bug. And the worst developers were consistently given the easiest tasks in order to keep their bug counts low enough to justify their employment.
Dell only used these numbers to determine an employee’s rating in annual reviews, but the measurements still wreaked havoc on team cohesion. Throw financial incentives into the mix, and the risk associated with misaligned incentives gets even greater.
You Misunderstand Employees and Projects
Without crystal clear communication channels, it’s incredibly easy for higher-ups to misunderstand a big project’s scope, blockers and stakeholders. That, in turn, makes it easy to offer the wrong incentives.
Alex Kuhner, director of program management for data at the New York Times, worked on one such project in a previous role at an education technology company.
Kuhner’s employer was rushing to deliver an app for educators in time for teacher training. The client was a New York City school district with thousands of teachers, so reducing the scope of the project wasn’t an option. There were about six scrum teams tackling the work, as well as a few offshore teams. When management urged everyone to “do whatever it takes” to deliver the project on time, the teams at headquarters hunkered down, working long hours and dealing with mounting technical issues. The teams offshore in Ukraine, however, worried they were in danger of losing their contract, and they started cutting corners to meet management’s demands.
“I don’t think there’s an amount at which people would have been like, ‘Oh, yeah, that makes sense.’”
When Kuhner’s teams raised concerns about the code coming in from offshore teams, however, company leaders didn’t do anything to help.
“We kept expressing, ‘Hey, we’re not sure we’re going to make it,’” Kuhner said. “It’s just like any software project, it’s unclear exactly how some of the things are going to play out. And you can’t just keep throwing people on it. That’s not going to help at some point.”
That’s when management made what was arguably its biggest mistake. Company leaders offered the teams a bonus if they finished the project on time: about $700 each.
People weren’t happy.
“It was both that it was a laughable amount that wouldn’t really change how we were working, and also that people felt like there wasn’t really any amount that could change [the outcome of the project],” Kuhner said. “I don’t think there’s an amount at which people would have been like, ‘Oh, yeah, that makes sense.’”
The biggest issue with the bonus, however, was that managers had misunderstood their employees. Kuhner and others were already motivated to finish the project because they wanted the win for their constituents: teachers. They didn’t need a cash incentive to work harder; they needed their superiors to listen when they explained what was blocking their progress.
Why Do Companies Keep Offering Bonuses for Developers?
Financial incentives are easy to get wrong, yet plenty of software teams still take the risk. Why are bonuses so tough to shake?
Holub named one potential reason: Corporate leaders get bonuses themselves, so they replicate that model for other employees. According to Rutkowski, it also comes down to structural problems in how managers see their work.
Managers Have an Incentive Bias
People tend to think better of themselves than they do others.
“Most people think they themselves have good and pure intentions,” Rutkowski said. “But everyone else, boy, they don’t have good intentions. And people are always looking out for the ways others might take advantage of them.”
“People are always looking out for the ways others might take advantage of them.”
In this context, that tendency is called incentive bias: Research has shown that people tend to think others need external rewards to do good work, while they themselves are intrinsically motivated to do well.
If executives and managers don’t trust their teams to do good work without a financial incentive system, incentive bias may be to blame. Odds are, those employees will show up and work hard, even without that dangling carrot in the form of a bonus. But management may be too nervous to find out.
Managers Don’t Mind the Drawbacks
You get what you incentivize, and some managers are fine with that.
Consider a scenario like the one Rutkowski described at Dell: Two teams have conflicting incentives, which leads to arguments. If managers view the arguments as a necessary evil to keep both teams scrambling toward their goals, the incentive system could stay the same year after year.
Managers Are Scared of Looking Bad
If an initiative, project or new hire fails miserably, managers are less likely to be fired for sticking with conventional wisdom (read: financial incentives) than for trying something new by throwing bonuses out the window, Rutkowski said.
Or maybe it’s too tough to prove that existing incentives aren’t helping. Software is complicated, and the success of a project could easily be attributed to financial incentives in the absence of a more obvious explanation. Doing away with bonuses on an already-successful team could make a manager look irrational — or put them at risk of (gasp) losing their own bonus.
What Works Better Than Bonuses?
In summation: Bonuses are kinda bad. But that doesn’t mean companies shouldn’t work hard to motivate employees.
When it comes to complex, conceptual work like software development, intrinsic motivation is key. Pink used the open-source ecosystem as evidence that feelings like mastery, autonomy and purpose can be just as, if not more, motivating to knowledge workers than money.
He also mentioned Atlassian, which gives employees one day a quarter to work on whatever they want — like an internal hackathon. There are no rewards involved, yet employees have used those days to make sweeping software fixes and formulate big product ideas.
Here are some other ways software orgs can foster intrinsic motivation:
Train Management on Intrinsic Motivation
If companies want managers to promote intrinsic motivation, companies should train managers on how to do that.
“It takes a lot of effort,” Rutkowski said. “It takes communication with your employees on a regular basis, at all levels, and it takes time.”
Managers will notice the costs associated with that extra time, so they need to understand the benefits as well. Team culture and output should improve as managers routinely check in with employees and search for opportunities to develop mastery, autonomy and purpose.
Train Employees Continuously
“It’s amazing how many times I’ve heard managers say something to the effect of, ‘Well, we don’t want to send [employees] to training, because then they’re just going to leave our company for more money somewhere else,’” Rutkowski said.
Don’t be like those managers. Instead, help employees build mastery by offering ongoing training opportunities in areas that will help them do their jobs better — or even in areas that would help them do other people’s jobs better.
“There is some benefit to having your testers learn some development and having developers learn some testing and some project management and some product management,” Rutkowski said. “Having the whole team learn those skills gives you a stronger team overall and allows people to fill different roles if they get tired of what they’re doing.”
Furthermore, adding a market-based-skill salary adjustment — similar to a cost-of-living adjustment — helps ensure employees are being compensated for their new skills and increased mastery.
Connect Developers With Users...
Speaking with end users motivates purpose-driven developers. Hearing about pain points and success stories directly can inspire game-changing solutions and new ideas — if management lets it happen.
Rutkowski recalled an experience he had while working at Texas Education Agency.
“We were working on really old software, just doing maintenance work, sitting in the basement,” he said. “It was kind of tedious work. And it could feel like, ‘Really, why am I here?’”
“Sure, the technology was a little old and our work environment wasn’t the greatest, but we were making an impact.”
But, every so often, he and his colleagues would get the chance to talk to people who used that software in classrooms across Texas, and those conversations would completely change his perspective.
“Sure, the technology was a little old and our work environment wasn’t the greatest, but we were making an impact,” Rutkowski said. “We could see, for a very low budget, what kind of great education we were helping kids get. And if we didn’t work on the software, what harm would that do?”
...Or at Least Explain the Impact
Speaking directly with users isn’t always possible, but company leaders can still take care to share the impact of what developers are building.
Kuhner remembered when a team at his former edtech job had to drop everything on its plate to write up a time-sensitive summary report for a client. When managers explained the sharp pivot, they said the client needed the summary in order to avoid noncompliance fees.
“The engineer kind of lit up and was no longer resentful of the project.”
Later, when one of the engineers who worked on the report was presenting it at a monthly company demo, he shared his annoyance at the project’s tight timeline. The CTO responded with a different reason than the one originally given: If the report hadn’t been delivered on time, teachers would have had to compile it themselves, which would have caused a lot of stress and canceled school days.
“The engineer kind of lit up and was no longer resentful of the project,” Kuhner said. “In that case, it was the product manager who had decided to tell us how much money our customers were worth rather than what it would mean to the teachers, thereby missing the opportunity to refocus it on the actual users.”
Make Your Company a Good Place to Work
At the end of one particularly long and challenging project, Kuhner’s former employer threw a party for the teams involved. There, the company handed out engraved iPods as a thank you gift. Kuhner still has his.
“The gift was successful because it was unexpected,” he said. “And it wasn’t, like, a term of anything. It was simply something that appeared after we knew we had done a good job.”
Gifts leave a strong impression when done right. They may come in the form of paid time off, trips, company outings, parties or gadgets — as long as it’s not contingent on performance, it’s a gift.
A consulting company Rutkowski used to work for would celebrate “cookie Wednesdays.” The cookies probably cost about $10 per person per week, he guessed. Offer someone a $500 bonus, and you’re likely to get eye rolls, but the cookies felt like a genuine thank you.
“Getting those cookies every week just made us feel appreciated,” Rutkowski said. “In that case, it wasn’t for a reward. It was just part of making it a good place to work.”
Ask Yourself These Questions If You’re Going Bonus Free:
- Are developers paid a competitive wage?
- Do existing incentive systems reward developers for working collaboratively and remaining flexible?
- Are developers given plenty of opportunities to build their skills in multiple areas?
- Does the organization take real steps to reduce stress and improve engagement?
- Do developers get to see the impact of their work?
- Do developers have unstructured time to work on projects of their choosing, or are higher-ups counting each unallocated hour?
