How to Establish Relevant Performance Metrics for Developer Productivity

When businesses invest in developing and using performance metrics, they are well-positioned to attain their productivity goals. Conversely, when businesses don’t prioritize metrics, they are much more likely to struggle with productivity. Just 23% of companies that don’t use KPIs (key performance indicators) report being able to hit their performance targets, according to industry research from Geckoboard. That’s in contrast to 96% of metric-driven companies that say they’re able to hit their performance targets.

For developers, performance metrics are especially relevant and essential. Metrics help development teams prioritize and clarify what they should be working on. Metrics also enable the C-suite to track a development team’s progress toward reaching its targets. However, setting performance metrics for developers isn’t always obvious or straightforward. There’s not one single set of definitive metrics that every organization should be using to measure developer productivity. Rather, businesses must be prepared to evaluate performance in multiple ways to gain meaningful insights into how their development team is performing. Let’s explore four universal strategies that businesses should use when developing relevant, tailored metrics to measure their development team’s performance:

1. Don’t conflate metrics with actual objectives: Performance metrics for developers are indicators of performance, not the business’s objectives. However many businesses conflate metrics with actual objectives. As a result, developers rely disproportionately on metrics to track big-picture outcomes and focus on achieving their metrics at the expense of helping the company achieve its bigger-picture objectives. For example, a metric might be to maintain 99% uptime for an app, but if the development team focuses all of its energy on maintaining 99% or better uptime, the team may be ignoring the company’s bigger-picture objective, which in this case could be developing an app that consistently delights and surprises customers. That’s why developers shouldn’t be obsessing over attaining or beating specific productivity metrics; it causes them to lose sight of how they can best help support the company’s strategic, bottom-line goals.
2. Establish metrics based on service-level objectives, not just SLAs: Businesses commonly think in terms of service-level agreements (SLAs). SLAs establish performance levels and responsibilities between a business and its vendor, making SLAs easy to measure and track. For example, a common SLA for an offshore development team might be to retest every app following a DevSecOps update. However, these SLAs are limited in that the insights they offer into developer productivity are limited. In other words, just because the development team is consistently completing all of their checklist DevSecOps tasks, the business has no way of knowing, for example, if meeting the SLA resulted in a boost to customer satisfaction scores. To make sense of SLAs, it’s important to organize them under an umbrella objective known as a service-level objective (SLO). An SLO establishes a long-term roadmap for how an app or service will need to evolve over time to achieve some sort of big-picture goal for the organization. Thus, an SLA-based metric quantifies incremental progress toward the SLO.
3. Use DORA to capture a broad range of metrics: Every business intuitively understands that certain attributes of DevOps teams are responsible for driving optimal productivity. But putting a finger on exactly what those attributes are can be challenging. A Google Cloud-sponsored research program known as DORA (DevOps Research and Assessment) is aiming to systematically pinpoint how to measure and track developer productivity over time. DORA calls on businesses to track a set of best-practices metrics, including deployment frequency, lead time for changes, change failure rate, and mean time to recovery. By focusing on these metrics, DORA encourages businesses to shift their mindset from writing code to driving value.
4. Don’t use metrics to pit team members against one another: Businesses often develop metrics that focus on measuring productivity instead of measuring outcomes. Some of these metrics are so specific that, intentional or not, they become de facto owned by individual members of the development team. The end result is these metrics pit team members against one another – and the business ultimately gains little meaningful insights into whether the development team is getting the outcomes it should. To ensure metrics don’t pit team members against one another, it’s essential to avoid setting metrics that focus on individual developer productivity. Instead, businesses should be choosing metrics that paint a bigger picture of how the development team is contributing to overarching company goals.

Developer productivity is often a black box to the rest of the organization that can be difficult to crack open in meaningful, insightful ways. To set relevant performance metrics for development teams, businesses should remember to avoid conflating metrics with actual business objectives, establishing metrics based on SLOs as well as SLAs, using the DORA method to capture a broad range of insightful metrics, and avoid using metrics to pit team members against one another.

Ippon specializes in working with businesses to set value-add metrics for their development teams that drive bottom-line profitability and customer satisfaction. To learn more about Ippon’s approach to setting developer performance metrics, please check out Ippon’s latest eBook, “The Secret to Boosting DevSecOps and Developer Productivity.”