Build a Team Dashboard — Engineering Metrics & DORA, Part 8

Engineering Metrics & DORA · Part 8

A metrics dashboard nobody looks at is just a more expensive way to not know how your team is doing. The useful kind is small, trend-based, and discussed on a schedule — not a wall of forty gauges. This walks through building a team dashboard people actually use: which five numbers to start with, why trends beat snapshots, and how to keep vanity metrics off it.

Metrics in spreadsheets are dead. Metrics on a dashboard live. Visible to the team; informs daily decisions.

Before you start

• Working instrumentation for at least two of the four metrics from Parts 2-5. A dashboard built on numbers you have not verified will be trusted for about a fortnight and then quietly ignored.

• At least a quarter of history. A dashboard that can only show today teaches nothing, because every one of these numbers is only meaningful as a trend.

• A decision about who this is for, made before you pick a tool. A team's working dashboard and an executive summary are different artifacts, and merging them produces something that serves neither — Part 10 is the other one.

• A named owner. Dashboards decay silently: a broken data source shows as a flat line, which looks like stability.

Step 1: Start With Five Numbers (10 min)

Don't dashboard 50 things. Pick 5:

• Lead time (median)

• Deploy frequency

• Change failure rate

• MTTR

• Open PRs awaiting review

Big numbers + trend. Glanceable.

Add more later if needed.

Step 2: Show Trends, Not Snapshots (10 min)

✓ Lead time over last 12 weeks (line chart)
✗ Lead time = 3 days (single number)

Trends tell a story:

• Getting better?

• Recent regression?

• Volatile?

Snapshots invite arguing about the moment.

Step 3: Per-Team Views (10 min)

If the org has multiple teams:

• Each team has their own dashboard

• Common metrics across all

• Per-team owners

Comparing teams: tricky. Different services have different risk profiles.

Use within-team trends > cross-team comparison.

Step 4: Pick Tools (10 min)

• Grafana — flexible; needs setup

• Datadog — integrated with metrics

• Custom — your own React app pulling from APIs

• LinearB / Swarmia / Cortex — paid engineering analytics

For a small team: Grafana free; works.

For larger: paid tools provide more out-of-the-box.

Step 5: Source the Data (15 min)

Most data sources:

• GitHub API (PRs, reviews, deploys)

• CI logs (deploy times)

• PagerDuty / Opsgenie (incidents)

• Survey tools (satisfaction)

# Pull GitHub PR data
prs = github.list_pulls(state="closed", since=last_month)
metrics = compute_metrics(prs)
store_in_db(metrics)

Schedule daily. Dashboard pulls from your store.

Step 6: Targets vs. Trends (10 min)

Some metrics have natural targets (DORA bands).

Others: just trends.

For targets:

• Color-code (green / yellow / red)

• Tied to band performance

For trends:

• Show the line

• Compare to prior period

Don't force targets on everything.

Step 7: Make It Visible (10 min)

- Channel pin in Slack
- Standup intro
- Office TV (or virtual)
- Linked from team wiki

Visible = remembered = improved.

Hidden behind 5 clicks = ignored.

Step 8: Discuss Regularly (10 min)

Weekly:

• Glance at dashboard

• Anyone notice anything?

• Anything to investigate?

Monthly:

• Deeper review

• Set monthly improvement focus

Without ritual: dashboard is decoration.

Step 9: Avoid Vanity Metrics (10 min)

"Code lines per week": 50,000 ⬆️

So what?

Each metric must tie to a decision:

• This tells us X

• If it changes, we do Y

• We track it for that reason

If no decision: drop it.

Step 10: Iterate the Dashboard (5 min)

Every quarter:

• Which metrics did we actually use?

• Which got ignored?

• What did we wish we tracked?

Update. Don't fossilize.

The "perfect" dashboard is the one your team actually looks at.

What earns space, and what quietly ruins it

The constraint that makes a dashboard useful is that it is small. Every number you add costs attention from the ones that matter, so each has to earn its place.

Element	Why it earns space	How it goes wrong
The four delivery metrics, as trends	They are the smallest set that describes both speed and stability, and they resist gaming at team level	Shown as a current value with no history. A number without a trend cannot be acted on
A distribution, not just a median	The tail is where the user pain and the on-call pain live	Only the mean is shown, so one four-hour incident disappears into an average
Open PRs awaiting review	It is the flow blockage most within the team's control, visible today	It becomes a per-person leaderboard, and you have built the anti-pattern from Part 7
Annotations for known events	An incident, a migration or a team change explains most step-changes	Absent, so every anomaly gets re-litigated from memory in the next review
A data-freshness indicator	A stale pipeline looks exactly like a stable team	Omitted — the most common way a dashboard lies without anyone noticing
Targets	Sometimes useful for a specific improvement effort with an end date	Left up permanently, at which point the target becomes the goal and the metric stops measuring

You're done when

• Every number on the dashboard traces to a query you can run yourself, and you have checked at least one against the raw data by hand.

• Every metric shows history, and the dashboard makes it obvious when the data last updated — so a broken feed cannot masquerade as a flat trend.

• Nothing on it is attributable to an individual, and you can point to a decision someone made because of something they saw on it. If no decision has come from it, it is a wall poster.

What You Just Did

Team dashboard: 5 numbers, trends, per-team, tools, data sources, targets, visible, discuss, no vanity, iterate. Dashboards that drive action.

Common Failure Modes

50 metrics; nobody reads. Visibility lost.

Snapshot numbers; no trend. Arguments about the moment.

Cross-team comparison. Resentment.

No discussion ritual. Dashboard decorative.

Same dashboard for years. Stale; ignored.

---

Sources

• DORA, DORA's software delivery performance metrics — current definitions and the five-metric set.

• DORA, Research — the State of DevOps report archive. Band thresholds live inside individual annual reports and differ by year.

• References & Sources — the version caveats that apply across everything on this site.

Continue the Engineering Metrics & DORA path

• Previous — Part 7: Avoid Metric Anti-Patterns

• Next — Part 9: Improve a Metric

Part of the Engineering Metrics & DORA learning path.