Performance reviews
To create an honest review do not harvest unimportant numbers.
I’ve been reading many articles on how to make proper performance reviews. Many of them are trying to get numbers to validate team member accomplishments. For example, the number of “thank you’ or ‘awesome” words in emails. Or number of written articles. I think numbers are important but I don’t think this is a good way to measure people’s performance.
What will happen when you bring a number of articles to a performance review meeting? People start writing more articles probably with less quality. Is it better for your company? Does it increase the important KPI?
Number of tickets closed? People will get creative opening tickets, or optimize for the easy-to-fix ones. Number of commits per day? It will lead to small and frequent commits. Is this what you want? Is this important for company or project success?
Sum real numbers
To create an honest review do not harvest unimportant numbers. Sum up what members have done since the last review meeting. What features? Name them. How did it increase the most important company kpi? Or other kpi?
Other members’ opinions
We are always working as a team. It’s not good to be alone. Ask other team members what they think about reviewing team member. Maybe there are deep toxic conflicts. Are they deeper and deeper? Or getting better? Maybe the team member realized that he didn’t need to fight with other members.
Don’t forget that team is always over individuals. Overall team performance is the next big topic. You can have great members but the team is not playing well.
Learning
Did team members learn something new? What exactly? Most valuable developers are changing technology and learning a lot. This is true value for every company. Especially for the software houses. On the other hand it’s not a good idea to push people to the limits. Everybody has mental and physical limitations and it’s necessary to understand where those limits are.
Expectations
What expectation do you have from a senior developer? Deliver end-to-end solutions? Writing articles? Planning, estimating, budgeting? Do they have deep competencies? What do you expect from juniors? What are expectations against senior dev? It’s really necessary to set up rules and follow them.
Compare team member with himself
I am not advocating comparing developer with other members. You can do that but not during performance review. For example you can choose the project owner leader based on team members skills. Performance review is mostly about how well team member do on projects. How valuable is it for the team.
