Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
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.
Agile Development: A Manager's Roadmap for Success
Give-away eBook – Confessions of an IT Manager
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?
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
16 comments
Watch Thread Reply