Engineering team metrics interview answer

In this article

1. Before you start
2. Why interviewers ask this
3. Engineering team metrics from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one part of the leadership interview questions guide; read that first if you are preparing for a manager or director loop, and see the director of engineering interview questions for the senior version.

Why interviewers ask this

A manager who cannot say how they know a team is doing well cannot defend its plan, its headcount or its priorities. Interviewers for manager and director roles ask about team metrics to find out whether you measure outcomes or only activity, whether you read several numbers together, and whether you know how a number gets gamed. Searchers phrase the question as "What metrics do you use to evaluate engineering team health and productivity?" or "What successful metrics have you achieved, and how do you measure your team's success?"

A weak answer lists commits, pull requests and lines of code. A strong answer names a small set of outcomes, reads them in pairs, adds a people signal and ends with what you changed because of them. A Staff-level answer also says what the numbers cannot tell you: they do not show customer value, individual performance, or why a number moved.

Engineering team metrics from first principles

DORA metrics

The DORA metrics are a set of five software delivery performance measures defined by DORA that describe how fast a team ships changes and how often those changes cause trouble: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They are best applied to one application or service at a time.

Failed deployment recovery time

Failed deployment recovery time is the time it takes to recover from a deployment that fails and requires immediate intervention. DORA renamed it from mean time to recover (MTTR) because the old definition did not separate failures caused by a software change from external causes such as a data center outage.

SPACE framework

The SPACE framework is a way of choosing developer productivity metrics across five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Forsgren and colleagues published it in 2021 to show that productivity cannot be reduced to one number.

In plain words

Think of a car dashboard. The speedometer tells you how fast you are going and the fuel gauge tells you what the trip costs. Neither one tells you whether the journey is going well, so a good driver reads both and watches the road. Team metrics work the same way: each one is a gauge, and you read them together.

The analogy breaks in one place. A speedometer cannot change what the car does to move its own needle, but a team can change how it works to move a number. That is why gaming matters.

In one precise sentence, an engineering team metric is a measured quantity about how a team's work reaches users or how the team is doing, and a good answer picks a small set that covers speed, stability and people.

Step 1: Start from outcome questions, then pick the metrics that answer them

Start from outcome questions, then pick the metrics that answer them. Three questions cover delivery: how fast does a change reach users, how often does a release cause trouble, and how fast do you recover when one does. DORA has identified five software delivery performance metrics (guide updated January 2026) that answer them:

• Change lead time: the time for a change to go from committed to version control to deployed in production.
• Deployment frequency: the number of deployments over a given period.
• Failed deployment recovery time: the time to recover from a deployment that fails and needs immediate intervention.
• Change fail rate: the ratio of deployments that need immediate intervention.
• Deployment rework rate: the ratio of deployments that are unplanned but happen as a result of an incident in production.

DORA's history page (January 2026) groups the first three as throughput and the last two as instability.

You now have the vocabulary; the next step is how to read it.

Step 2: Pair a speed metric with a stability metric

Pair a speed metric with a stability metric so one cannot be gamed alone. For example, a team told to raise deployment frequency can push many untested or half-finished deployments and hit the number while releases get worse; change fail rate, read beside it, shows the damage. DORA names this trap: setting metrics as a goal, which it ties to Goodhart's law (when a measure becomes a target, it stops being a good measure), with the example "Every application must deploy multiple times per day by year's end."

It also lists "Having one metric to rule them all" as a pitfall and advises several metrics, including some with a healthy amount of tension between them. The pairing is not a compromise: DORA's research has repeatedly shown that speed and stability are not trade-offs, and high performers excelled at both. In your answer, say the pairs out loud: lead time with change fail rate, deployment frequency with deployment rework rate. You now have a defense against the gaming follow-up.

Step 3: Add a people signal

Add a people signal because productivity cannot be measured by a single metric or dimension. That is the claim in the abstract of Forsgren and colleagues (2021), which says developer productivity "is about more than an individual's activity levels or the efficiency of the engineering systems relied on to ship software." Its five dimensions are satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.

DORA metrics measure delivery, while SPACE is a wider framework for choosing metrics, so using both gives you a delivery answer and a team-health answer. In practice, add one measure of how engineers feel about their work, such as a short regular survey, and treat counts such as commits as one weak signal at most.

Step 4: Use the numbers to improve, not to rank

Use the numbers to improve your own team over time, not to rank teams. DORA says the goal is to improve your team's performance over time, not to compete against other teams. It lists "Making disparate comparisons" as a pitfall, because DORA says its metrics are best suited for measuring one application or service at a time: a mobile app and a mainframe system are not comparable.

Its improvement loop makes a good spine for the end of your answer: set a baseline (its Quick Check is one way), talk with the team about friction, commit to the biggest constraint, plan the work with leading indicators such as code review time and test quality (a leading indicator moves before the outcome you care about, so it lets you steer early, while a lagging indicator such as change fail rate reports what already happened), do the work, check progress and repeat. DORA also suggests starting with conversations rather than heavy tooling. Close your answer with one change you made and what moved.

1 · Outcome questions2 · Paired metrics3 · People signal4 · ImproveReplay

Step-by-step description

1. Start from what you need to know.
2. Pair speed with stability.
3. Add a team-health measure.
4. Improve over time, do not rank.

• Start from outcome questions, then pick the metrics that answer them.
• Pair a speed metric with a stability metric so one cannot be gamed alone.
• Add a people signal because productivity cannot be measured by a single metric or dimension.
• Use the numbers to improve your own team over time, not to rank teams.

