Noah Labhart logoNoah Labhart

Guide

Engineering metrics that matter (and the ones that don't)

Track a small set of team-level metrics: deployment frequency, lead time for changes, change failure rate and time to restore, plus one customer-facing reliability measure. Never measure individual engineers by commits, lines or story points — those numbers are trivially gamed and destroy trust.

6 min read · Updated 2026-08-06

What engineering metrics should a startup track?

Start with the four DORA delivery metrics plus one reliability measure your customers would recognise. Five numbers, reviewed monthly, will tell you more than a dashboard of thirty.

MetricWhat it tells youA healthy early-stage target
Deployment frequencyBatch size and confidence in the pipelineDaily or better
Lead time for changesFriction between idea and productionUnder a day for a small change
Change failure rateWhether speed is costing you qualityUnder 15%
Time to restore serviceOperational maturityUnder an hour
Customer-visible availabilityWhat users actually experienceAgreed with the business, then met

Why shouldn't you measure individual developer productivity?

Individual output metrics measure the visible part of a collaborative job and punish the invisible parts — review, mentoring, deleting code, preventing work. Once a number affects someone's rating, it stops describing reality.

  • Lines of code rewards verbosity and punishes deletion.
  • Commit counts reward noise.
  • Story points are an estimation aid, not a unit of value.
  • Ticket throughput rewards splitting work rather than finishing it.

How do you measure engineering quality?

Measure escaped defects and their cost, not test coverage percentage. Coverage tells you what was executed; escaped defects tell you what your customers had to live with.

  • Defects reported by customers per release.
  • Percentage of incidents caused by a change made in the last 24 hours.
  • Time spent on unplanned work as a share of the sprint.
  • Flaky test rate — a leading indicator that the suite is about to be ignored.

How should you review engineering metrics with the team?

Review them monthly, with the team present, as inputs to a conversation rather than as a verdict. The useful question is always 'what changed and what should we try', never 'who is responsible for this line going down'.

Frequently asked questions

What are the DORA metrics?
Four measures of software delivery performance from the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and time to restore service.
Is velocity a useful engineering metric?
Only inside one team, for their own planning, and only as a trend. Comparing velocity between teams is meaningless because points are not a shared unit.
How many engineering metrics should you track?
Roughly five. Enough to see delivery, quality and reliability; few enough that everyone on the team can recite them.

From the podcast

Founders who lived this

Code Story episodes where founders work through the same problem in their own words.

More on data & analyticsMore on saas & b2b

Keep reading

Related guides

Scaling an engineering team from 5 to 50

How to scale a startup engineering team from 5 to 50 people: when to add managers, how communication breaks, what process to add at each size, and what to leave alone.

Managing technical debt without stopping the roadmap

How to identify, quantify and pay down technical debt at a startup without freezing the roadmap — including how to explain the trade-off to non-technical stakeholders.

Startup engineering team structure that actually ships

How to structure a startup engineering team: the models that work at 5, 15 and 40 engineers, how to split teams, and the org mistakes that quietly slow delivery.

All guides