Every company I've walked into in the last five years already had a DORA dashboard. Someone bought it, someone configured it, someone looked at it once. And in almost every one, nobody could tell me where lead time starts counting.

That's usually the whole problem.

The four metrics, ranked by how much they lie

Lead time — the liar. It lies because it starts wherever your workflow says it starts. Measured from "in progress"? That excludes the two weeks the ticket sat in the backlog waiting to be picked up. Measured from ticket creation? Bulk-closing stale tickets last quarter just cut your lead time in half without shipping anything. And the mid-Jira "waiting for approval" state that eats 80% of the real wait? Counts as zero.

Deployment frequency is the honest one because it's hard to fake — your CI either ran twelve times this week or it didn't.

Change failure rate — quietly gamed. Not dishonest, but elastic: what counts as a failure? If a rollback counts but a hotfix doesn't, you've defined your way to a good number. Teams learn the definition fast.

MTTR — survivorship bias in a chart. You measure recovery for incidents you detected. The slow ones, the ones a customer told you about three days in — they're underrepresented exactly to the degree they're embarrassing.

Deployment frequency — the honest one. Hard to fake, easy to check, boring. Trust it.

The move that makes lead time tell the truth

Read lead time and deployment frequency together. Each alone misleads; the pair diagnoses.

High deployment frequency with long lead time is the most common pattern I see, and it's not an engineering problem. The code ships fine. It sits. Somewhere between "done" and "deployed" there's an approval nobody wants to own — a security review, a release manager, a sign-off that exists in nobody's calendar and everybody's critical path. That's a management problem wearing an engineering costume, and no amount of pipeline optimization will fix it.

Low deployment frequency with short lead time is the mirror image: the team works fast, then batches. Small, safe changes accumulate behind a release train. The risk profile of every release goes up precisely because the process was designed to reduce risk.

What the metric is actually for

A DORA number is only worth having if it triggers the question "why". The number is never the finding — the argument it starts is. Lead time of 14 days tells me nothing. Lead time of 14 days where the code was done on day 2 and waited 12 days for a compliance checkbox tells me everything.

When we built our own engineering-intelligence board (one view over Jira, GitHub, GitLab and Azure DevOps — self-hosted, open-sourced after it changed our own first week in every client), we spent more time on where each clock starts and stops than on any chart. A metrics tool that can't tell you where its clock starts is a poster, not an instrument.

Repo if you want to see where our clocks start: https://github.com/Codpal-Limited/deckgauge — demo with a fictional org at https://demo.deckgauge.com

I'm Yaniv — fractional CTO. Where does your lead time clock start? Genuinely curious, because in five years I've gotten a different answer from every team that ever gave me one.