Worked example

Take an illustrative team that ships one service. Over four weeks it makes 40 deployments, so deployment frequency is 10 per week (illustrative).¹ The median change lead time is 14 hours (illustrative).¹ Six deployments need immediate intervention, so change fail rate is 15% (illustrative), and the median failed deployment recovery time is 2.5 hours.¹ Five unplanned deployments follow incidents, so deployment rework rate is 12.5% (illustrative).¹

Now a leader sets a goal to deploy more often. To hit the count, the team ships half-finished slices and skips review on the extra releases. Working in small, well-tested batches is not the problem; the damage here comes from chasing the count. In the same illustrative model, deployments double to 80 in four weeks, so frequency becomes 20 per week and the median change lead time falls from 14 hours to 4 hours.¹ A speed-only report calls this a win. In this illustrative example, change fail rate rises from 15% to 25% when deployment frequency doubles.¹ The median recovery time moves to 3 hours and the rework rate reaches 20% (illustrative).¹

Text description of the diagram

• In this illustrative example, change fail rate rises from 15% to 25% when deployment frequency doubles.
• The deployment rework rate rises from 12.5% to 20% in the same illustrative example.

What you say about it: speed improved and stability got worse, so the goal was wrong. Keep deployment frequency as a signal, and set the goal on the paired outcome. Quote your own baseline and trend rather than an industry band; this page uses no benchmark thresholds.

Trade-offs and edge cases

DORA and SPACE answer different questions, so choose by what you are asked.

Text description of the diagram

• DORA metrics measure delivery, while SPACE is a wider framework for choosing metrics.
• DORA also says the metrics suit one application or service at a time.

DORA metrics measure delivery, while SPACE is a wider framework for choosing metrics. DORA also says the metrics suit one application or service at a time, so blending them across teams or a whole organization is misleading.

• Four or five metrics. DORA's history page says it began with four variables: deployment frequency, lead time for changes, mean time to recover and change fail rate. In 2023 it renamed and redefined the recovery metric, and in 2024 it added deployment rework rate as a fifth metric.
• Reliability is not the fifth metric. The same page says the 2021 report inaccurately called reliability the fifth metric; reliability measures operational performance, not software delivery performance.
• Where recovery sits. Earlier descriptions grouped recovery time with stability; the current grouping puts it under throughput, with change fail rate and rework rate as instability.
• Lagging and leading. DORA describes the metrics as lagging indicators for delivery practices, so steer with leading indicators such as code review time.
• Stability data helps priorities. Fail and rework rates give you evidence in a tech debt versus features decision.
• What is not settled. This page cites no public source on what hiring panels expect, so the interview framing here is advice.

How to answer it in an interview

The spoken structure: name the outcomes, give the paired metrics, add the people signal, say you improve rather than rank, and end on one real change.

Common mistakes

• "We track commits and pull requests per engineer." (wrong) Activity is one SPACE dimension, and productivity is more than activity. (right) "Activity is one weak signal beside delivery and team-health measures."
• "Everyone must deploy more often; that is our goal." (wrong) DORA lists setting a metric as a goal as a pitfall. (right) "Deployment frequency is a signal; the goal is paired speed and stability."
• "DORA has four metrics, and MTTR is one." (wrong) DORA now has five, and MTTR became failed deployment recovery time. (right) "Five delivery metrics, in throughput and instability."
• "Our team is faster than the payments team." (wrong) DORA says to improve over time, not to compete, and to apply the metrics per service. (right) "We compare ourselves with our own baseline."
• "Moving fast means accepting more breakage." (wrong) DORA's research says speed and stability are not trade-offs. (right) "High performers do well on both, so I watch both."

Follow-up questions

What metrics do you use to evaluate engineering team health and productivity?

Name a small set of metrics and key performance indicators (KPIs): paired delivery metrics from DORA plus at least one people signal, such as a regular survey on satisfaction and friction, because productivity cannot be measured by a single metric or dimension. Say which you would look at first and why.

What successful metrics have you achieved, and how do you measure your team's success?

Pick one outcome you actually moved, state the baseline, the change you made and the result in your own numbers, and name the paired metric you watched to be sure nothing got worse. Do not borrow numbers you cannot defend.

How would your team game these metrics, and how do you stop it?

Any single number can be gamed, such as pushing many untested or half-finished deployments to raise deployment frequency. Reading it beside change fail rate and keeping the numbers for improvement, not for comparing people, removes most of the reason to game it.

Do speed and stability trade off?

DORA's research says they do not: speed and stability are not trade-offs, and high performers excelled at both. If speed rises while change fail rate rises too, that is a signal of rework, not a trade you must accept.

What do you do when a manager wants one productivity number?

Explain that DORA lists one metric to rule them all as a pitfall, offer a small set that includes a people signal, and agree what decision each number will inform. The stakeholder management for engineering managers page covers how to hold that conversation.

How do metrics change a tech debt versus features decision?

Metrics give you evidence: a rising change fail rate or rework rate shows the cost of debt in the units a roadmap understands. See how to build a roadmap and prioritize and delivery under pressure for the planning side, and how technical an engineering manager must be for how deep to go on pipelines.

Sources

1. DORA's software delivery performance metrics — DORA (Google Cloud), 5 Jan 2026
2. A history of DORA's software delivery metrics — DORA (Nathen Harvey), 2 Jan 2026
3. The SPACE of Developer Productivity: There's more to it than you think — ACM Queue (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler), 6 Mar 2021