Goodhart's Law in Software Engineering: How Metrics Can Mislead Teams

You rely on metrics to track progress, improve performance, and make better decisions. But what happens when those numbers start working against you? If you focus too much on hitting a target, you risk losing sight of your true goal.

This is where Goodhart’s Law comes in. It explains why, once a measure becomes a target, it stops being useful. The wrong focus leads to negative consequences, such as teams focusing on numbers instead of real impact.

In this article, you’ll learn how to avoid this trap, take a balanced approach to metrics, and use Axify to track what truly matters. Let's get right to it.

What Is Goodhart's Law in Agile?

Goodhart’s Law states, “When a measure becomes a target, it ceases to be a good measure.” In Agile, this happens when teams focus on hitting specific numbers rather than improving processes.

You risk focusing on the wrong things if you rely too heavily on velocity, cycle time, deployment frequency, or any other metric viewed as output, without considering the broader context (including the outcome). 

Instead of delivering value, you might chase numbers that don’t reflect actual progress.

This issue is common in software development teams. A real-world example is the Novopay project in New Zealand. This company wanted to replace a nationwide payroll system responsible for paying 110,000 people in the education sector. However, focusing on meeting rollout deadlines and hitting predefined targets—rather than ensuring system stability and user readiness—led to widespread payroll errors, technical failures, and government intervention. 

By following deployment at all costs (even quality), the project became a case study of how focusing on the wrong metrics can derail a critical initiative.

So, prioritizing a single objective without addressing risks or stakeholder needs can cause severe disruptions. 

That’s why you first need a solid measurement approach to ensure your team tracks meaningful metrics that drive real success. Then, you need to consciously not pursue output at all costs but instead value and quality.

Goodhart's Law Examples in DevOps

Metrics are meant to help you measure progress, but when they become the ONLY goal you focus on, they stop being useful. In DevOps, we frequently see or hear about teams who start focusing on numbers instead of outcomes.

You want faster delivery, higher efficiency, and better collaboration. But if you track the wrong things, you might make decisions that do more harm than good.

For example, many teams use story points to measure productivity. Management wants better output (more story points), so developers simply assign higher values to their estimates. Suddenly, productivity looks excellent, but nothing has actually improved.

This is precisely how Goodhart’s Law plays out in performance measurement. Without a holistic approach, relying on a single metric can mislead your team. It will also make them focus on numbers instead of real business impact.

Let's look at other examples to clarify things even more.

Misguided Software Engineering Metrics

You might think tracking output metrics will help you improve performance, but if those metrics are easy to manipulate, they won’t reflect actual progress. Here are two common examples of how this happens:

• Story points: If your team inflates estimates just to appear productive, sprint planning becomes unreliable. Instead of tracking effort, you end up with misleading data.
• Lines of code: Writing more code doesn’t mean writing better code. If developers are rewarded for adding lines rather than improving efficiency, you get bloated, harder-to-maintain code.

Good Metrics Taken Out of Context

Even useful metrics can backfire if you only focus on them without considering the bigger picture. These two examples show how focusing on a single number can create hidden risks:

• Cycle time: Reducing cycle time sounds great, but if you push too hard, you risk skipping thorough reviews. Bugs slip through, leading to more issues down the line.

• Deployment frequency: Faster deployments are valuable, but if you’re shipping unstable changes, your team will spend more time fixing problems than delivering real value. If you don’t measure business health alongside deployment speed, you might be setting yourself up for failure. This ties back to Goodhart’s Law: If teams focus only on increasing deployment frequency without considering code quality, they risk optimizing the wrong thing, leading to technical debt, downtime, and customer frustration.

Ignoring Contextual Analysis

It’s easy to focus on metrics because they’re simple to track. But numbers alone don’t tell the whole story. The SPACE framework helps you gain that context. 

Instead of just measuring output, it suggests using three KPIs across three dimensions of SPACE (which are Satisfaction & well-being, Performance, Activity, Collaboration & communication, Efficiency & flow). 

