The end of the year is approaching and with it one of your most important tasks as a manager. Summarizing the performance of 10, 20 or 50 developers over the past 12 months, offering personalized recommendations, and having the facts to back them up - is no small task.
We believe that the only fair, accurate and insightful way to understand how your developers are working, progressing and - last but certainly not least - how they feel, is with the data. Data can provide more objective information about employee activity than could ever be gathered by a human.
It is still very difficult for many managers to fully understand that all employees work at different rates and levels.
Consider this: More than two-thirds of employees say they would put more effort into their job if they felt more appreciated, and 90% want a manager who is fair to all employees.
Let's tell the truth. It is difficult to judge all of your employees fairly if (1) you are unable to physically work side-by-side with them, which means that you will inevitably have more contact with some than others (e.g., the ones you are friendlier with) ; and (2) you rely on manual trackers to keep up with everyone's work, which can get lost and take a lot of processing and analysis effort; (3) you expect engineers to independently report their progress, which is far from objective.
It's also unlikely, especially with quieter ones, that on top of all that you've identified areas in which to expand their talents by upgrading or retraining. But it's that kind of personal attention that will make employees feel valued and able to progress professionally with you. If not, they are likely to seize the next best job opportunity that comes up.
So here's a summary of why you need data to set up a fair annual review process; if not this year, you can start it for 2021.
1. Use the data to set next year's goals
The best way to automatically track your developers' progress is to use Git Analytics tools, which track people's performance by aggregating historical Git data and then returning that information to managers in minute detail.
This data will clearly show you whether one of your engineers is over or under capacity and the types of projects they excel at. If you are evaluating a technical manager and the team members they are responsible for have taken longer to submit their code to the shared repository, causing an accumulation of activities, it could mean that they are not delegating tasks properly. An appropriate goal in this case would be to monitor and divide the responsibilities of your team more efficiently, which can be monitored using the same metrics or by training members of other teams to assist with their tasks.
Another example is that of an engineer who is dedicating himself to multiple projects. Indicators of where they performed best include dropping out (we'll get to that later), colleagues repeatedly asking the same employee to assist them in new tasks, and of course positive feedback for senior staff, which can be easily integrated into tools of Git analytics. These are clear signs that next year your engineer may be maximizing his talents in these alternative areas and you may be diversifying his duties accordingly.
Once you know which goals to set, you can use the analytics tools to create automatic goals for each engineer. This means that once you set it up, it will regularly update on the progress of the engineer using indicators directly from the code repository. It won't require time-consuming input from you or your employee, allowing both of you to focus on more important tasks. As a manager you will receive full reports once the task deadline is reached and you will be notified whenever the metrics start to decline or the goal is met.
This is important: you will be able to maintain these goals on your own, without having to delegate that responsibility or depend on self-reporting by the engineer. It will keep employee monitoring honest and transparent.
2. Three Git metrics can help you understand true quality of performance
The easiest way for managers to "conclude" how an engineer behaved is to look at the superficial output: the number of completed pull requests sent per week, the number of commits per day, etc. Especially for non-technical managers, this is a serious but common mistake. When something is done, it doesn't mean that it has been done well or that it is even productive or usable.
Instead, look at these data points to determine the actual quality of your engineer's work:
- Churn rate is your number one red flag, telling you how many times someone changed their code in the first 21 days after check-in. The more neglect, the less an engineer's code is actually productive, with good longevity. The dropout rate is a natural and healthy part of the software development process, but we've identified that any dropout level above the normal 15-30% indicates that an engineer is struggling with assignments.
