DORA Metrics vs Cycle Time: What Each Reveals

Your engineers can rattle off DORA metrics, deployment frequency and cycle time without missing a beat. Those numbers have never told you whether the team is performing or just staying busy. That disconnect is common.

Most founders in this position are not missing data. They are missing interpretation. You get sprint reports, velocity charts and burndown graphs. None of it tells you whether delivery is getting better or worse, or why. I see founders ask the right questions and never get a plain answer about what these numbers mean for the business. That gap is fixable.

By the end of this article you will know which engineering metrics to track, what each one implies for your business rather than just your codebase, and what to do when a number looks wrong.

What the four DORA metrics are actually measuring

DORA stands for DevOps Research and Assessment. It is a research-backed framework, not a trend. The four metrics split into two pairs: throughput and stability. Think of a restaurant kitchen. A kitchen that produces plates fast but sends half of them back is not performing well. Throughput without stability is noise.

Deployment frequency and lead time: the speed pair

Deployment frequency is how often your team ships working software to real users in production. Lead time for changes is how long a change takes to travel from a developer's first commit to running in production. A team that deploys every few days has a cadence. A team that deploys once a month is constrained somewhere, and that constraint matters. If lead time is measured in weeks, there is a process problem worth finding.

Change failure rate and MTTR: the stability pair

Change failure rate is the percentage of deployments that break something in production and need an immediate fix or rollback. MTTR, or mean time to recovery, is how long the team takes to restore service once something fails. An MTTR measured in days rather than hours means the team lacks the tooling or process to respond quickly.

Together, these two tell you how much of the team's time goes on cleaning up its own mess instead of building new things. The DORA research program publishes the definitions and current benchmarks, so you have a factual baseline instead of a gut feeling.

Which engineering metrics should a non-technical founder track?

Not every metric is worth tracking at every stage. The goal is the minimum useful signal for where you are now, not a dashboard nobody reads.

What to track before Series A

Three metrics are enough: how often you ship (deployment frequency), how long work takes to reach users (cycle time), and how often you break production (change failure rate). If deployment frequency is low, cycle time is high and the failure rate is high, you have a process or structure problem. The pattern is clear without a technical background.

What to add once you scale past one team

When several squads work in parallel, MTTR becomes critical because incidents take longer to resolve with more moving parts. Lead time for changes starts to show whether your deployment pipeline is scaling with the team. WIP across teams surfaces coordination problems that look like slowdowns but are hard to diagnose from standups alone.

Cycle time and WIP: the two signals DORA does not give you

DORA tells you what ships and how often. It does not tell you where work stalls before it ships. Cycle time does. It is the elapsed time from when a developer starts a task to when that task reaches production. It often exposes the real problem: work piling up in code review, waiting for a decision, or stuck in a queue nobody mentions in standups.

Work in progress, or WIP, is the companion metric. It counts how many tasks are in flight at any moment. High WIP almost always drives inflated cycle time. Together these two numbers say more about delivery health than velocity does.

Where the hidden delays live

A bloated cycle time usually points to one of three things. Tasks sit in code review for days. Approvals bottleneck on one senior developer. Or work is technically done but not deployed because releases are batched. A team can close plenty of tickets every sprint and still have a long median cycle time because nothing ships independently. The tickets get done. The work does not reach users. I covered how to find where work waits in finding the bottleneck in your tech team's workflow.

Why WIP limits matter more than velocity

A team working on twenty things at once is fragmented, not productive. WIP limits force the team to finish work before starting more, which directly reduces cycle time. You do not need to understand Kanban to act on this. If your team consistently has more items in progress than completed, start there.

How to pull these numbers without a data team

Jira, GitHub, GitLab and most CI/CD systems already capture this data. The real work is making sure those systems are wired together correctly.

What your existing tools already track

Jira's cycle time report shows the median cycle time for shipped work items and flags the ones that took unusually long. GitLab's built-in analytics surface deployment frequency and lead time if deployments are linked to the right production environment. GitHub's workflow analytics give a partial picture of delivery speed.

The first step is simple. Ask your engineering lead to confirm that the production environment is consistently labeled and that Jira items are linked to branches and pull requests. That one setup step unlocks most of the built-in reporting. Without it, the numbers are incomplete or quietly wrong.

A founder dashboard: four cards, one page

Four metrics are enough for a monthly view:

• Production deployments per week, trended over 12 weeks
• Median cycle time and the 75th percentile, so outliers are visible
• Change failure rate as a percentage
• Average MTTR

Four to six numbers with a 12-week trend line is enough to see whether things are improving, flat or degrading. For GitHub-native teams, LinearB and Sleuth are low-effort options that surface all four DORA metrics without custom queries. GitLab teams can start with the native Value Streams Dashboard.

Reading trends correctly and avoiding the traps

A single data point means almost nothing. A trend over 8 to 12 weeks tells you whether the team is getting better or worse at delivering software. The direction matters more than any individual number.

Why a rising number is not always good news

A jump in deployment frequency can mean the team is shipping more value. It can also mean they started counting staging deployments as production, or split one feature into many tiny releases to hit a target. If deployment frequency improved but customer-reported bugs also rose, something in the definition or the incentives changed.

Always pair deployment frequency with change failure rate over the same period. If frequency went up and the failure rate climbed with it, you are seeing instability shipped faster.

The three patterns that signal a real problem

Cycle time that keeps growing sprint over sprint means work is accumulating and not finishing. MTTR stretching into days means the team cannot respond to incidents efficiently. A change failure rate that is high and not trending down means the team is consistently shipping before the work is ready.

None of these is fixed by hiring another developer. Each points to a process, role or workload problem. Adding headcount to a broken system makes it more expensive, not faster. I wrote more on that in why more developers did not fix delivery.

When a metric shows a problem, here is what to do first

Every metric problem has a specific first response. The goal is a targeted question that narrows the cause, not a long investigation.

First actions for each common problem

High cycle time. Pull the slowest items from the last sprint and trace each one to where it stopped moving. Most often it is code review wait time or a dependency on one person. That tells you whether the fix is a process change or a role gap.

High change failure rate. Read the incident log for the last 30 days and count how many failures share a root cause. It is usually a testing gap or an unclear definition of ready to ship. The repetition in the log is the signal.

Low deployment frequency with a busy team. Count the manual steps between a merged pull request and a production deployment. Manual approval chains and hand-offs are where deployment cadence quietly dies.

When you need an outside read

Data is half the answer. The other half is knowing which problem to fix first and whether the root cause is process, people, roles or tooling. Founders without a technical background often get stuck here. They see the number but cannot act on it without risking an expensive mistake, like hiring more developers when the real bottleneck is the review process.

The short version

You do not need to become a metrics expert. You need enough signal to ask the right questions and notice when something is wrong. The four DORA metrics cover throughput and stability. Cycle time and WIP show where work stalls before it ships. A simple dashboard with a 12-week trend line beats a complex analytics setup nobody opens.

Start with deployment frequency, cycle time and change failure rate. Add MTTR and lead time for changes once you have multiple teams. Pair every metric with its guardrail, and treat a rising number with the same skepticism as a falling one.

If your metrics are moving the wrong way and you cannot tell why, that is what a diagnosis is for. Book a free 30-minute call. No pitch, no fixed packages, just a clear place to start looking.