What an operations dashboard should show, and what it should not.

The usual way a dashboard gets built is additive. Someone asks what we can measure, the systems answer, and the answers become tiles. The result is accurate, comprehensive and inert — a wall of numbers that describes the business without ever prompting anyone to do anything differently.

The alternative is to start from the decision. For each candidate measure, ask what you would do differently if it moved. If the honest answer is nothing, the measure may still be interesting, but it is not operational, and putting it on the same surface as the measures that do drive action dilutes all of them.

This is why the most useful dashboards are smaller than expected. Not because less information is better in principle, but because attention is the scarce resource and every tile spends some.

Try the question in the past tense instead: over the last three months, which number actually caused somebody to change what they were doing? That list is usually short and always revealing.

Mixing these together is the most common structural mistake, because it makes a dashboard impossible to read at a glance. A number that demands action today sits beside a number that is only meaningful across a quarter, and the eye cannot tell which is which.

Separate measures by what they are for:

• WORK IN HAND

  What is waiting, how old it is, and who holds it. This is the only category that is genuinely operational — it changes what somebody does this morning.

• FLOW

  How quickly work moves through, and where it accumulates. Read weekly rather than daily; useful for finding the constraint, not for reacting.

• QUALITY

  How often work has to be redone, returned or corrected. Slower still, and the most commonly missing category.

• OUTCOME

  Revenue, retention, capacity. These belong in a review, not on an operations screen; they move too slowly to guide daily behaviour and they invite the wrong kind of daily attention.

A figure on its own is rarely enough to act on. What turns it into a prompt is context: the comparison that says whether it is unusual, the owner who is expected to respond, and the route from the number to the underlying items.

That last one matters more than it sounds. A dashboard where you cannot click from the count to the actual records is a dashboard that generates questions somebody then has to answer manually — which is more work than before, not less.

Vanity measures are the obvious case, but the more damaging category is measures that are actionable in appearance and misleading in substance — usually because they are averages, or because they are counts of activity rather than of progress.

An average hides the distribution that matters. If most work completes in two days and a handful takes six weeks, the mean describes neither population and points at no action. The nine stalled items are the operational fact; the average of forty-seven is not.

Activity counts have a worse failure mode: they are easy to satisfy without doing the underlying work. Any measure that a person can move directly, without the outcome moving, will eventually be moved directly.

• AVERAGES WITHOUT A DISTRIBUTION

  Report the tail. Where the measure is about delay, the items above a threshold are the operational content and the mean is the noise.

• ACTIVITY AS A PROXY

  Calls made, messages sent, tickets touched. These measure motion, and motion is the easiest thing to produce on demand.

• MEASURES WITH NO OWNER

  If a tile moves and nobody is accountable for responding, it is reporting rather than operations, and it belongs elsewhere.

• RATIOS WITHOUT VOLUME

  A conversion rate over a small denominator will swing wildly and provoke reactions to noise. Show the count beside it or not at all.

Dashboards built from available data tend to grow; dashboards built from a recurring decision tend to stay small and get used. The practical starting point is the moment when the team already gathers, because that moment already has a purpose.

1. 01

   Name the recurring decision

   Decides

   What does somebody decide, and when?

   Output

   A named moment and a named decision the dashboard exists to serve.

2. 02

   List what would change the decision

   Decides

   Which facts would lead to a different answer?

   Output

   A candidate measure list derived from the decision rather than the data.

3. 03

   Check each against the system of record

   Decides

   Is this actually captured, reliably, today?

   Output

   An honest split between measures that exist and measures that need a process change first.

4. 04

   Give every measure an owner and a threshold

   Decides

   Who responds, and at what point?

   Output

   Each measure has a role attached and a defined unusual.

5. 05

   Build the smallest version

   Decides

   What is the minimum that serves the decision?

   Output

   A dashboard small enough to read in the meeting it was built for.

6. 06

   Review what was ignored

   Decides

   Which tiles changed nobody's behaviour?

   Output

   Measures removed, and the reason recorded so they are not re-added.

Reporting is downstream of capture. If a stage is marked complete when somebody remembers to mark it, the dashboard reports memory rather than work. This is the point at which reporting projects most often turn into process projects, and that is usually correct rather than a failure of scope.

The practical rule is that a measure is only as good as the moment the underlying fact is recorded. Facts captured as a by-product of doing the work — a record created, a status changed by an action rather than by a person tidying up — are dependable. Facts captured by a separate act of administration decay quickly, because administration is the first thing dropped under load.

1. 01

   Captured as a by-product

   Owner

   The system

   Advances when

   Reported directly with confidence

2. 02

   Captured by convention

   Owner

   The person doing the work

   Advances when

   Holds while the convention holds

   Ends when

   Degrades quietly under workload

3. 03

   Reconstructed afterwards

   Owner

   Whoever prepares the report

   Advances when

   Survives if one person keeps doing it

   Ends when

   Stops the week that person is unavailable

4. 04

   Estimated

   Owner

   Nobody

   Advances when

   Presented with the same confidence as the rest

   Ends when

   Discovered to be wrong during a decision that relied on it

The pressure to consolidate is understandable: one dashboard is cheaper to build, easier to maintain, and avoids the awkward question of which version is correct. It also tends to produce a surface neither audience reads, because the two are asking different questions at different speeds.

The person running the work needs to know what is waiting, what is late and what is theirs, this morning. They need depth on a narrow slice and a route from the figure to the records behind it. The person accountable for the business needs to know whether the shape of the operation is changing — whether flow is degrading, whether rework is rising, whether capacity is keeping pace — and they need that monthly, across the whole, with enough history to tell a trend from a bad week.

Built as one screen, each set of needs erodes the other. Daily tiles invite the owner to react to normal variation. Quarterly aggregates make the operator scroll past their own work. The usual compromise is a long page that nobody reads in full.

The resolution is not two disconnected reports. It is two views built on the same definitions — the same meaning of open, the same moment a job counts as complete, the same records underneath — presented at the cadence each decision actually runs at. Shared definitions are what make the two views reconcilable; shared layout is what makes them unreadable.

Where the two views disagree, the disagreement is the finding. It almost always means a stage is being counted at a different moment in each, and that is worth resolving before either number is trusted.

Dashboards fail quietly. Nobody announces that they have stopped reading one; attendance at the number simply drops and the tiles keep refreshing. Because the artefact still exists and still looks maintained, the failure can persist for a long time.

The signals are behavioural rather than technical. People ask for a figure that is already on the screen. Someone maintains a private spreadsheet alongside it. The weekly review opens the dashboard and then discusses something else. Each of those says the same thing: the measures no longer match the decisions.

The response is subtraction. Remove what nobody used, record why, and rebuild around the decision people are actually making now — which may not be the decision the dashboard was designed for.

1. A measure earns its place only if a change in it would change a decision; if nothing would be done differently, it is information rather than operations.
2. Separate work in hand, flow, quality and outcome — mixing cadences on one surface makes the urgent and the slow-moving indistinguishable.
3. A number becomes actionable when it carries a comparison, a named owner and a route to the underlying records.
4. Averages hide the distribution that matters, and activity counts can be satisfied without the underlying work happening.
5. Reporting inherits the honesty of capture: facts recorded as a by-product of the work are dependable, facts recorded by separate administration decay under load.
6. Dashboards fail behaviourally rather than technically — private spreadsheets and questions about figures already on screen are the signal to subtract and rebuild.