Ask IH: What motivation system can be used for developers besides a fixed salary?
For jobs where it’s easy to count an employee’s contribution in money, salary can be represented as a percentage of a “benefit” for a company. For example, a salesman can receive 10% of a transaction amount.
But the developer's contribution is difficult to measure in money. Metrics such as amount of code, number of commits or number of tasks are also loosely related to business metrics.
Are there any ways to bind business metrics with developer’s income?
There is a fundamental flaw in trying to bind business metrics to people's income:
People are pretty good at gaming the system
An example from back in the day when I was packing bread:
One part of the bonuses was tied to our manager picking one random bread out of the packaging line and sending it to qualify assurance. The bread would be measured for size, appearance etc and that would be translated into bonuses of the whole factory.
The flaw here was that the manager's own bonuses relied on that single bread too. So we would usually spend quite some time to find the best possible bread to send to quality assurance, measuring and weighing the breads on the packaging line.
What you should do instead is to hold on to your good developers as much as possible as they are scarcity. You should empower your dev teams and embrace good craftsmanship and quality over artificial metrics. If you want to bind their success to company revenue, consider giving them sweat equity when reaching a certain milestone.
Yeah, I also thought about cheating the system. I agree that equity can help to keep the feeling that employees and founders/investors in the same boat.
People will game anything, including sales quota. Sales quotas are at least close to being aligned with business needs, mostly suffering from short vs long-term differences in goals, though.
Any kind of engineering-related metric is hopelessly easy to game and engineers are, by training, good at looking at systems and solving for how to optimize for a desired characteristic, be it space efficiency, throughput or bonus checks!
Your best bets would be either equity or profit sharing as incentives and determine contributions based on feedback from managers, peers and those who later take over their projects.
Sales quotas can be tricky. If you're selling projects or customisations, you might be tempted to "do harm" (e.g. close a big deal that you know will end up hurting the company in long run).
I've had the luxury of seeing a company that does not have provision based salary for their salespeople, and it turned out to be one of the best things on a bigger scale that drives that company to do good decisions.
Myself and most of my developer friends are motivated by remote work, the ability to create our own schedules, and unlimited vacation policies (not that we take a lot of vacation — it's just nice to know that we can take a day to recoup after a busy project).
And some people are simply motivated financially. Raising salaries, bonuses, and granting stock options are good for these people. (I know you wanted some more creative ideas though.)
Site Reliability Engineering does raise some interesting points regarding metrics.
For example, some contrarian metrics like
can be combined into one metric that provides an incentive to strike the right balance. I might not get this quite right ... but that is the gist of it.
Still, the incentive to avoid taking on technical debt is relatively abstract with that approach. At all the companies I have worked at, people did not take technical debt seriously at all. They were proud of their "creative" solutions. Without fail, the software got harder and harder to maintain ... but people still chose willful blindness and argued that there is just no other way. Their instinct is coming up with solutions and workarounds in the operations department when the stability metric degrades. The idea of ever fixing code quality issues is alien to them.
So, I feel like one piece of the puzzle has to be a standardized way to visualize how technical debt develops over time, possibly as part of code reviews. A metric derived from the change in code quality could then affect the stability metric mentioned above.
Still, introducing any such system is difficult because it introduces a lot of management overhead ... and it can clash with the belief system of a superstar developer.
Does the app work for the users? Are new features implemented roughly on schedule (people like to underestimate the time it takes to implement something, take that into account!)? Are bugs fixed in a timely manner?
There are plenty of possibilities to measure success in every stage of a startup or project.
This comment was deleted 4 years ago
This comment was deleted 4 years ago
Just a theoretical question for discussion. I work as a software developer and had a discussion with CEO about motivation system for developers. But we ended up with opinion that it's hard to bind income with dev metrics because of the reasons that was explained in this thread (for example, system can be cheated). So, it was interesting for me to see the IH community opinions.
This comment was deleted 7 years ago
This comment was deleted 7 years ago
some 80~90% of open source is done by paid developers. Companies have a strong interest that their employees develop open source.
That's a really good point. Another example is the video gaming industry, which has historically had very high demands in terms of skill, working hours and risk tolerance and is horribly paid. Yet, there are still a lot of people who choose to do it (until burning out, at least).
I agree that money is not the only motivation, but formally people work for money :)
About 1: people who work on open source software also can make money. For example, they can provide paid tech support, enterprise license and so on.
About 2: yeah, these can work for science :)
You should check the yearly StackOverflow survey for data what motivates a developer. In 2018 survey the money/compensation is only under 20% (while still being biggest single factor), there is e.g. remote work possibility at 10%.