Why a baseline = decision authority#

DORA metrics without a baseline are just a pretty dashboard. The zero point is what gives a leader investment arguments: how long it’ll take to shorten Lead Time, what budget a specific change touches, where the cheapest lever sits.

Week 1 — instrumentation#

1.1 Collecting raw events#

Wire up GitHub/GitLab webhooks into a simple endpoint that records push, pull_request, deployment, and incident events. You don’t need a SaaS yet — Vercel KV, Cloudflare D1, or a JSON file on S3 is enough.

1.2 Picking definitions#

Define “failure” in an auditable way. The most common heuristic: rollback within 24h OR hotfix deployed inside an incident OR a deploy explicitly named in a post-mortem.

Week 2 — first read#

Compute values for a rolling 14-day window and compare against SMB benchmarks. Don’t compare yourself to “Elite” from the DORA report for Google — that’s a different ecosystem. End-of-week-2 goal: one number for each of the four metrics and one hypothesis about your bottleneck.

Week 3 — first intervention#

Pick one bottleneck and propose one change with a measurable effect. Most often:

• High Lead Time → code review automation, smaller PR batches.
• High CFR → introduce a CI quality gate (tests, static analysis, vulnerability scan).
• High MTTR → runbooks + deploy previews + one-click rollback.
• Low Deployment Frequency → trunk-based dev + feature flags.

Week 4 — review at the table#

Present 4 numbers + one hypothesis + one intervention. The board should see that they’re not buying a “dashboard”, they’re buying a learning system that, after a quarter, returns a concrete saving in engineering hours.

A baseline isn’t a goal. It’s the start of the negotiation about where to deploy the next engineering hour.