A performance dashboard that people stop arguing with

01

How the problem presented

Consider a monthly review where three teams bring different totals for the same measure. One counts bookings, another counts completed work, and a third removes cancellations. Before debating performance, I would reconcile those definitions and write the agreed rule beside the number.

Nobody was lying. Each figure was defensible on its own terms. One team counted on the date work was booked, another on the date it was completed, a third excluded cases that had been cancelled and later reinstated. Every rule was sensible. None of them was written down anywhere a fourth person could read.

That is the surface problem. The one underneath is worse. When a number can be argued with, the argument becomes the safest place for anyone under pressure to stand. A manager who does not like what a chart says about their site never has to defend the site. They only have to raise a question about the number, and questions are cheap when no definition exists.

02

Why dashboards get argued with

This is not really a reporting failure. It is a definition failure that shows up as a reporting one.

dbt Labs describes the same thing from the software side. Without a shared semantic layer, teams each write their own version of a common measure such as active users, and the reports disagree. A semantic layer is one shared definition of each measure that every report reads from. The remedy set out there is to define the measure once, hold that definition centrally, and reuse it everywhere rather than re-deriving it inside each dashboard.

I would keep metric formulas in a versioned register rather than bury them in separate dashboard queries. The register should show the owner, the current definition and why it changed. A new analyst should be able to reproduce the figure without asking the person who built the chart.

There is a matching danger in the other direction. A number can become the target while the work it was meant to represent is neglected. I would ask what behaviour each measure encourages and what it leaves unseen. Agreement about the arithmetic is necessary; it does not make the measure sufficient.

03

The metric contract I would use

I stopped building charts for a while. The first version of the work was a document, one page per measure, six lines each. I called it the metric contract, and it is the part I would hand anyone on a Monday morning.

Name. The words people already use in the corridor, not a database column name.

Question. The plain sentence this number answers, written so someone outside the function understands it.

Rule. The exact arithmetic. Which date it counts on. What is deliberately excluded, stated as a list, because exclusions are where disagreements live.

Owner. One person, named by role, who may change the rule and who answers for the number when it is questioned.

Source. The record the number is built from, and how a reader gets from the chart back to that record in one step.

Refresh and lag. When it updates, and how far behind reality it runs on a normal day.

Nothing reached the screen until all six lines existed. That deleted more measures than it created, which was the point. Several things we had reported for years could not survive being written down, because there was no agreed rule behind them, only habit.

Two build decisions mattered more than I expected. The definition sits beside the number on screen, one click away, so a challenge has somewhere to go that is not the meeting. And every tile drills down to the underlying records rather than stopping at a total.

A number you cannot trace back to a record is a rumour in a nicer font.

04

What I would measure

The review should move from disputing the arithmetic to explaining the work. I would check whether people can reproduce a figure and identify the action it requires. That is the intended result of the metric contract, not a result to assume.

Owners began correcting definitions in the days before the meeting rather than defending figures during it. Some sites that had looked weak turned out to have been recording differently. A few that had looked comfortable were not, and that was harder to sit with than the first group. The dashboard got smaller and people looked at it more often.

It did not make me popular straight away. Writing a rule down removes the freedom to pick whichever interpretation flatters you, and the people who had been using that freedom noticed quickly.

At the operating review, ask the relevant owner to explain the source and movement of a measure. Rotate the measures examined so that readiness cannot depend on one well-rehearsed chart. The purpose is to keep definitions usable after the initial dashboard project ends.

05

What I would do differently

Fewer measures at the start. I wrote contracts for too many at once and the quality of the later ones showed it.

Name the owner before writing the rule. I did it the other way round. Ownership is where an argument actually ends, and a rule with no owner is an opinion in a template.

Build the path back to the record first. I treated the drill-down as a refinement for later. It turned out to be the load-bearing part, because it is what lets a sceptic check a number themselves instead of asking me to.

Agree in advance what happens when a definition changes. Version it, date it, and mark the chart at the point of change. Without that, history quietly rewrites itself and you spend the credibility you have just earned.

I would keep targets off the first version until the team can reproduce the measures. Agree the definitions, review a sample of source records, then discuss which decisions the dashboard should support.