How to Measure Engineering Team Performance

Why the wrong metrics cause more damage than none

Most of the metrics engineering managers reach for first are activity metrics. Story points completed per sprint. Tickets closed per week. Commits per engineer. These feel measurable because they are easy to count, not because they are meaningful. The problem is that they optimise for the measurable thing, not the thing you actually care about. Velocity climbs when teams inflate estimates. Ticket counts rise when work is broken into smaller pieces for appearance rather than clarity. Commit frequency increases when people commit more often to look productive.

This is Goodhart's Law in action: once a measure becomes a target, it stops being a good measure. Activity metrics do not tell you whether the team is building the right things, building them well, or building in a way that is sustainable over time. They also damage trust. Engineers who feel assessed on raw output learn quickly to optimise for the metric rather than the outcome.

The DORA framework - a validated foundation

The most rigorously validated model of engineering performance comes from the DORA (DevOps Research and Assessment) programme, which has tracked engineering teams across thousands of organisations for over a decade. It identifies four metrics that correlate strongly with both organisational performance and team health. Crucially, they measure outcomes rather than activity.

DORA is not a target to hit. It is a diagnostic tool. Teams use it to understand where they sit, spot where they are losing time or quality, and track whether changes they make are actually helping. The four metrics work together - improving one in isolation while ignoring the others is a warning sign rather than a win.

If you can only start with two, begin with deployment frequency and lead time. They are the easiest to instrument and immediately reveal whether your pipeline is working for your team or against it.

What to track alongside DORA

DORA metrics are powerful but incomplete. They focus on the delivery pipeline and do not capture everything that determines whether a team is healthy and effective over time. Three supplementary areas are worth tracking once the DORA foundations are in place.

• Quality indicatorsDefect escape rate (bugs that reach production), customer-facing error rates, and test coverage give you a signal on code quality over time. Review these as trends rather than point-in-time snapshots. A team that rarely ships defects but when it does takes weeks to fix them has a different problem to one with frequent small issues resolved in hours.
• Cycle timeThe time from a piece of work being picked up to it being shipped. Distinct from DORA lead time, which covers the pipeline from commit to production, cycle time reveals where work slows down inside the team - in review, in QA, waiting on dependencies, or stuck in a queue. Sustained high cycle time is often the first signal that the team is overburdened.
• Team healthTechnical performance data alone misses the conditions that determine whether performance will hold over the next six months. Regular retrospectives and team surveys surface psychological safety, workload, burnout risk, and engagement. These are leading indicators: a team with declining health will show deteriorating technical metrics three to six months later, consistently.

You do not need to track everything at once. Starting with DORA plus a lightweight team health check from your retrospectives gives you most of the signal you need without creating a metrics overhead that nobody maintains.

What not to measure

Knowing which metrics to avoid is as important as knowing which to adopt. Some common approaches are not just unhelpful - they actively damage the team. If any of these are currently in use in your organisation, replacing them with better alternatives is worth treating as a priority.

• Lines of codeWritten and deleted code are not the same thing. Deleting three hundred lines of unnecessary code is often more valuable than writing them. Measuring output by volume rewards complexity and penalises the engineers who keep systems clean.
• Story points per personStory points reflect complexity, and they are estimated by the team collectively. Comparing engineers by points completed turns a shared team estimate into an individual performance judgement it was never designed to support. It also incentivises padding estimates.
• Utilisation rateA team operating at 100% capacity has no slack for learning, refactoring, or handling the unexpected. Consistently high utilisation is a risk indicator, not a success metric. Teams that appear fully occupied often have serious technical debt accumulating invisibly underneath.
• Commit frequencyUseful for understanding workflow habits but meaningless as a performance signal in isolation. Frequent small commits can indicate good engineering practice or anxious over-checking. Without context, the number tells you almost nothing about quality or progress.

How to use metrics with your team

The most important thing about engineering metrics is not which ones you choose. It is how you use them. Data that lives on a dashboard nobody reads is useless. Data that only surfaces when something goes wrong is demoralising. The goal is to build a shared language around performance that the team owns and engages with rather than fears.

• Make them visibleShare the metrics with the team. Engineers who can see their own data tend to engage with it rather than resist it. A dashboard that is reviewed together in retrospectives is far more useful than one only the manager reads. Visibility without transparency creates suspicion.
• Use them to open conversationsWhen cycle time spikes or change failure rate rises, that is a conversation starter, not a verdict. Bring the data to the team with a question - "What do you think is driving this?" - rather than an announcement. Teams that investigate their own metrics find problems you would never surface from above.
• Focus on trends, not snapshotsA single sprint where deployment frequency drops tells you almost nothing. A consistent three-month trend where it is falling is worth a real conversation. Single-point readings are noisy; patterns are signal. Resist the urge to react to every week-on-week change.
• Let the team choose what mattersInvolve engineers in deciding what to track and what targets would feel meaningful to them. Metrics imposed from above tend to generate compliance. Metrics the team helped define generate ownership. That ownership is what turns data into improvement.

A useful test: if you shared your current metrics with the team tomorrow, would they feel informed or judged? The answer tells you whether you are using data as a management tool or as a development tool. Only one of those creates a healthy team culture.