Tracking change and innovation in the enterprise software development community
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Mark Levison on Oct 30, 2008 02:01 PM
In the Wall Street Journal Sam Culbert, author and professor of management at UCLA, argues that annual performance and pay reviews are at best dysfunctional. He sees their primary purpose as "intimidation aimed at preserving the boss's authority and power advantage".
Sam gives a number of reasons that performance reviews have this effect:
Related to the problem of objectivity Linda Rising, author of Fearless Change Patterns, notes that people will categorize or stereotype others in a very short period of time. "In many cases, a supervisor “determines” the ability of a worker in about three weeks, labeling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."
There are a number of different solutions proposed. Jeff Sutherland (with more detail from Christophe Louvion), co-creator of Scrum, provides five areas of contribution to measure individual team members: Product Delivery, Process Improvement, Organizational Flexibility, Group Learning and Product. For Managers: Organizational Flexibility and Product are replaced by Team building and Enterprise Collaboration. Jeff uses a scale from 1-10, gathering feedback from both the Manager and team mates (averaged). There are two key differences between this and traditional approaches: for ratings outside the range of 4-6 the manager must provide evidence in writing supporting the claim and if the rating from the manager and team differ the higher rating wins. Finally the manager and employee collaborate to determine career goals that the person is passionate about. Jeff recommends conducting reviews on a quarterly basis.
Sam recommends a different approach, he calls them performance previews. He suggests that managers and their employees be held jointly accountable for their results (and their quality). With previews the manager will be focused on what needs to happen in the future. The format: "Bosses should be asking all the questions that occur to them in inquiring about how a subordinate thinks he or she can best perform the job. Then, after they have exhausted their questions, they should ask the subordinate for what else they need to know." Finally Sam says that these previews should happen whenever the employee and manager don't think they're working well together.
Mary Poppendieck's advice is to abandon schemes based on individual measurement and compensation. Instead she offers:
- tell people directly what’s important and why. it is cheaper and easier than financial incentive systems signaling what is important
- base pay differentials on job complexity, avoid individual performance bonuses because they extinguish collaboration
- base collective rewards on broad measures — the larger the group that is measured, the more reliably performance can be accessed. Use profit sharing schemes instead of bonuses to tie people to the organisation goals.
- keep in mind the norm of reciprocity — if people feel that they are being treated generously, they will reciprocate it with increased discretionary effort.
Finally Esther Derby just recommends having a conversation, discussing how the quarter/year has gone.
Real-World SOA: Definition, Implementation and Use of SOA with CentraSite
Ensuring SOA success with effective, automated control throughout the lifecycle
Enable and Enforce SOA Policies with CentraSite and iTKO LISA
SOA Governance: Rule your SOA Whitepaper
The Key to SOA Governance: Understanding the Essence of Business
I see Jeff's solution as an improvement of a fundamentally broken practice. Jeff does nothing to address the lack of objectiveness in the process.
In my opinion, anyway.
<p>
How much MORE damage can you do to someone than to say: "4 stars, top performer, wish I had more like you. Oh, btw, here's your 3% raise. Keep up the good work."
<p>
The fact that many companies can do this with a straight face says a lot.
</p></p>
I attended Poppendieck's session on this topic at Agile 2008, and my take-away was that performance reviews as a once or twice a year process are a failure (in line with the other sources in this article).
BUT, the true intention of a performance review if separated from compensation and done monthly or more frequently can be a good thing.
I think Poppendieck's session slides are on the Agile 2008 site.
Kevin E. Schlabach
agile-commentary.blogspot.com/
correction, they are on the Poppendieck site:
www.poppendieck.com/pdfs/The%20Elephant%20in%20...
The link to my post on dumping the performance review and having a conversation seems to be broken. Try this: www.estherderby.com/weblog/archive/2004_11_01_a...
I had a long talk with the practice director for HR/Compensation at a national consulting firm recently. One of the things I found most interesting was her perception that many companies install elaborate performance management /appraisal systems to "force" managers to give feedback.
My observation is that many manager don't know how to give feedback. So it seems to me it would be more effective to teach manager how to give useful feedback--close to the event--and help people improve or move to a another place where they can be successful.
A couple of other related articles here: www.ayeconference.com/should-a-scrummaster-give... and here: www.scrumalliance.org/articles/50-performance-w....
Here's a related post following Mary's talk at the agile Bazaar in january: runningagile.com/2008/02/02/of-rewards-and-teams/
Esther - thanks for the correction. That was the item I'd intended to link to in the first place.
It also interesting (and sad) to read how HR justifies the practice in the first place.
Charles Nutter discusses bringing JRuby to the JVM, why Ruby is hard to implement, JIT compilation, precompilation, core Ruby implementation, Java library access, library challenges and future plans.
Alois Reitbauer specifies several architectural anti-patterns that one should stay away from and which can downgrade an application’s performance.
Teams in large organizations still struggle to adopt TDD. In this article Mark Levison shares problems he uncovered when he surveyed teams, and his own strategy to introduce TDD into an organization.
In this talk from RubyFringe, Luke Francl asks: is developer-driven testing really the best way to find software defects? Or is the emphasis on testing and test coverage barking up the wrong tree?
John Pampuch discusses the HotSpot compiler, the history of Java performance, HotSpot development philosophies and challenges, optimization, JVM library improvements, and tips for better performance.
In this interview, Keith Braithwaite, an Agile developer, consultant and trainer, says that we should show a good deal of skepticism towards today’s Agile practice.
This article demonstrates how to build and orchestrate highly configurable and extensible yet light-weight embedded process flow using AOP techniques with Spring AOP and Aspect J.
Jeff Patton explains why one needs to embrace uncertainty in order to succeed with his/her Agile project and how to avoid some of the common mistakes leading to project failure.
7 comments
Reply