Mixing
Management tactics and bonus programs
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
19
down vote
favorite
I was reading The Econ 101 Management Method by Joel Spolsky. He speaks of management tactics to motivate developers by paying them for fewer bugs (for instance). He describes how bad such approach can be, and what drawbacks it has.
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks. For example, a developer creates a big and complicated piece of an application, and gets more money for it.
Isn't it better to raise the developer's salary since he/she is qualified and experienced enough to handle such a complicated task? Or to have task-money policy? Has any manager/team leader had such an experience?
software-industry management bonus
edited Jul 30 '12 at 16:04
gnat
3,23273066
asked Jul 30 '12 at 11:36
superM
2,34421927
migrated from programmers.stackexchange.com Jul 30 '12 at 15:36
This question came from our site for professionals, academics, and students working within the systems development life cycle.
 |Â
show 2 more comments
up vote
19
down vote
favorite
I was reading The Econ 101 Management Method by Joel Spolsky. He speaks of management tactics to motivate developers by paying them for fewer bugs (for instance). He describes how bad such approach can be, and what drawbacks it has.
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks. For example, a developer creates a big and complicated piece of an application, and gets more money for it.
Isn't it better to raise the developer's salary since he/she is qualified and experienced enough to handle such a complicated task? Or to have task-money policy? Has any manager/team leader had such an experience?
software-industry management bonus
edited Jul 30 '12 at 16:04
gnat
3,23273066
asked Jul 30 '12 at 11:36
superM
2,34421927
migrated from programmers.stackexchange.com Jul 30 '12 at 15:36
This question came from our site for professionals, academics, and students working within the systems development life cycle.
8
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
2
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
1
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05
 |Â
show 2 more comments
up vote
19
down vote
favorite
up vote
19
down vote
favorite
I was reading The Econ 101 Management Method by Joel Spolsky. He speaks of management tactics to motivate developers by paying them for fewer bugs (for instance). He describes how bad such approach can be, and what drawbacks it has.
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks. For example, a developer creates a big and complicated piece of an application, and gets more money for it.
Isn't it better to raise the developer's salary since he/she is qualified and experienced enough to handle such a complicated task? Or to have task-money policy? Has any manager/team leader had such an experience?
software-industry management bonus
edited Jul 30 '12 at 16:04
gnat
3,23273066
asked Jul 30 '12 at 11:36
superM
2,34421927
I was reading The Econ 101 Management Method by Joel Spolsky. He speaks of management tactics to motivate developers by paying them for fewer bugs (for instance). He describes how bad such approach can be, and what drawbacks it has.
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks. For example, a developer creates a big and complicated piece of an application, and gets more money for it.
Isn't it better to raise the developer's salary since he/she is qualified and experienced enough to handle such a complicated task? Or to have task-money policy? Has any manager/team leader had such an experience?
software-industry management bonus
edited Jul 30 '12 at 16:04
gnat
3,23273066
asked Jul 30 '12 at 11:36
superM
2,34421927
edited Jul 30 '12 at 16:04
gnat
3,23273066
edited Jul 30 '12 at 16:04
gnat
3,23273066
edited Jul 30 '12 at 16:04
gnat
3,23273066
3,23273066
asked Jul 30 '12 at 11:36
superM
2,34421927
asked Jul 30 '12 at 11:36
superM
2,34421927
asked Jul 30 '12 at 11:36
superM
2,34421927
2,34421927
migrated from programmers.stackexchange.com Jul 30 '12 at 15:36
This question came from our site for professionals, academics, and students working within the systems development life cycle.
migrated from programmers.stackexchange.com Jul 30 '12 at 15:36
This question came from our site for professionals, academics, and students working within the systems development life cycle.
8
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
2
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
1
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05
 |Â
show 2 more comments
8
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
2
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
1
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05
8
8
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
2
2
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
1
1
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05
 |Â