For example, if you focus on individual metrics, you can track code review velocity (performance), developer satisfaction (satisfaction and well-being), and PR merge times (collaboration).

Instead of tracking how fast you ship features, consider qualitative measures such as code quality, team engagement, and long-term impact. Good metrics should help you make better decisions, not create undesirable effects that slow you down in the long run.

These examples lead us to the next point.

Good KPIs and Mindsets to Mitigate Goodhart's Law

To avoid the negative impacts of Goodhart’s Law, you need to track the right metrics and adopt a mindset that prioritizes actual outcomes over vanity numbers.

Instead of individual output, you should focus on team performance, product quality, and long-term success. A common approach is using a mix of quantitative and qualitative metrics reflecting speed and stability.

Using the Right Metrics

We know that you need to move fast but without sacrificing stability. We recommend using the DORA mindset, which balances speed and reliability. Tracking deployment frequency, change failure rate, lead time for changes, and failed deployment recovery time helps you get a clearer picture of efficiency and system health.

These metrics alone don’t tell the whole story. You should track customer feedback, product quality, and service efficiency to understand the real impact of your work. Something is probably off if your team is hitting delivery goals but users are unhappy.

The Right Mindset to Have

Tracking the right metrics is only part of the solution. You also need the right mindset (one that focuses on value delivery, team collaboration, and long-term success). Here are three key principles to help you avoid the pitfalls of Goodhart’s Law:

• Flow-based thinking: Instead of measuring individual performance, focus on how efficiently your team delivers value. Axify’s Value Stream Management (VSM) helps you track bottlenecks, reduce waste, and improve your workflow.

• Outcome-oriented metrics: Measuring raw output leads to unintended consequences such as rushed work and technical debt. Instead, you should tie your KPIs to customer satisfaction and business results. Axify’s OKR tracker helps you connect engineering efforts to actual goals.

• Leverage the SPACE framework: To create a balanced view of productivity, consider meaningful insights in context. Remember, you need at least three metrics from three different dimensions. You also need qualitative metrics like developer satisfaction and collaboration alongside quantitative KPIs like velocity and cycle time. This approach helps you improve both team efficiency and well-being.

Choosing the right KPIs and adopting the right approach for engineering leaders allows you to focus on broader business goals and ensure a healthier, more effective team.

Here's what you should do.

Avoid Goodhart’s Law with Axify

Focusing on the wrong metrics can have adverse effects, such as inflated estimates, rushed reviews, and misaligned priorities. Even following good metrics without context or turning them into goals is highly problematic.

That’s why you need a more thoughtful way to track performance – one that helps you reach your goals without falling into the common outcome vs. output trap.

Axify allows you to monitor flow, balance speed with stability, and connect your engineering work to tangible business outcomes. Instead of chasing numbers, we can help you improve collaboration, efficiency, and long-term success.

Don’t let bad metrics or insufficient context hold your team back. Book a demo with Axify today and see how you can deliver value.

FAQ

How can I mitigate Goodhart's Law?

You can mitigate Goodhart’s Law by using a mix of qualitative measures and outcome-based KPIs instead of relying solely on raw numbers. You should track business processes that reflect real value, not just individual performance. Frameworks such as SPACE and DORA can help you balance speed, collaboration, and quality.

Is Goodhart's Law true?

Goodhart’s Law is true and widely observed in social decision-making and performance tracking. When a metric becomes the primary target, people tend to manipulate it, making it a poor measure of real success.

What is an example of Goodhart's Law?

An example of Goodhart’s Law is when developers inflate story point estimates to appear more productive. The metric (story points) becomes the target but no longer reflects actual work effort.

What is the strong version of Goodhart's Law?

The strong version states that even honest efforts to prioritize a metric will eventually harm the complex systems it was meant to improve. Metrics alone can never fully capture how different factors influence each other within a system.

What is replacing KPIs?

OKRs (Objectives and Key Results) are replacing KPIs. They help you focus on broader goals instead of hitting isolated performance numbers.