Perspective
Decision signals versus dashboards: why more charts made it worse.
A dashboard displays the state of the business. A decision signal asserts that one specific thing now requires a decision, names who owns it, and carries the evidence behind it. The difference is not presentation. One is a description and the other is a demand, and only one of them changes what happens next.
The dashboard that nobody opens
Most organisations that have built dashboards have also quietly stopped looking at them. Not all at once, and nobody announces it. The link stays in the bookmark bar. The weekly cadence slips to fortnightly. Eventually someone screenshots one chart into a deck and the dashboard's actual role becomes supplying that screenshot.
This is usually treated as an adoption problem, which invites an adoption solution: training, a redesign, a champion, a better tool. Those are expensive and they do not work, because the problem is not that people will not look. It is that looking is the wrong verb.
What a dashboard is for, and what it is not for
A dashboard answers questions you already know to ask. That is a genuine and useful function. If you want to know current utilisation, or this month's volumes against last month's, a dashboard is the right instrument and nothing else beats it.
The trouble starts when a dashboard is asked to do the other job, which is to tell you about the thing you did not know to ask about. It cannot, and the reason is structural rather than a failure of design. A dashboard is a passive surface. It waits. It shows the state of everything with equal weight, and equal weight is the same as no weight. Finding the one thing that matters among forty tiles that all look equally important is a task, and it is a task you have handed to the most expensive people in the organisation, to be done in whatever attention they have left at the end of a day.
Adding more charts makes this worse, not better, and does so in direct proportion. Every additional tile lowers the average importance of a tile.
What a decision signal is
A decision signal has four properties, and something that lacks any one of them is a chart.
It asserts. It does not display a value, it makes a claim: this has crossed a threshold that was agreed in advance.
It is owned. A named person is responsible for the response, and that name is attached to the signal rather than looked up afterwards.
It carries evidence. The basis of the claim is one step away, not a separate investigation.
It is bounded. The set of things that can produce a signal is small, defined, and agreed by the people who will receive them. If anything can raise a signal, nothing does.
Read that list again and notice that three of the four are not display properties at all. They are decisions about how the organisation works. This is why buying a better visualisation tool does not produce decision signals, and why a firm that already has good dashboards can still be flying blind.
The ranking problem
Suppose you solve everything above and leadership now receives signals rather than charts. On a given morning there are nine of them.
Which one first?
If the answer is "whichever the most senior person mentions", or "whichever arrived most recently", you have rebuilt the original problem at a smaller scale. Ordering has to be a rule, agreed in advance, applied the same way every morning: a priority queue, with an explicit ranking basis, that anyone can interrogate. A queue whose order can be argued in the meeting is not a queue, it is an agenda.
The ranking rule is where most of the real disagreement in an organisation surfaces, which is uncomfortable and also the most valuable part. Two divisions that rank exposure differently have been making inconsistent decisions for years. Nobody noticed, because the inconsistency lived in individual judgement rather than in a written rule.
Latency, which is the whole argument
Every property above serves one end, and it is worth stating plainly because it is the thing that gets lost in conversations about reporting.
The value of knowing something falls with time, and it does not fall smoothly. It falls off a cliff at the moment the options close. A cost that could have been avoided on the Tuesday cannot be avoided on the Monday. A conversation that could have been had before the customer escalated cannot be had after. The information is identical. Its value is not.
A dashboard is indifferent to this. It shows you the same figure with the same emphasis whether you are four hours or four weeks from the event. A decision signal is built around it: the threshold, the owner and the time limit exist precisely to compress the distance between the event and the person who can still act.
That is the sentence worth taking away. Reporting latency is not an inconvenience. It is the mechanism by which a manageable operational fact becomes an unmanageable financial one.
What to do with an existing dashboard
Keep it. This is not an argument for throwing away reporting, and the firms that do usually rebuild something similar within two years.
Do something narrower. Pick the three things that, if leadership learned about them a week late, would cost the most. For each, write down the threshold at which it becomes a decision, the person who owns that decision, the evidence that must accompany it, and the time within which it has to be acted on.
Four lines each. Twelve lines in total.
If those twelve lines are hard to write, that difficulty is the finding, and no dashboard was ever going to fix it.
Terms used on this page: Decision signal, Priority queue, Exception surfacing, Trend inflection.
Where this leads