In this post
You do not need to read code to tell whether an engineering team is healthy. You need five questions your team can answer with real data in a few minutes, and the habit of asking for the answers in writing. This post gives you the five questions, the commands that answer them, and what we saw when we ran them on a public repository.
The numbers come from DORA, Google’s long-running research program on software delivery. DORA’s current guide defines five measures: change lead time (commit to production), deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate (DORA metrics guide). The first three describe throughput. The last two describe how often releases go wrong. We use the first three plus two founder questions that the guide does not cover.
Two cautions from the same guide apply before you start. Do not set a metric as a goal: DORA warns that a blanket target like “every application must deploy multiple times per day by year’s end” invites teams to game the number (the Goodhart’s law pitfall). And do not compare across very different systems, since the metrics are meant for one application or service at a time. Use these as conversation starters about one product.
The 15-minute agenda #
Put the five questions in front of the lead developer, ask for the answers as links or pasted output, and spend the meeting on the answers, not the setup.
1. How often do we ship, and what does a release look like? #
Ask for the list of releases with dates. In a Git project that is one command:
$ git for-each-ref --sort=-creatordate --format='%(creatordate:short) %(refname:short)' refs/tags | head -6
2026-08-24 v2.0.0.beta4
2026-08-23 v2.0.0.beta3
2026-08-23 v2.0.0.beta2
2026-08-22 v2.0.0.beta1
2026-08-22 v2.0.0.alpha1
2026-08-22 v1.15.1
That output is from the public snap_diff-capybara repository, a Ruby testing gem that JetThoughts’ Paul Keen contributes to most, read on 30 October 2026. It shows a burst of tagged releases over three days, then nothing for the next two months. A bursty pattern is not a verdict, but it is a question: “why three days of releases, then silence?” On your product you want the answer in a sentence.
If your product is a web app that deploys continuously rather than by tag, ask instead: “How many times did we deploy last month?” Your host or CI keeps the log.
2. How long from “finished” to in front of customers? #
This is DORA’s change lead time. A rough proxy you can get today is how long pull requests (the proposed changes) stay open before they are merged. With the GitHub command-line tool:
$ gh pr list -R snap-diff/snap_diff-capybara --state merged --limit 30 \
--json createdAt,mergedAt --jq '[.[] | ((.mergedAt|fromdateiso8601) - (.createdAt|fromdateiso8601)) / 3600] | sort | {prs: length, median_hours: (.[length/2|floor]*10|round/10), max_hours: (max*10|round/10)}'
{"max_hours":975.5,"median_hours":1.4,"prs":30}
Thirty merged pull requests between 24 August and 22 October 2026: median 1.4 hours from open to merged, slowest about 40 days. Be careful reading it. Two people opened those thirty pull requests, so a median of 1.4 hours says the merge button was close to hand, not that careful review happened. On your team, a long tail like the 40-day one is the interesting part. Ask what that change was and what held it.
3. When a release breaks something, how long until it is fixed? #
Ask: “What was the last production incident, how long did it last, and what changed afterwards?” This is failed deployment recovery time. A team that can answer with a date, a duration and a specific change has a working feedback loop. A team that cannot remember the last incident either has none or is not recording them.
4. If one person left tomorrow, what would we lose? #
This is the truck factor: the number of developers who would have to leave before a project stalls. A study of 133 popular GitHub projects found that 65 percent had a truck factor of 2 or less (Avelino et al., 2016). Ask your lead to run:
$ git shortlog -sn --no-merges --since="12 months ago"
212 Paul Keen
9 Diego Algorta
8 dependabot[bot]
2 Twill
1 twill-hq[bot]
Same repository, same date. Of 223 commits not labelled as bots, 212 come from one person. For a one-maintainer open source gem that is expected. For your company’s product it is a risk you should know about before it becomes a resignation letter.
5. Which part of the system does the team dread touching? #
There is no command for this one, only a question. Ask each developer separately and compare the answers. Martin Fowler’s Design Stamina Hypothesis explains why the answer matters: skipping design work buys speed in the short run and then “accumulates technical debt which will slow your productivity later” (Fowler, 2007). Areas that several people name are where your next slow quarter is coming from.
How to run the conversation #
- Ask for artifacts, not reassurance. “Send me the release list” cannot be answered with “it’s going fine”.
- Frame it as removing obstacles. You are asking so you can help. If the team hears an audit, you will get tidy answers.
- Compare against last quarter, not another company. DORA’s own guidance is to avoid comparing different systems. The useful signal is your trend.
- Write down one change per meeting. One slow review process or one fragile module. Check it next time.
What these numbers cannot tell you #
They say nothing about whether you are building the right product, and a team can score well on all five while shipping features nobody wants. They also depend on the team recording the data, and a small team may have no release log at all, which is itself a finding. If a question has no answer, an outside reviewer can establish a baseline. Our post on questions to ask a dev shop and the one on what to look for in a weekly update cover the next step.
If you want a team that reports on these without being asked, see how we work. JetThoughts is rated 4.8/5 on Clutch.
Sources #
- DORA, DORA’s software delivery metrics - the five measures and the pitfalls quoted above.
- Avelino, Passos, Hora and Valente, A Novel Approach for Estimating Truck Factors, ICPC 2016.
- Martin Fowler, Design Stamina Hypothesis, 2007.
- Commands run against snap-diff/snap_diff-capybara on 30 October 2026.