show 2 more comments
6 Answers
6
active
oldest
votes
up vote
10
down vote
accepted
raise the developer's salary since he/she is qualified and experienced enough
to handle such a complicated task?
It would suggest to "Pay a very good market rate or above to the talented developers. Otherwise, they are smart enough to consider other options and switch companies."
have a policy where one can ask for money?
That is dangerous and bad policy for a full-time employee, however, it might be very reasonable for contractors
Some points in regard to software developer's compensation:
- Pay a good market rate or above it to a good developer. Otherwise,
they may consider switching companies. - Terminate contracts with developers who always delay or who have caused problems with a deliverable. After a third big mistake would be a good guideline.
- Allocate enough resources to avoid employees burning out, and have a realistic manager to manage the team of developers.
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
add a comment |Â
up vote
13
down vote
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks.
The only place I've seen this be good is getting hazard pay for being on-call. Nobody wants to do that, and it's not motivation at that point but overtime compensation.
Outside of that, if a programmer is being valuable to the company by doing things that others can't, or is innovating solutions for business then they deserve regular compensation relative to that value. If they're below that rate, then increasing their rate is good.
Bonuses aren't great because programmers by and large realize that you're milking them for production, rather than recognizing their value.
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
add a comment |Â
up vote
9
down vote
For a lot of people, building software has intrinsic value. That intrinsic motivation is more powerful than any financial motivation. In fact, if you try to combine intrinsic motivation with performance-based financial motivation, you'll actually reduce performance.
However, developers still need to eat. So, you need to offer a salary that's comparable to what they could get elsewhere (based on their experience), and other than that you need to separate the work from the financial reward.
I think that's similar to what you're saying, except I'm suggesting paying them for what they bring to the table, not for what you happen to be feeding them today.
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
add a comment |Â
up vote
4
down vote
Premise
A professional is paid for what they do.
Natural consequences follow if that relationship is broken by companies or professionals.
The Mismatch of Bonuses and Research and Development
Bonuses in some companies are a lever to promote compliant and motivated behavior toward requested results. For sales, it is an article of faith that if you sell more, you earn more, and that using commission aligns the salesman's goals with the company goals. Executives are often rewarded with stock options that fluctuate proportional to the top goal the board of directors has set for them which is to increase stock holder value.
Product development and the remainder of the company sometimes share a third bonus methodology. The idea is to reward against a benchmark for profit. No profit, no bonus. Profit above the benchmark, bonuses for everyone. Desired behavior includes good teamwork, widespread ownership of being thrifty with company resources, alignment of worker goals with the goals of the chain of command, and industrious focused contributions by each person each day. These are great goals, even without a bonus system in place because they help the company survive and give employees better job security and opportunity.
What about a development team that labors three years to bring out a successful product? Value is created the entire time, but costs of a big project might hit the company bottom-line hard, resulting in no bonus. Sometimes, the directors give some of the executives the boot about this time, and it is no picnic for development managers or foot soldiers.
Let's say Q1 of the fourth year, the product releases and is wildly successful.
- The sales staff makes record commissions in the same month. Their reward is almost immediate.
- The market may lag a few months, but when Q1 sales are announced, the stock jumps, the executives sell shares, some after not much involvement. Their reward is not immediate, but may be pretty efficient WRT when the market identifies accomplishment.
- What about manufacturing employees? They get some overtime, and in Q2 of year five, the company wide bonus for year four will be paid. They wait about 12 months for their work to bring a bonus.
In contrast, for the R & D staff, no bonus is paid on their three years work unless they stay at their jobs until Q2 of the fifth year. It is not sinister, or part of an evil plot. It just works out that way. For people in our profession, this is mild compared to what happens with start ups and stock options. If there is a bonus for developers at time of launch, at least for those who worked on the project a while, it is probably well deserved.
Some Suggestions
The moral of the story?
- Revenue lags R & D expense, so we would need much shorter cycles in R & D to permit the annual bonus model to more fairly reward the involved rather than the uninvolved. Agile, iterative, incremental approaches give us some relief from the problem if we can put product into customers hands earlier and see profit hit the bottom line while our effort is still remembered.
- It is difficult and potentially harmful to reward someone for a project that is not complete. But we probably do need some recognition and reward for milestones and hard to measure things like focused and methodical effort toward a goal.
- Patents are a prime example of a huge lag between contribution and reward. It is very hard to value a patent at its time of filing, but it may take years if the reward is tied to the time it is granted.
- Knowledge workers like software developers can have a huge impact on the success of their companies. The reality of high turnover among developers makes stock options an interesting instrument. It can induce some to stay, but insures their reward cycle is separated from their contribution cycle. It also means that up and down cycles in staffing may often separate developers from their reward. Shorter vesting times or simply a shared expectation of pay-as-you-go salaries in which extraordinary work is compensated with overtime without the distraction of bonus talk.
answered Aug 18 '12 at 20:37
DeveloperDon
1413
add a comment |Â
up vote
0
down vote
Here are a few points on this subject that I'd like to make:
- The better programmers should make more money and be given more difficult tasks.
- Imagine holding a contest and award a prize for the first programmer to create a solution. Good luck with anyone spending time on anything else. Or watch everyone else give up because they know the better programmer is going to win anyway.
- When the company has a financial windfall as a result of the developer's contribution, they need to feel they share in the extra income. Otherwise, they'll feel exploited
- Beware of the everything is an emergency because nothing will be considered an emergency. It can't always be done, but strive to manage sustainable workloads.
- Do you really want to set a precident of every little bit of extra effort is going to require a bonus attached?
- Before you offer more money, find out if anything else will motivate your developers. You could probably save more money than you think.
add a comment |Â
up vote
0
down vote
Joel wrote another article addressing this question more directly.
In this case an intern came up with an idea that, once implemented, made $1 million for the company. What should be his reward?
He ended up rewarding him with equity in the company, which he was pleased with, but was utlimately not enough to retain him. We discussed this a bit on the gone but lamented Joel on Software forum.
--
In short, hopefully your company is building a culture where people enjoy contributing to what is going on. There is always some drudgery, but in general the rewards should be aligned with skill level and results and wants the team to be successful.
So I would say tread carefully.
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
raise the developer's salary since he/she is qualified and experienced enough
to handle such a complicated task?
It would suggest to "Pay a very good market rate or above to the talented developers. Otherwise, they are smart enough to consider other options and switch companies."
have a policy where one can ask for money?
That is dangerous and bad policy for a full-time employee, however, it might be very reasonable for contractors
Some points in regard to software developer's compensation:
- Pay a good market rate or above it to a good developer. Otherwise,
they may consider switching companies. - Terminate contracts with developers who always delay or who have caused problems with a deliverable. After a third big mistake would be a good guideline.
- Allocate enough resources to avoid employees burning out, and have a realistic manager to manage the team of developers.
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
add a comment |Â
up vote
10
down vote
accepted
raise the developer's salary since he/she is qualified and experienced enough
to handle such a complicated task?
It would suggest to "Pay a very good market rate or above to the talented developers. Otherwise, they are smart enough to consider other options and switch companies."
have a policy where one can ask for money?
That is dangerous and bad policy for a full-time employee, however, it might be very reasonable for contractors
Some points in regard to software developer's compensation:
- Pay a good market rate or above it to a good developer. Otherwise,
they may consider switching companies. - Terminate contracts with developers who always delay or who have caused problems with a deliverable. After a third big mistake would be a good guideline.
- Allocate enough resources to avoid employees burning out, and have a realistic manager to manage the team of developers.
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
add a comment |Â
up vote
10
down vote
accepted
up vote
10
down vote
accepted
raise the developer's salary since he/she is qualified and experienced enough
to handle such a complicated task?
It would suggest to "Pay a very good market rate or above to the talented developers. Otherwise, they are smart enough to consider other options and switch companies."
have a policy where one can ask for money?
That is dangerous and bad policy for a full-time employee, however, it might be very reasonable for contractors
Some points in regard to software developer's compensation:
- Pay a good market rate or above it to a good developer. Otherwise,
they may consider switching companies. - Terminate contracts with developers who always delay or who have caused problems with a deliverable. After a third big mistake would be a good guideline.
- Allocate enough resources to avoid employees burning out, and have a realistic manager to manage the team of developers.
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
raise the developer's salary since he/she is qualified and experienced enough
to handle such a complicated task?
It would suggest to "Pay a very good market rate or above to the talented developers. Otherwise, they are smart enough to consider other options and switch companies."
have a policy where one can ask for money?
That is dangerous and bad policy for a full-time employee, however, it might be very reasonable for contractors
Some points in regard to software developer's compensation:
- Pay a good market rate or above it to a good developer. Otherwise,
they may consider switching companies. - Terminate contracts with developers who always delay or who have caused problems with a deliverable. After a third big mistake would be a good guideline.
- Allocate enough resources to avoid employees burning out, and have a realistic manager to manage the team of developers.
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
edited Aug 20 '12 at 22:10
HLGEM
133k25227489
133k25227489
answered Jul 30 '12 at 13:27
EL Yusubov
34439
answered Jul 30 '12 at 13:27
EL Yusubov
34439
answered Jul 30 '12 at 13:27
EL Yusubov
34439
34439
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
add a comment |Â
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
4
4
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
If you want to be Machiavellian, paying above market rates for your best developers has the twofold benefit of both making their job more attractive, and making it more difficult for them to find another job without taking a pay cut.
– Carson63000
Jul 31 '12 at 2:05
add a comment |Â
up vote
13
down vote
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks.
The only place I've seen this be good is getting hazard pay for being on-call. Nobody wants to do that, and it's not motivation at that point but overtime compensation.
Outside of that, if a programmer is being valuable to the company by doing things that others can't, or is innovating solutions for business then they deserve regular compensation relative to that value. If they're below that rate, then increasing their rate is good.
Bonuses aren't great because programmers by and large realize that you're milking them for production, rather than recognizing their value.
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
add a comment |Â
up vote
13
down vote
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks.
The only place I've seen this be good is getting hazard pay for being on-call. Nobody wants to do that, and it's not motivation at that point but overtime compensation.
Outside of that, if a programmer is being valuable to the company by doing things that others can't, or is innovating solutions for business then they deserve regular compensation relative to that value. If they're below that rate, then increasing their rate is good.
Bonuses aren't great because programmers by and large realize that you're milking them for production, rather than recognizing their value.
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
add a comment |Â
up vote
13
down vote
up vote
13
down vote
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks.
The only place I've seen this be good is getting hazard pay for being on-call. Nobody wants to do that, and it's not motivation at that point but overtime compensation.
Outside of that, if a programmer is being valuable to the company by doing things that others can't, or is innovating solutions for business then they deserve regular compensation relative to that value. If they're below that rate, then increasing their rate is good.
Bonuses aren't great because programmers by and large realize that you're milking them for production, rather than recognizing their value.
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
I was wondering if this conclusion extends on the cases when the management is ready to pay a little bit more for some "special" tasks.
The only place I've seen this be good is getting hazard pay for being on-call. Nobody wants to do that, and it's not motivation at that point but overtime compensation.
Outside of that, if a programmer is being valuable to the company by doing things that others can't, or is innovating solutions for business then they deserve regular compensation relative to that value. If they're below that rate, then increasing their rate is good.
Bonuses aren't great because programmers by and large realize that you're milking them for production, rather than recognizing their value.
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
answered Jul 30 '12 at 12:37
Telastyn
33.9k977120
33.9k977120
add a comment |Â
add a comment |Â
up vote
9
down vote
For a lot of people, building software has intrinsic value. That intrinsic motivation is more powerful than any financial motivation. In fact, if you try to combine intrinsic motivation with performance-based financial motivation, you'll actually reduce performance.
However, developers still need to eat. So, you need to offer a salary that's comparable to what they could get elsewhere (based on their experience), and other than that you need to separate the work from the financial reward.
I think that's similar to what you're saying, except I'm suggesting paying them for what they bring to the table, not for what you happen to be feeding them today.
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
add a comment |Â
up vote
9
down vote
For a lot of people, building software has intrinsic value. That intrinsic motivation is more powerful than any financial motivation. In fact, if you try to combine intrinsic motivation with performance-based financial motivation, you'll actually reduce performance.
However, developers still need to eat. So, you need to offer a salary that's comparable to what they could get elsewhere (based on their experience), and other than that you need to separate the work from the financial reward.
I think that's similar to what you're saying, except I'm suggesting paying them for what they bring to the table, not for what you happen to be feeding them today.
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
add a comment |Â
up vote
9
down vote
up vote
9
down vote
For a lot of people, building software has intrinsic value. That intrinsic motivation is more powerful than any financial motivation. In fact, if you try to combine intrinsic motivation with performance-based financial motivation, you'll actually reduce performance.
However, developers still need to eat. So, you need to offer a salary that's comparable to what they could get elsewhere (based on their experience), and other than that you need to separate the work from the financial reward.
I think that's similar to what you're saying, except I'm suggesting paying them for what they bring to the table, not for what you happen to be feeding them today.
For a lot of people, building software has intrinsic value. That intrinsic motivation is more powerful than any financial motivation. In fact, if you try to combine intrinsic motivation with performance-based financial motivation, you'll actually reduce performance.
However, developers still need to eat. So, you need to offer a salary that's comparable to what they could get elsewhere (based on their experience), and other than that you need to separate the work from the financial reward.
I think that's similar to what you're saying, except I'm suggesting paying them for what they bring to the table, not for what you happen to be feeding them today.
answered Jul 30 '12 at 12:37
Scott Whitlock
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
add a comment |Â
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
But in this case, lowering the salary can be more discouraging than motivating for better work. I must confess, I've felt that on my skin once.
– superM
Jul 30 '12 at 12:41
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
I misunderstood you, I guess. I thought by saying "paying them for what they bring to the table" you meant adding to their salary when they're working well, and lowering the salary after poor performance.
– superM
Jul 30 '12 at 12:48
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
Got it. Thanks ))
– superM
Jul 30 '12 at 13:36
add a comment |Â
up vote
4
down vote
Premise
A professional is paid for what they do.
Natural consequences follow if that relationship is broken by companies or professionals.
The Mismatch of Bonuses and Research and Development
Bonuses in some companies are a lever to promote compliant and motivated behavior toward requested results. For sales, it is an article of faith that if you sell more, you earn more, and that using commission aligns the salesman's goals with the company goals. Executives are often rewarded with stock options that fluctuate proportional to the top goal the board of directors has set for them which is to increase stock holder value.
Product development and the remainder of the company sometimes share a third bonus methodology. The idea is to reward against a benchmark for profit. No profit, no bonus. Profit above the benchmark, bonuses for everyone. Desired behavior includes good teamwork, widespread ownership of being thrifty with company resources, alignment of worker goals with the goals of the chain of command, and industrious focused contributions by each person each day. These are great goals, even without a bonus system in place because they help the company survive and give employees better job security and opportunity.
What about a development team that labors three years to bring out a successful product? Value is created the entire time, but costs of a big project might hit the company bottom-line hard, resulting in no bonus. Sometimes, the directors give some of the executives the boot about this time, and it is no picnic for development managers or foot soldiers.
Let's say Q1 of the fourth year, the product releases and is wildly successful.
- The sales staff makes record commissions in the same month. Their reward is almost immediate.
- The market may lag a few months, but when Q1 sales are announced, the stock jumps, the executives sell shares, some after not much involvement. Their reward is not immediate, but may be pretty efficient WRT when the market identifies accomplishment.
- What about manufacturing employees? They get some overtime, and in Q2 of year five, the company wide bonus for year four will be paid. They wait about 12 months for their work to bring a bonus.
In contrast, for the R & D staff, no bonus is paid on their three years work unless they stay at their jobs until Q2 of the fifth year. It is not sinister, or part of an evil plot. It just works out that way. For people in our profession, this is mild compared to what happens with start ups and stock options. If there is a bonus for developers at time of launch, at least for those who worked on the project a while, it is probably well deserved.
Some Suggestions
The moral of the story?
- Revenue lags R & D expense, so we would need much shorter cycles in R & D to permit the annual bonus model to more fairly reward the involved rather than the uninvolved. Agile, iterative, incremental approaches give us some relief from the problem if we can put product into customers hands earlier and see profit hit the bottom line while our effort is still remembered.
- It is difficult and potentially harmful to reward someone for a project that is not complete. But we probably do need some recognition and reward for milestones and hard to measure things like focused and methodical effort toward a goal.
- Patents are a prime example of a huge lag between contribution and reward. It is very hard to value a patent at its time of filing, but it may take years if the reward is tied to the time it is granted.
- Knowledge workers like software developers can have a huge impact on the success of their companies. The reality of high turnover among developers makes stock options an interesting instrument. It can induce some to stay, but insures their reward cycle is separated from their contribution cycle. It also means that up and down cycles in staffing may often separate developers from their reward. Shorter vesting times or simply a shared expectation of pay-as-you-go salaries in which extraordinary work is compensated with overtime without the distraction of bonus talk.
answered Aug 18 '12 at 20:37
DeveloperDon
1413
add a comment |Â
up vote
4
down vote
Premise
A professional is paid for what they do.
Natural consequences follow if that relationship is broken by companies or professionals.
The Mismatch of Bonuses and Research and Development
Bonuses in some companies are a lever to promote compliant and motivated behavior toward requested results. For sales, it is an article of faith that if you sell more, you earn more, and that using commission aligns the salesman's goals with the company goals. Executives are often rewarded with stock options that fluctuate proportional to the top goal the board of directors has set for them which is to increase stock holder value.
Product development and the remainder of the company sometimes share a third bonus methodology. The idea is to reward against a benchmark for profit. No profit, no bonus. Profit above the benchmark, bonuses for everyone. Desired behavior includes good teamwork, widespread ownership of being thrifty with company resources, alignment of worker goals with the goals of the chain of command, and industrious focused contributions by each person each day. These are great goals, even without a bonus system in place because they help the company survive and give employees better job security and opportunity.
What about a development team that labors three years to bring out a successful product? Value is created the entire time, but costs of a big project might hit the company bottom-line hard, resulting in no bonus. Sometimes, the directors give some of the executives the boot about this time, and it is no picnic for development managers or foot soldiers.
Let's say Q1 of the fourth year, the product releases and is wildly successful.
- The sales staff makes record commissions in the same month. Their reward is almost immediate.
- The market may lag a few months, but when Q1 sales are announced, the stock jumps, the executives sell shares, some after not much involvement. Their reward is not immediate, but may be pretty efficient WRT when the market identifies accomplishment.
- What about manufacturing employees? They get some overtime, and in Q2 of year five, the company wide bonus for year four will be paid. They wait about 12 months for their work to bring a bonus.
In contrast, for the R & D staff, no bonus is paid on their three years work unless they stay at their jobs until Q2 of the fifth year. It is not sinister, or part of an evil plot. It just works out that way. For people in our profession, this is mild compared to what happens with start ups and stock options. If there is a bonus for developers at time of launch, at least for those who worked on the project a while, it is probably well deserved.
Some Suggestions
The moral of the story?
- Revenue lags R & D expense, so we would need much shorter cycles in R & D to permit the annual bonus model to more fairly reward the involved rather than the uninvolved. Agile, iterative, incremental approaches give us some relief from the problem if we can put product into customers hands earlier and see profit hit the bottom line while our effort is still remembered.
- It is difficult and potentially harmful to reward someone for a project that is not complete. But we probably do need some recognition and reward for milestones and hard to measure things like focused and methodical effort toward a goal.
- Patents are a prime example of a huge lag between contribution and reward. It is very hard to value a patent at its time of filing, but it may take years if the reward is tied to the time it is granted.
- Knowledge workers like software developers can have a huge impact on the success of their companies. The reality of high turnover among developers makes stock options an interesting instrument. It can induce some to stay, but insures their reward cycle is separated from their contribution cycle. It also means that up and down cycles in staffing may often separate developers from their reward. Shorter vesting times or simply a shared expectation of pay-as-you-go salaries in which extraordinary work is compensated with overtime without the distraction of bonus talk.
answered Aug 18 '12 at 20:37
DeveloperDon
1413
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Premise
A professional is paid for what they do.
Natural consequences follow if that relationship is broken by companies or professionals.
The Mismatch of Bonuses and Research and Development
Bonuses in some companies are a lever to promote compliant and motivated behavior toward requested results. For sales, it is an article of faith that if you sell more, you earn more, and that using commission aligns the salesman's goals with the company goals. Executives are often rewarded with stock options that fluctuate proportional to the top goal the board of directors has set for them which is to increase stock holder value.
Product development and the remainder of the company sometimes share a third bonus methodology. The idea is to reward against a benchmark for profit. No profit, no bonus. Profit above the benchmark, bonuses for everyone. Desired behavior includes good teamwork, widespread ownership of being thrifty with company resources, alignment of worker goals with the goals of the chain of command, and industrious focused contributions by each person each day. These are great goals, even without a bonus system in place because they help the company survive and give employees better job security and opportunity.
What about a development team that labors three years to bring out a successful product? Value is created the entire time, but costs of a big project might hit the company bottom-line hard, resulting in no bonus. Sometimes, the directors give some of the executives the boot about this time, and it is no picnic for development managers or foot soldiers.
Let's say Q1 of the fourth year, the product releases and is wildly successful.
- The sales staff makes record commissions in the same month. Their reward is almost immediate.
- The market may lag a few months, but when Q1 sales are announced, the stock jumps, the executives sell shares, some after not much involvement. Their reward is not immediate, but may be pretty efficient WRT when the market identifies accomplishment.
- What about manufacturing employees? They get some overtime, and in Q2 of year five, the company wide bonus for year four will be paid. They wait about 12 months for their work to bring a bonus.
In contrast, for the R & D staff, no bonus is paid on their three years work unless they stay at their jobs until Q2 of the fifth year. It is not sinister, or part of an evil plot. It just works out that way. For people in our profession, this is mild compared to what happens with start ups and stock options. If there is a bonus for developers at time of launch, at least for those who worked on the project a while, it is probably well deserved.
Some Suggestions
The moral of the story?
- Revenue lags R & D expense, so we would need much shorter cycles in R & D to permit the annual bonus model to more fairly reward the involved rather than the uninvolved. Agile, iterative, incremental approaches give us some relief from the problem if we can put product into customers hands earlier and see profit hit the bottom line while our effort is still remembered.
- It is difficult and potentially harmful to reward someone for a project that is not complete. But we probably do need some recognition and reward for milestones and hard to measure things like focused and methodical effort toward a goal.
- Patents are a prime example of a huge lag between contribution and reward. It is very hard to value a patent at its time of filing, but it may take years if the reward is tied to the time it is granted.
- Knowledge workers like software developers can have a huge impact on the success of their companies. The reality of high turnover among developers makes stock options an interesting instrument. It can induce some to stay, but insures their reward cycle is separated from their contribution cycle. It also means that up and down cycles in staffing may often separate developers from their reward. Shorter vesting times or simply a shared expectation of pay-as-you-go salaries in which extraordinary work is compensated with overtime without the distraction of bonus talk.
answered Aug 18 '12 at 20:37
DeveloperDon
1413
Premise
A professional is paid for what they do.
Natural consequences follow if that relationship is broken by companies or professionals.
The Mismatch of Bonuses and Research and Development
Bonuses in some companies are a lever to promote compliant and motivated behavior toward requested results. For sales, it is an article of faith that if you sell more, you earn more, and that using commission aligns the salesman's goals with the company goals. Executives are often rewarded with stock options that fluctuate proportional to the top goal the board of directors has set for them which is to increase stock holder value.
Product development and the remainder of the company sometimes share a third bonus methodology. The idea is to reward against a benchmark for profit. No profit, no bonus. Profit above the benchmark, bonuses for everyone. Desired behavior includes good teamwork, widespread ownership of being thrifty with company resources, alignment of worker goals with the goals of the chain of command, and industrious focused contributions by each person each day. These are great goals, even without a bonus system in place because they help the company survive and give employees better job security and opportunity.
What about a development team that labors three years to bring out a successful product? Value is created the entire time, but costs of a big project might hit the company bottom-line hard, resulting in no bonus. Sometimes, the directors give some of the executives the boot about this time, and it is no picnic for development managers or foot soldiers.
Let's say Q1 of the fourth year, the product releases and is wildly successful.
- The sales staff makes record commissions in the same month. Their reward is almost immediate.
- The market may lag a few months, but when Q1 sales are announced, the stock jumps, the executives sell shares, some after not much involvement. Their reward is not immediate, but may be pretty efficient WRT when the market identifies accomplishment.
- What about manufacturing employees? They get some overtime, and in Q2 of year five, the company wide bonus for year four will be paid. They wait about 12 months for their work to bring a bonus.
In contrast, for the R & D staff, no bonus is paid on their three years work unless they stay at their jobs until Q2 of the fifth year. It is not sinister, or part of an evil plot. It just works out that way. For people in our profession, this is mild compared to what happens with start ups and stock options. If there is a bonus for developers at time of launch, at least for those who worked on the project a while, it is probably well deserved.
Some Suggestions
The moral of the story?
- Revenue lags R & D expense, so we would need much shorter cycles in R & D to permit the annual bonus model to more fairly reward the involved rather than the uninvolved. Agile, iterative, incremental approaches give us some relief from the problem if we can put product into customers hands earlier and see profit hit the bottom line while our effort is still remembered.
- It is difficult and potentially harmful to reward someone for a project that is not complete. But we probably do need some recognition and reward for milestones and hard to measure things like focused and methodical effort toward a goal.
- Patents are a prime example of a huge lag between contribution and reward. It is very hard to value a patent at its time of filing, but it may take years if the reward is tied to the time it is granted.
- Knowledge workers like software developers can have a huge impact on the success of their companies. The reality of high turnover among developers makes stock options an interesting instrument. It can induce some to stay, but insures their reward cycle is separated from their contribution cycle. It also means that up and down cycles in staffing may often separate developers from their reward. Shorter vesting times or simply a shared expectation of pay-as-you-go salaries in which extraordinary work is compensated with overtime without the distraction of bonus talk.
answered Aug 18 '12 at 20:37
DeveloperDon
1413
answered Aug 18 '12 at 20:37
DeveloperDon
1413
answered Aug 18 '12 at 20:37
DeveloperDon
1413
answered Aug 18 '12 at 20:37
DeveloperDon
1413
1413
add a comment |Â
add a comment |Â
up vote
0
down vote
Here are a few points on this subject that I'd like to make:
- The better programmers should make more money and be given more difficult tasks.
- Imagine holding a contest and award a prize for the first programmer to create a solution. Good luck with anyone spending time on anything else. Or watch everyone else give up because they know the better programmer is going to win anyway.
- When the company has a financial windfall as a result of the developer's contribution, they need to feel they share in the extra income. Otherwise, they'll feel exploited
- Beware of the everything is an emergency because nothing will be considered an emergency. It can't always be done, but strive to manage sustainable workloads.
- Do you really want to set a precident of every little bit of extra effort is going to require a bonus attached?
- Before you offer more money, find out if anything else will motivate your developers. You could probably save more money than you think.
add a comment |Â
up vote
0
down vote
Here are a few points on this subject that I'd like to make:
- The better programmers should make more money and be given more difficult tasks.
- Imagine holding a contest and award a prize for the first programmer to create a solution. Good luck with anyone spending time on anything else. Or watch everyone else give up because they know the better programmer is going to win anyway.
- When the company has a financial windfall as a result of the developer's contribution, they need to feel they share in the extra income. Otherwise, they'll feel exploited
- Beware of the everything is an emergency because nothing will be considered an emergency. It can't always be done, but strive to manage sustainable workloads.
- Do you really want to set a precident of every little bit of extra effort is going to require a bonus attached?
- Before you offer more money, find out if anything else will motivate your developers. You could probably save more money than you think.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Here are a few points on this subject that I'd like to make:
- The better programmers should make more money and be given more difficult tasks.
- Imagine holding a contest and award a prize for the first programmer to create a solution. Good luck with anyone spending time on anything else. Or watch everyone else give up because they know the better programmer is going to win anyway.
- When the company has a financial windfall as a result of the developer's contribution, they need to feel they share in the extra income. Otherwise, they'll feel exploited
- Beware of the everything is an emergency because nothing will be considered an emergency. It can't always be done, but strive to manage sustainable workloads.
- Do you really want to set a precident of every little bit of extra effort is going to require a bonus attached?
- Before you offer more money, find out if anything else will motivate your developers. You could probably save more money than you think.
Here are a few points on this subject that I'd like to make:
- The better programmers should make more money and be given more difficult tasks.
- Imagine holding a contest and award a prize for the first programmer to create a solution. Good luck with anyone spending time on anything else. Or watch everyone else give up because they know the better programmer is going to win anyway.
- When the company has a financial windfall as a result of the developer's contribution, they need to feel they share in the extra income. Otherwise, they'll feel exploited
- Beware of the everything is an emergency because nothing will be considered an emergency. It can't always be done, but strive to manage sustainable workloads.
- Do you really want to set a precident of every little bit of extra effort is going to require a bonus attached?
- Before you offer more money, find out if anything else will motivate your developers. You could probably save more money than you think.
answered Aug 20 '12 at 18:39
user8365
add a comment |Â
add a comment |Â
up vote
0
down vote
Joel wrote another article addressing this question more directly.
In this case an intern came up with an idea that, once implemented, made $1 million for the company. What should be his reward?
He ended up rewarding him with equity in the company, which he was pleased with, but was utlimately not enough to retain him. We discussed this a bit on the gone but lamented Joel on Software forum.
--
In short, hopefully your company is building a culture where people enjoy contributing to what is going on. There is always some drudgery, but in general the rewards should be aligned with skill level and results and wants the team to be successful.
So I would say tread carefully.
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
add a comment |Â
up vote
0
down vote
Joel wrote another article addressing this question more directly.
In this case an intern came up with an idea that, once implemented, made $1 million for the company. What should be his reward?
He ended up rewarding him with equity in the company, which he was pleased with, but was utlimately not enough to retain him. We discussed this a bit on the gone but lamented Joel on Software forum.
--
In short, hopefully your company is building a culture where people enjoy contributing to what is going on. There is always some drudgery, but in general the rewards should be aligned with skill level and results and wants the team to be successful.
So I would say tread carefully.
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Joel wrote another article addressing this question more directly.
In this case an intern came up with an idea that, once implemented, made $1 million for the company. What should be his reward?
He ended up rewarding him with equity in the company, which he was pleased with, but was utlimately not enough to retain him. We discussed this a bit on the gone but lamented Joel on Software forum.
--
In short, hopefully your company is building a culture where people enjoy contributing to what is going on. There is always some drudgery, but in general the rewards should be aligned with skill level and results and wants the team to be successful.
So I would say tread carefully.
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
Joel wrote another article addressing this question more directly.
In this case an intern came up with an idea that, once implemented, made $1 million for the company. What should be his reward?
He ended up rewarding him with equity in the company, which he was pleased with, but was utlimately not enough to retain him. We discussed this a bit on the gone but lamented Joel on Software forum.
--
In short, hopefully your company is building a culture where people enjoy contributing to what is going on. There is always some drudgery, but in general the rewards should be aligned with skill level and results and wants the team to be successful.
So I would say tread carefully.
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
answered Aug 20 '12 at 19:22
JohnMcG
1,8561818
1,8561818
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f2915%2fmanagement-tactics-and-bonus-programs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
8
Bonuses are a cheat. By paying you less, you have a smaller salary when you get promoted or move to some other company. They may arbitrarily reduce your compensation by turning the bonus off one year. And most importantly, they affect the overall value of your retirement.
– HLGEM
Jul 30 '12 at 15:05
2
As an aside, the mention of The Econ 101 book reminded me of one of Scott Adams' books. Specifically of one anectdote he brought up, where the company he was with wished to reduce bugs in code, and thus began offering a bounty for each bug that was discovered, reported, and stopped. They had to shut the program down very quickly, after a handful of 'bug cabals' formed among the developers, which then started trading buggy code and intentionally making mistakes to be found later. unrelated, just entertaining.
– acolyte
Jul 30 '12 at 16:10
@acolyte, this is very related: it illustrates what the article says. Only in this case the harm is more obvious!
– superM
Jul 30 '12 at 16:22
1
I think a bonus program would make me very effective in meeting the bare minimum required to get the bonus...
– IDrinkandIKnowThings
Jul 30 '12 at 17:38
@acolyte - I seem to remember that series of comics, they were paying bonuses for finding and fixing bugs. Someone asked Wally where he was going and he said "I'm going to write me a new boat".
– Dunk
Aug 1 '12 at 19:05