Tracking change and innovation in the enterprise software development community
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Posted by Vikas Hazrati on Mar 24, 2008 07:25 AM
In an interesting discussion started by Sam Bayer on Lean Development group, members discussed on the best way to distribute bonus.The other key question is how to we allow teams to recognize the leaders within their midst, like the QA person who steps up to really cross-train everyone on testing and the QA tools, or the developer that is really disciplined about automation and is frequently improving the productivity of the whole?Adrian Howard suggested that measuring individual performance to distribute bonus is counter-productive in many cases and should be avoided. It becomes a major reason of conflict between team members and could quickly collapse a well oiled team. According to him, once the distribution is based on individual performance then people tend to put their own goals over the team goals.
There are 2 schools of thought, one says everyone gets X% of their salary as a bonus, the other is that there are $X to distribute throughout the team and you spread it out evenly.However, this solution did not seem to convince many members of the group. Some suggested that if the bonus is equally distributed then the people who are putting more effort than others are bound to be demotivated, you cannot afford to demotivate high performers by even distribution. On the other hand, if it is a percent of the salary then the people who are already getting more would get even more. For example assume A gets 100K salary and B gets 50K. Now if the bonus is say 5% then A would get 5K and B 2.5K
Mike Cohn talks about a case where a team was given a LARGE bonus and told to decide how to split it among themselves. They attempted to come to an agreement on how to share the money, but this created huge and irreconcilable conflict in the team. Eventually all they could decide to do was split it equally, even though many though this was very unfair. Asking the team to decide how to split the bonus created so much conflict that most members wish there had never been a bonus in the first place.The group did not seem able to agree on a the best possible way to distribute bonus. For some teams a certain way of distribution made sense which was a complete chaos for other teams. The group however seemed to agree on the point that distribution of bonus to an Agile team is like playing with dynamite.
IBM Web 2.0 Developer eKit: Free Tutorials, Webcasts, Whitepapers
Software Quality Survival Guide
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
The Agile Business Analyst: Skills and Techniques needed for Agile
What a fascinating experiment this would make, if you could afford to take the chance of destroying a team. Let's play a game. Assume you have a team in which: a. All members have absolutely equal skills b. All members work on tasks that provide equal business value c. All members work exactly the same hours Even in this mythical situation, I strongly suspect that you would have some team members claiming they contributed more than the others. I suspect it so strongly I'd be willing to wager my next bonus on it. Given this, the task of trying to find an "equitable" distribution of bonus money seems impossible. You are bound to piss someone off.
Given this, the task of trying to find an "equitable" distribution of bonus money seems impossible. You are bound to piss someone off.
Bruce I think you are correct. It seems that it is huge challenge to distribute bonus without frustrating some members of the team. I have seen this challenge personally on the teams that I worked with. I am wondering if some of us have got a chance to work on teams where distributing bonus was a pleasure :)
The notion of splitting bonuses evenly as a matter of ideal is misguided at best. I'm not against it when the entire team (such as my current one) is pulling a fairly even amount of weight (even as much as 20% variation here). Heck, even if they're all TRYING to pull the same amount of weight, it would be ok, but I'm totally opposed to casting this in stone as the "right way". Bonuses should be bonuses and if some folks pulled a lot more weight than others, they should be rewarded appropriately. Otherwise, you're just walking in saying "please be average". This is the same kind of stupid reasoning that leads people to sue schools for having honor roll programs that "insult" their kids because their kids don't make the honor roll. BTW, a straight percentage of salary is a lot more even and fair than most bonus structures in the corporate world. Many companies use a structure where the higher level you are, the higher the percentage as well.
We're actually experimenting with this a bit.
A project has X points. So the team can earn that.
However each teammember must give points (on a specified list of tasks) to the other teammembers (help, effort, ...) and this is used as a coefficient to calculate the real points a teammember will earn.
teammember A: X * coefficientA -> Z points
teammember B: X * coefficientB -> Y points
...
Yes, I'm afraid I don't understand the point about higher paid people will receive higher bonuses. Presumably people are higher paid because they make a greater contribution and have greater responsibilities.
If that's not true you have bigger problems than just splitting bonuses.
P.S. What's going on with the message formatting?
Hi Bruce > P.S. What's going on with the message formatting? Yeah, we've noticed some people's posts are getting a lot of blank lines at the end, suddenly. Please send me any intelligence you gather on that! :-)
I think we found quite good solution. Each employee gives on paper an estimation of contribution of all employees (in % that all sum to 100%). Then for each employee we calculated average of his contribution taking what all proposed. It still sums up to 100% and I think is quite fair.
That sounds good but do you ever get into a situation where some people are frustrated and they think that everyone else is conspiring against them by giving them lower contribution percentages.
That sounds good but do you ever get into a situation where some people are frustrated and they think that everyone else is conspiring against them by giving them lower contribution percentages.
I don't think such people are good team players. If they are, and are generally disliked by others, they should think about why this happens. If others feel themselves uncomfortable with such people, then bonus reduction is just a fair compensation for others, for spending their nerves while working with them.
One thing that this may miss (and you can miss this any way you do it) is the quiet person who out contributes everyone else. It also assumes everyone "plays fair". If you have some people conspiring together, they can game the system to allocate more bonus to a smaller segment. The "non-good" team players may also play their game in such a way that they ostracize the good team players as part of their survive and get ahead strategy. You need to do something more elegant than simply averaging to be sure. This is why we still need effective leaders and managers, although I emphasize the EFFECTIVE part of that...
The problem with doing anything besides splitting the bonus equally is that there is no objective way to apportion the bonus. There is simply no way to take an end result and determine any individual's contribution to the result. For those who would like further information, I would recommend reading Dr. W. E. Deming, "Out of the Crisis" or "The New Economics".
If the product is selling, then the sales team is doing something right. If customer retention is high, then the development team and the professional services people are doing something right. Why shouldn't everybody be paid based on an objective measure such as revenue rather than a subjective measure of individual or team performance? Trying to evaluate individual performance has always seemed futile to me.
I might be inclined to try something whereby some portion (50% or more, probably) is split equally, and the remainder is allocated through a quiet team-based mechanism where each team member has 100 pts they have to allocate to the team (not including themselves) as they see fit. Points are tabulated by an independent third party and bonuses allocated without sharing the results. It's often surprising how incentives end up pulling people in the wrong direction, but that incentive simply ensures that the team's own perception of value is partially mirrored in bonus distribution. It doesn't seem too dangerous, but, well, I'd have to try it and see what happens.
I believe the problem isn't itself the bonus that is being given to the employees. The problems is the creation of a incentive system which gives rewards based on individual performances.
What you get from that? Great individuals, but not a great team.
The best solution ,in my opinion, is to have a clear criteria about the bonus amount, and especially to reward everybody based on the team performance.
Cheers,
Francisco
http://franktrindade.wordpress.com
If the bonus is sufficient to motivate you to work hard - why would the junior developer care that the chief architect got $10k and he only got $1k in bonus. A % based bonus is almost always going to incentivize someone. Someone making $100k is not going to be motivated by a $1k bonus, but someone making $20k would work extra hard for it... Also - since when do people on the teams know the exact salaries of every other team member? A % based bonus structure is a good solution because everyone can be equally happy about it. Sure - those who have more will get more... but that's because they DO more (hence their higher salaries...) (of course, if you have any devs you are paying only $20k to, you probably aren't going to be distributing the bonuses in USD and will have to factor in currency exchange in the equation ;) )
The Bonus in many places is seperate from a performance incentive. Often in a Team there are people in different Salary / Position bands. These bands have their equal conterparts in every team. Hence if its something like an annual bonus thats being distributed would it be better from all perspectives if it is distributed evenly across bands and not evenly among the entire team / product vertical. If you make the distribution the Percentage of the Cost to Company - there will be differences (even if minute) due to the amount granted which in turn will cause the human ego / comparison related issues. This hampers team performance and team work - which is a bigger loss. However the salary/position bands are decided taking into account a persons effect on /value to the organisation, skill, experience and previous performance. Hence by distributing Bonuses on par with bands would it be better?
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
16 comments
Reply