5 Developer productivity metrics you should measure

As software development becomes increasingly complex, developers are expected to take on more responsibility along the path to production. Most developers don’t have the working experience necessary to interact with cloud platforms like Kubernetes or Terraform, even though they must regularly use them to deploy to production. This cognitive load affects their ability to maintain productivity and velocity.

As a result, developers often spend more time pushing features to production than coding. They lose time to things like writing unfamiliar code for Terraform modules, which can not only delay production but introduce security risks and other vulnerabilities that will either degrade the production environment or require repeated effort to resolve them (or both).

To address pain points like these and drive continuous improvement, engineering managers need to find ways to understand their teams’ performance and areas for improvement. But where should managers start?

We’ll discuss five developer productivity metrics in this post and how they contribute to overall business success. 

What are developer productivity metrics?

Developer productivity metrics are a subset of engineering metrics designed to help managers keep better track of work and provide developers with a clear picture of success. They encompass people metrics, process metrics, project metrics, and code metrics.

When enabled effectively, developer productivity metrics help you understand the speed, quality, and frequency of developers’ work across the software development lifecycle. There are five primary developer productivity metrics:

1. Lead time to change — how long it takes to push a working piece of code to production
2. Deployment frequency — how often deployments occur
3. Change failure rate — how frequently deployments fail
4. Mean time to recovery (MTTR) — how quickly your teams can resolve issues and return to normal production after incidents
5. Overall cycle time — how long a feature is in production, from coding to deployment

You may notice that these are similar to DORA metrics — and while that is true, these metrics can be applied more generally than just to DevOps and provide deeper insight into where and how your developers lose productivity. 

In addition to productivity, these metrics help you identify better ways of working and implement best practices in the form of working agreements, which make life easier for developers and managers alike by increasing transparency. 

Why measure developer productivity?

Measuring developer productivity is important because it can:

• Help reduce costs
• Provide insight into areas for improvement
• Surface previously unreported or unknown slowdowns that were considered normal
• Highlight where and how R&D teams have added value to the company, with specifics

Before DevOps and DORA metrics, it was difficult to measure developer productivity because it was difficult to understand the relationship between developers’ input and output. Work such as building new features and releasing them to production was not easily measured or tracked using a time metric (i.e., hours worked) because a feature that took a day to produce is not necessarily worse or less important than a feature that took a month to produce. 

Similarly, lengthy development times did not necessarily mean that a process was overly complex or that a developer ran into too many problems to reach deployment on time — the problems were more complex, and often related to the quality of code deployed earlier on in the development process.

On another note, it’s important to measure developer productivity in relation to developer experience. Developer productivity and experience are not the same thing, though they are typically tightly coupled. 

Consider the above example again: if a feature took six hours to reach deployment, measuring both developer experience metrics and developer productivity metrics will help you determine whether:

1. The developer had a poor experience — they couldn’t find what they were looking for or were unable to access a tool they needed, or 
2. The developer was not as productive as they could have been — their pull request languished in the review stage for four of the six hours of lead time

How to measure developer productivity

If you aren’t currently measuring developer productivity, start by surveying your developers about their experience working in your specific software development environment. Build a thorough survey that asks your developers about:

• Pain points — where do things become difficult?
• Blockers — how and when are developers prevented from or unable to continue doing work?
• Workloads —  is part of your team suffering from a case of Ticket Ops?
• Cognitive load — similar to the above, is part of your team slogging through work others can support?
• Clarity and quality — does your team understand what “good” code looks like? 

Understanding your developers' pain points in terms of what, where, when, why, and how is a great place to begin making improvements. Knowing what needs to be done helps you plan with your teams to fix workflows and establish better practices. 

If you don’t have anything in place, other resources, such as industry baselines, also exist to help you:

• Gauge your current software development quality and velocity
• Establish improvement benchmarks
• Measure and track developer productivity
• Set standards for development

You should still use these as a supplement to your developer survey results, as those will be most applicable to your team.

Improving developer productivity with an open internal developer portal

If you’re looking for a quick fix — don’t skip the survey. Instead, take your results and use them to establish working agreements that give your developers a clear productivity goal to work towards.

If your survey results say developers are tired of waiting multiple days for a PR review, consider setting a working agreement that PRs must be reviewed within one day of submission. This can then be measured and tracked as a way of understanding productivity. 

Where can this be tracked, you ask? In an open internal developer portal! A portal unifies your software development platform into a single UI, which then enables self-service actions for developers to complete common actions and provides methods for setting and communicating baselines, tracking work, and establishing team-wide initiatives. 

Platform engineering has also emerged as a discipline focused on prioritizing developer productivity. Platform engineers build and orchestrate the development platform, which consists of all the different software needed to deploy to production. There are many platform engineering and software engineering intelligence tools available to help measure a variety of developer and engineering metrics.

But the best part about platform engineers — who are responsible for building, maintaining, and iterating on the portal — is that they can create new workflows in the portal UI, and abstract away all of the complexity that comes with deployment, cloud technologies, and AppSec. 

Using a portal, platform engineers are empowered to design workflows, self-service actions, and scorecards specifically for your team, using the results from your developer survey to build solutions that are as unique as your tech stack.

Ultimately, the most important first step is to understand the problem you and your teams are facing. Every situation and software development lifecycle is unique, and comes with its own individual challenges — so, from the jump, you are the best person to solve them!

If you take your survey results seriously and engage your platform engineers like product managers whose focus is on improving the experience of their developers, you should see an improvement in every developer productivity metric. 

Curious about Port’s open internal developer portal? Imagine your future using our open demo. Happy building!