I’ve never been a big fan of annual performance reviews. Frankly, I think they ought to be utterly unnecessary. No one enjoys the process. I’m at a loss why a company would spend all those person-hours on a process that no one really wants.
Any competent manager should be meeting regularly with all of her direct reports, and should make sure that each employee knows clearly where they stand and how they are performing. Continuous and timely feedback is vastly superior to annual reviews. If a manager provides continuous and timely feedback, then the performance review process should be a complete waste of time.
Companies should foster a culture in which the standing and progress of every employee are transparent, making performance reviews an unnecessary exercise in redundancy. Managers who have direct reports who are not totally clear about where they stand should themselves be told that they are not performing up to snuff.
My skepticism of performance reviews goes double for software developers.
Metrics miss the meaning
Performance reviews that rely on individual developer metrics are particularly pernicious. Current management fads insist that quantifiable metrics are critical for the success of an organization, and sadly, this approach has creeped into the evaluation of software developers.
The essence of great software development—creativity, problem solving, innovation—is inherently resistant to quantification. Stressing metrics will often encourage gamesmanship, leading developers to prioritize moving (often arbitrary) needles over meaningful contributions to project and company objectives.
Moreover, software development is commonly called a “team sport.” Assessing individual contributions in isolation can breed unhealthy competition, undermine teamwork, and incentivize behavior that, while technically hitting the mark, can be detrimental to good coding and good software. The pressure of performance evaluations can deter developers from innovative pursuits, pushing them towards safer paths.
And developers shouldn’t be steering towards safer paths. The development environment is rapidly changing, and developers should be encouraged to experiment, try new things, and seek out innovative solutions. Worrying about hitting specific metrics squelches the impulse to try something new.
Finally, a one-size-fits-all approach to performance reviews doesn’t take into account the unique nature of software development. Using the same system to evaluate developers and members of the marketing team won’t capture the unique skills found among developers. Some software developers thrive fixing bugs. Others love writing greenfield code. Some are fast but less accurate. Others are slower but highly accurate. Trying to quantify these different skills in a standard performance evaluation misses the nuances that make different developers great for different reasons.
A better kind of performance review
Now, I anticipate the HR professionals among us might be recoiling. While I’m not versed in legal matters, it’s been my observation that the historical reliance on performance reviews for justifying personnel decisions is unfounded. If the need arises to send a poor performer packing, this should be addressed through a clearly documented performance improvement plan (PIP), followed by decisive action if necessary.
Often a company will insist on having some form of a review. If you must implement a performance review system, I’d recommend something like the following.
Divide all employees into three broad tiers. The vast majority of them should be told, “You are doing great, keep up the good work.” The second group—and there need not be anyone in this group—should be put on a PIP and worked with to improve. Anyone left over should be, well, sent on their way.
I like this system because it is a thin veneer over what ought to be happening anyway. If you are doing a good job, you should know it and be told so frequently by your manager. If your performance falls short, you should know that and be told so by your manager. And you should be told right away, not just at performance review time. The whole thing can be done on a single sheet of paper, and might include highlights of yearly accomplishments and a few clear goals for the coming year.
But again, only if you absolutely have to do performance reviews.
Ultimately, keeping workers happy and productive requires a culture of trust, openness, and honesty. Developers who feel trusted to do good work and who are frequently told that they are doing good work will do good work. A good culture will make things like annual performance reviews completely unnecessary. Performance reviews add nothing to this excellent approach.