When developer productivity is measured in lines of code, hours, tickets, and not goals and accomplishments, no wonder productivity has become such a dreaded word.
Because, in software development, it’s more about performance. It’s not about producing something big, but delivering reliable, effective products for end-users. This often means “less is more” – numbers are not always relevant to the software quality, nor developer performance.
The problem is that moving from a feeling-driven to a data-driven measurement of your team’s work alignment with business goals is HARD. It asks for tools and metrics put into a context (otherwise, they’re just noise), tied into a story that can help you make confident decisions.
Besides the different tips we will share from our developer experience with productivity, a developer analytics tool like Waydev can provide an ocean of valuable data. It translates engineering activity into developer productivity metrics, reports, and guidelines. This offers you, as a tech lead, the visibility needed into the development processes, to help your team improve.
If you’re interested in upgrading the way you measure developer productivity, let’s dive into how to get the best performance out of your team.
While productivity is about a measure of quantity (numbers, output), performance is a process of accomplishing something (goals, outcome). We could say productivity is more of a means to an end – performance.
But when it comes to most professional careers (teachers, doctors, programmers), we can’t just evaluate numbers. We can’t ask how many patients a doctor has in a day, and measure success based on that. That’s irrelevant and demoralizing, stealing focus from the real goals.
In the same way, developer performance cannot just be evaluated based on numbers, at least not out of context. If that’d be the case, many engineers would feel compelled to simply game the system. That not only affects teams, but also the business itself.
Although measuring developers’ productivity is not exactly a walk in the park, it’s not impossible either.
It can be done by using the right performance metrics and reports for your particular team. Trusted by over 1,000 engineering leaders worldwide, Waydev can show you this full picture. Schedule a live demo.
Now, let’s see some perfect examples of how to approach developer productivity in a way that speaks about performance, with practical tools and metrics.
In Measuring Engineering Productivity, Ciera Jaspen, Google’s Tech Lead Manager of Engineer Productivity Research, talks about productivity as a sum of 5 core components – QUANT, which can be evaluated through different types of metrics:
These are great questions to ask when you decide on which KPIs and productivity metrics to measure for your team.
As you can see, these are less about the numbers and more about outcomes, from the technical and human side of things. You can also use these in how you evaluate the performance of your engineers.
The acmqueue April issue published a brilliant research article on SPACE for Developer Productivity:
After decades of research and practical development experience, knowing how to measure productivity or even define developer productivity has remained elusive. Far too often, teams or managers attempt to measure developer productivity with simple metrics, to capture it all with “one metric that matters.”
The research authors talk about “The SPACE”, a framework for understanding and boosting dev productivity based on five dimensions.
Using these allows leaders to identify and work toward fixing potential process issues, avoid burnout or persistent churn. As a complete Git Analytics tool, Waydev helps engineering leaders do precisely that: deliver more reliable software faster, while driving engineering productivity up.
Productivity and satisfaction are deeply connected. People want to work in a place that empowers them to reach their full potential.
When engineers feel great about their work, their team, and their tools, and see the impact of their efforts, their performance levels go high.
When engineers are unhappy, stuck in an unproductive place, you’ll see lower retention and productivity, since feelings of burnout and lack of involvement are linked to a decline in results.
Treat the satisfaction and well-being of your team the same way as you treat any performance metrics. You can think of it as a valuable KPI, where you can measure:
For example, Waydev looks at Responsiveness paired with Reaction time metrics, as with the Review Collaboration feature in Waydev.
The first one refers to the time it takes a submitter to incorporate feedback from reviewers, while the second is about the time it takes to provide feedback on PRs. Both can give you an overview of the way your team is involved and collaborate.
Certain metrics can speak about potential cases of burnout. High rates of Churn and Low Throughput for an extended period can tell it’s time to revitalize an engineer with a new project.
Anonymous surveys are extremely helpful in finding out where you’re situated and how you can support your team the way they need. You can “measure” how engineers feel about their workplace, level of trust, quality of team communication, and your management style.
Dev productivity metrics can offer valuable insights into an individual engineer’s output. They give you an idea of when to coach, advocate for, and support people in their career.
But individuals don’t own or maintain code – teams do. The team is the one responsible for writing software. So look at performance at a team level to see the bigger picture.
Writing large amounts of code doesn’t necessarily mean it’s productive. Quickly responding to comments doesn’t always mean efficiency. Tasks differ in impact and cognitive load.
Instead, consider measuring performance through productivity metrics and reports that tell you a story of how the end product is delivered. For example:
And look at a large set of team metrics (amount of commits, average time to respond, number and frequency of code reviews, average time to merge PRs).
They’re not useful alone, but together they show you a clear overview of the progress and challenges of your team. And you can access all these important metrics and reports of engineers’ activity in Waydev.
Our Dev Analytics tool measures developer performance automatically; it makes engineers more efficient, managers more accurate, and processes less flawed, without draining extra resources. You can also see here how a day in the life of an engineering manager looks like.
With the right dev analytics and clear objectives, you can gain valuable insights about developer productivity and performance.
This is relatively easily done by measuring specific sets of activity metrics and getting access to relevant activity reports across different phases of software development.
With the Developer Summary report, you zoom into each engineer’s stats. You can understand how each one is contributing to the codebase, how they collaborate, and their work patterns. Plus, you can identify cross-training and up-skilling opportunities.
Developer summary metrics like:
You also have access to Developer Performance and Developer Progress reports. These help you to recognize nuances, like identifying when engineers are putting in effort to help others.
With the Work Log report, you can gain visibility for each engineer, such as code commits, merge commits, pull requests open and merged comments and reviews.
Impact is a complex metric that is particularly useful in finding the quiet heroes of performance. It speaks on how much cognitive load the engineer carries when implementing changes. It takes a look at:
It’s difficult to spot when engineers are paying down technical debt. But with Waydev features you gain visibility into this “invisible delivery”, a major contribution to the code quality.
Team collaboration is essential in software development because it’s a creative and highly collaborative field.
Without a clear flow of coordination and communication, team members would be affected and forced to correct many issues (that could have been prevented) – unnecessary rework and code reviews, slower pull request merges, additional time spent on bug fixing, burnout and blockers.
There are a few metrics that can be used to assess and improve coordination and collaboration.
Review Collaboration allows you to see who in your team is sharing knowledge. It also provides valuable metrics to help you assess the health of your code review workflow. You can compare evaluations for each sprint, to get a better perspective on the performance level.
Another thing you can do is to facilitate discussions during Retrospectives. They are essential to making improvements to the process and product. For that, you need data about what was shipped and how it was shipped.
Once you get a hang of these developer productivity metrics, you can bring up data to set clear and healthy expectations around responsiveness and team velocity. And you can spend time talking about why and what the team would like to start, stop or keep.
By also frequently measuring Legacy Refactor and New Work metrics, as well as our Sprints feature, you can evaluate the success of your sprints and the amount of technical debt.
And with data at your fingertips, you and your team can notice and correct deviations in healthy collaboration and take action.
Team performance is also about being able to identify potential roadblocks and disruptions in your developers’ work – and eliminating them.
At team level, efficiency is affected by delays and handoffs during the software cycle. Teams should first track the four core metrics (DORA):
And since many software professionals talk about a flow state that boosts their productivity, let’s take a closer look at this part.
A state of flow increases joy and motivation when working. It can be optimized by tracking how much uninterrupted time an engineer has, and how long they wait for reviews. No matter the job, we work better when there are no disruptions while doing something. That is the flow state.
And there are quite a few disruptions that developers dread: meetings, reports, ineffective tools, lack of work-life balance, difficult access to documentation. Standups are ineffective and meetings take up valuable time.
The solution is to identify these blockers and eliminate them. You can use the Work Log report and see historical data about when engineers have high productivity impact.
It shows you where the attention of engineers goes or when there’s an unexpected deviation in activity. Use it to track meaningful metrics that help you:
The Activity Heatmap feature helps you to find out what their golden hour is, in terms of developer productivity. Also, it allows you to schedule meetings depending on the engineer’s flow. It includes metrics like:
Another important one is code churn. When a problem seems complex, developers will rework, test and explore various solutions. The churn levels are not always bad – it is normal during prototyping, when engineers shouldn’t be interrupted.
They vary from one team or individual to another, and that’s why it is your task as a manager to understand the baseline levels and the right context, to start identifying spikes and irregularities.
Without context, metrics are just… noise. Put them in the right context, and you have a strategic tool for business intelligence, helping you make great decisions and better predictions without any “gut feelings” involved.
300+ managers are improving their engineers’ productivity with Waydev, the Dev Analytics tool we created.
You can become part of this community of great engineering managers by using Waydev yourself. Get the right set of metrics and tools to automatically track, measure, and optimize your engineers’ effectiveness and productivity, without their manual input.
Or if you want to find out more about how Waydev can help you, schedule a demo.
😍 You May Also Like: What is the Difference Between Lead Time and Cycle Time?🔥
Ready to improve your SDLC performance?
