Performance Reviews – part II.

Doing performance reviews are expensive, in both time and opportunity cost. So if you are going to do them, remember that the most important factor in designing a performance review system is to understand the objective you are trying to accomplish. If it is to rank employees 1 to n, then you will need some form of rating system. But that is a crappy goal, and I wonder why companies feel it necessary to do so. It doesn't improve the product, and doesn't make developers more efficient or more productive.

If the objective is to drive specific behaviors that is simple enough to do. Ratings based on easily measured objectives (uch as focusing on bug fixing) will ensure that those metrics are met, most of the time regardless of the cost/benefit to the organization. And if the annual reviews set up competing metrics (QA rated on how many bugs, developers rated on how few bugs) then progress will grind to a halt as teamwork goes right out the window in this zero-sum game.

If the objective is to help people grow in their careers (and this *should* be the objective), then the reviews should not be annual, but much more frequent, quarterly at a minimum. Annual reviews tend to focus more heavily on the most recent quarter, as that is what is freshest in the minds of both the manager and the developer. If you are going to have quarterly reviews then they have to be lightweight. Don't use ratings, but rather focus the review on strengths and weakness, and how those fit into the company's strategic plan, and the developer's personal career plan. Make sure the developer is aware how they are progressing, and knows on which areas to concentrate. Using SMART objectives can be effective here, but they have to be focused enough to be of value. Long term macro objectives (n dollars in gross sales) are not effective at the team level. Individual level Objectives that are SMART and Annual and relevant are a myth. Quarterly objectives are short enough time frame to allow for adjustment to market/company directions without causing the developer to rebel (I am not meeting the annual objective, therefore my bonus is in peril, and I won't be able to afford that family vacation I have been promising the spouse).

Finally, be consistent in the review data. Do not have a quarterly review for results mixed with an annual peer review, mixed with a semi-annual daily behaviors review. Consistency will help drive the message (whatever that message you want to deliver as a manager) more effectively. Have the same information available for each review. If you want to do peer reviews as part of the process, then have them at every review. If the data are not important enough to review quarterly, the do not include that data.