Table of contents:
- Key problems of developer productivity metrics
- Step-by-step guide for implementing productivity measurement tools
- How to start?
- Key ideas
Lots of engineering managers experience difficulties when it comes to evaluating developer performance. The main questions are:
- How to measure software developer productivity?
- What software developer productivity metrics should I use?
- How to secure developers' buy-in?
Before we turn to a review of the main metrics of calculating coder productivity and the step-by-step guide for how to implement them into your dev team’s work, it is worth mentioning that evaluation of knowledge worker’s productivity requires a complex approach.
As long as we’re talking about traditional production processes, a productivity metric is quite simple: how many units of a particular quality product are produced and at what cost? For intellectual work, it’s much more tricky.
Knowledge work fundamentally differs from manual work. That’s why an engineering manager should use a different approach when measuring the productivity of developers and, hence, consider factors besides the simple output/input ratio.
However, lots of managers still measure developer productivity quantitatively, ignoring the quality of their work. And this is a huge mistake.
So, let's take a quick look at the main productivity measurement metrics and talk about how much resistance they can meet from developers and why.
Key problems of developer productivity metrics
Lines of сode
How does it work? Efficiency is measured by the number of lines of code written.
What’s wrong with the metric? The problem is obvious: the quality of code is completely neglected.
The metric is irrelevant in modern business realities. Programming is not manual labor on a machine, where the master has made a certain number of products and done well. These are knowledge workers, where everything is more complicated: it is important to look at what benefit the final work will provide to the complex.
How does it work? This metric reflects how the developer has contributed to the team's work.
What’s wrong with the metric? It does have advantages of lines of code metric, yet the practical benefit of counting commits as a measure of software (if it’s the only metric used) is doubtful.
In fact, the commit count metric is nothing more than a "save point", and how often a developer will save his work is his personal preference. The number of commits is generally not a measure of productivity, because a developer can commit every time they create a line of code.
How does it work? The productivity of a developer is measured by the number of completed tasks in this case.
What’s wrong with the metric? The problem with evaluating productivity using this metric is that tasks often come to the developer automatically. They can be large and small. So, a developer can get stuck on a big task, do it well, and fix bugs. And they will look ineffective in the end because they have only resolved one issue. Whereas a developer who has done 10 small, simple tasks will look more efficient.
When used alone, this metric is not an objective assessment.
How does it work? Evaluation is based on an estimate of the amount of code that was found to be unusable.
What’s wrong with the metric? Often the amount of work in prod does not depend on the developer. Perhaps a developer received a task to write the code, but this code did not end up in the release, through no fault of his/her own, but because the product team made the wrong decision at the planning stage.
What should a manager do if all the metrics, to one degree or another, do not reflect the true value that engineers bring?
The solution is not to focus on one approach. Make a comprehensive assessment and individually assess developers, depending on the tasks they are working on, create a set of metrics that suit better for every single occasion and each individual developer.
Step-by-step guide for implementing a productivity measurement tool
Now you know that the best approach to measuring software developer productivity is to use a combination of metrics and to choose the ones that suit your dev team the best.
In this part, we will answer the question: “How to secure developers' buy-in?” It’s a vital one, since the implementation of a productivity measurement tool may meet developer resistance due to their belief that it might be unfair or aimed at controlling them. The goal at this stage is to persuade teammates of the objectiveness of your approach.
If you do everything right, then the developers should understand that this will not only benefit the project, but also help them boost their own effectiveness and usefulness, improve their skills, and become motivated to work better.
The main steps to implementing a software developer productivity measurement tool are:
- Be transparent
- Explain benefits to all parties
- Identify top performers
- Show how each commit is measured
- Make clear the tool is not decisive
- Use metrics from the tools in performance reviews
And now more about each of these points.
Discuss the tool with developers and make sure it will be applied fairly. The team should not have the feeling that managers just want to monitor their work in order to then punish the weakest member of the team. None of this is true. Tell them in detail how the implemented tool will work, and what its benefits are for the business and especially for the employee.
Explain benefits to all parties
Show developers that they can influence their own productivity. Explain that the result of the work is important for each of them personally, because high-quality code is a strong case in the portfolio. They can independently manage their time, workspace, try to show their best skills at work, and acquire new ones if it’s necessary.
Identify top performers
Try to find leaders among the development team empirically. Surely, during your work as a manager, you have accumulated experience and you can easily find such people. Or ask your colleagues for their opinion. Once you find such a person, promote ideas about the importance of introducing productivity measurement tools by referring to this person as an influencer.
Show how each commit is measured
Let developers see your approach to measuring productivity on each commit. Help developers get a tangible understanding of how their work, step-by-step, commit-by-commit, becomes a useful and working product.
Make clear the tool is not decisive
Your team should understand you consider several factors when making decisions, not just based on the metrics. The most valuable developers are not the ones who create the most amount of code, but the ones who do not create bugs, who mentor others, and who are easy to interact with.
Therefore, it is important that when you present your measurement tool, you make it clear that code measurement is just one of many aspects that will affect your assessment.
Read our complete list of factors that influence developer productivity in order to make sure you have excluded all the manager-related productivity killers.
Use metrics from the tools in performance reviews
Show the effectiveness of a data-driven productivity measurement tool. This is what will convince them.
At the performance review, showcase the reports and dashboards from which you draw your conclusions. Highlight the strong sides of your developers, draw attention to their small victories by showing data from these reviews.
How to start?
To successfully implement the tools for your business that will work and ultimately impact growth, here is some practical advice on how to start with a productivity measurement tool:
- Try the free version of the productivity measurement tool before you commit yourself to a company-wide implementation. Answer the questions: “Does this offer a reasonable improvement over our current process?” and “How will it make our job better or easier?”
- Share your solution with top management. Explain how this tool will improve the lives of employees, and focus on the benefits for the business.
- Get support from team members who demonstrates excellent communication skills, technological prowess, and a desire to grow professionally.
- Organize training on the tool, show how the tool works, individually, so that employees participate in the process and do not get distracted during company meetings.
- Test the new tool. Introduce it into workflows smoothly, so developers don't feel stressed. Keep your old process in place as a “backup”.
- Ask employees for honest feedback during 1 on 1 meetings. They should be able to speak up and feel secure in sharing their opinions.
To sum up, starting to measure software developer productivity, make sure you chose the correct tool and prepared your team before its implementation.
- Do not concentrate on a single metric when measuring software developer productivity. You’re not evaluating the lines, but the quality of your developers’ work. Choose the metrics that fit your team’s goals and current tasks and work out a more complex approach.
- You shouldn't introduce new tools without first discussing them with the developers. Be part of their team, then they will be happy to test your implementations in their work.
- To convince developers that the productivity measurement tool is really useful and get positive feedback, ask the team's opinion on the tool at all stages of implementation. The support of the team leaders would also be helpful.
- Make sure that a productivity measurement tool isn't the only factor considered when making decisions on employees’ performance.
One-on-One Meeting Templates For Your Software Development Team
In this blog post, you'll find out about types of 1:1s an engineering manager should carry out with an engineering team on a regular basis. Bonus: ready-to-use one-on-one meeting templates to make them more effective.
Survey: How Engineering Teams Around The World Run 1-on-1 Meetings
In this survey report by the Vectorly team, you’ll find the latest info on how engineering teams around the world (Brasil, Asia, USA, UK, Canada) perform 1-on-1 meetings. 275 people shared what team management problems they face; how do they prepare for 1-on-1 meetings and how much does it take; what’s the specifics of holding 1-on-1 meetings in different countries. Read our full report for insightful details.
Developer Burnout Can Be a Serious Issue. Here Is How to Spot It
Even though a software development gig can sometimes seem like the cushiest job in the world, this perception can often be misleading. Developer burnout is a real problem, since their work environment can often cause chronic stress.