The end of the year is looming 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 advice and having the facts to back it up — is no small task.
We believe that the only unbiased, accurate and insightful way to understand how your developers are working, progressing and — last but definitely not least — how they’re feeling, is with data. Data can provide more objective insights into employee activity than could ever be gathered by a human.
It’s still very hard for many managers to fully understand that all employees work at different paces and levels.
Consider this: Over two-thirds of employees say they would put more effort into their work if they felt more appreciated, and 90% want a manager who’s fair to all employees.
Let’s be honest. It’s hard to judge all of your employees fairly if you’re (1) unable to work physically side-by-side with them, meaning you’ll inevitably have more contact with the some over others (e.g., those you’re more friendly with); and (2) you’re relying on manual trackers to keep on top of everyone’s work, which can get lost and take a lot of effort to process and analyze; (3) you expect engineers to self-report their progress, which is far from objective.
It’s also unlikely, especially with the quieter ones, that on top of all that you’ll have identified areas for them to expand their talents by upskilling or reskilling. But it’s that kind of personal attention that will make employees feel appreciated and able to progress professionally with you. Absent that, they’re likely to take the next best job opportunity that shows up.
So here’s a run down of why you need data to set up a fair annual review process; if not this year, then you can kick-start it for 2021.
1. Use data to set next year’s goals
The best way to track your developers’ progress automatically is by using Git Analytics tools, which track the performance of individuals by aggregating historical Git data and then feeding that information back to managers in minute detail.
This data will clearly show you if one of your engineers is over capacity or underworked and the types of projects they excel in. If you’re assessing an engineering manager and the team members they’re responsible for have been taking longer to push their code to the shared repository, causing a backlog of tasks, it may mean that they’re not delegating tasks properly. An appropriate goal here would be to track and divide their team’s responsibilities more efficiently, which can be tracked using the same metrics, or cross-training members of other teams to assist with their tasks.
Another example is that of an engineer who is dipping their toe into multiple projects. Indicators of where they’ve performed best include churn (we’ll get to that later), coworkers repeatedly asking that same employee to assist them in new tasks and of course positive feedback for senior staff, which can easily be integrated into Git analytics tools. These are clear signs that next year, your engineer could be maximizing their talents in these alternative areas, and you could diversify their tasks accordingly.
Once you know what targets to set, you can use analytics tools to create automatic targets for each engineer. That means that after you’ve set it up, it will be updated regularly on the engineer’s progress using indicators directly from the code repository. It won’t need time-consuming input from either you or your employee, allowing you both to focus on more important tasks. As a manager you’ll receive full reports once the deadline of the task is reached and get notified whenever metrics start dropping or the goal has been met.
This is important — you’ll be able to keep on top of those goals yourself, 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 performance quality
The easiest way for managers to “conclude” how an engineer has performed is by looking at superficial output: the number of completed pull requests submitted per week, the number of commits per day, etc. Especially for nontechnical managers, this is a grave but common error. When something is done, it doesn’t mean it’s 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 is your number-one red flag, telling you how many times someone has modified their code in the first 21 days after it has been checked in. The more churn, the less of an engineer’s code is actually productive, with good longevity. Churn is a natural and healthy part of the software development process, but we’ve identified that any churn level above the normal 15%-30% indicates that an engineer is struggling with assignments.
Comments
Post a Comment