A company can become much better at collecting data without becoming much better at understanding what is happening.
That distinction interests me because the technical part of reporting has become remarkably easy. A small company can connect its CRM, accounting system, advertising platforms, support software, product analytics, and operational tools to a dashboard that would have required a dedicated reporting team not very long ago. The result can look impressive: revenue, pipeline, conversion, churn, utilization, response time, margins, forecasts, dozens of charts updating automatically.
And yet someone still has to look at all of this and decide whether anything requires attention.
The dashboard solved the problem of assembling numbers. It did not necessarily solve the problem of producing management information.
The number needs a reference point
Consider a simple example. Monthly gross margin is 41%.
There is nothing wrong with the number. It may be perfectly accurate. But by itself, 41% tells a manager surprisingly little.
Was the plan 48% or 38%? Was gross margin 44% last month? Has the definition changed? Is the movement concentrated in one product line? Did pricing change, did input costs increase, or did the customer mix shift? Is this a temporary effect that was expected, or the beginning of something management did not anticipate?
The same problem appears with almost every operating metric.
Sales pipeline is $3.2 million. Customer response time is 47 minutes. Utilization is 72%. Net retention is 93%. Inventory is $1.4 million.
These are measurements. They become useful information only when placed in enough context to answer a more important question: is something happening here that changes what we should think or do?
This sounds obvious, but a surprising amount of reporting stops before that question.
A dashboard and an operating system are different things
One reason is that dashboards are naturally organized around metrics. Management is organized around exceptions, causes, trade-offs, and decisions.
Those are different structures.
GitLab's public KPI documentation is an unusually visible example of this distinction. Its KPI framework does not treat a KPI simply as a number. The documented components include the definition, data source, calculation method, target, forecast, actual result, and other reference values. GitLab also assigns health states to performance indicators, including whether something is acceptable, requires attention, represents a problem, or remains unknown.
The interesting part is not whether another company should copy GitLab's system. Most probably should not. The interesting part is that the number is only one object inside a larger information structure.
That structure begins to answer questions a raw dashboard cannot answer reliably. What exactly are we measuring? Compared with what? Who owns it? Is the deviation meaningful? Do we understand why it happened?
Once those questions are included, reporting starts moving from measurement toward diagnosis.
Making the abnormal visible
This idea predates modern business intelligence by decades.
Toyota's history of its production system describes the use of andon boards and lights on production lines. When an abnormal condition appeared, it became immediately visible so that a supervisor could come to the source of the problem and address it. Toyota described this as part of "management that can be seen with the eyes."
A factory production line and a SaaS company obviously operate very differently. I would not try to turn andon into a generic management metaphor.
But there is a useful principle underneath it.
A good information system does not merely make activity visible. It makes abnormality visible.
That is much harder.
To know that something is abnormal, the system needs some understanding of what normal looks like. A target may provide that reference. So might a forecast, historical range, service level, cohort pattern, operating plan, or simply an explicit management expectation.
Without a reference point, more visibility can actually create more work. Every number becomes something that someone has to inspect manually.
The context around the metric may matter more than another metric
This is where reporting systems often expand in the wrong direction.
When managers feel they do not understand the business well enough, the natural response is to add more metrics. Another chart is created. Another source is connected. Another segmentation is requested.
Sometimes that is exactly what is needed. But often the missing information is not another metric. It is context around a metric that already exists.
Imagine that revenue is 8% below forecast.
The useful next layer is probably not eleven additional revenue charts. It is an explanation of where the variance came from, whether the cause is understood, whether it is expected to continue, who is examining it, and whether management needs to make a decision.
This changes the object being reviewed.
Instead of:
Revenue: $920,000
the management information becomes something closer to:
Revenue: $920,000 versus $1,000,000 forecast. The variance is concentrated in enterprise renewals, where three expected contracts moved into the following month. Two are signed and awaiting effective dates; one remains unresolved. No change has been made to the quarterly forecast yet.
The second version contains only a little more data. But it contains much more information.
It tells the reader where to look and, equally important, where not to look.
Metrics can also become dangerous when they acquire too much authority
There is another side to the problem. Once a number becomes visible, consistent, and easy to compare, organizations tend to give it authority.
Sometimes more authority than it deserves.
Amazon's engineering leadership recently discussed this problem in the context of measuring AI adoption. The company noted that input measures such as AI-tool usage or coding throughput can be useful, particularly because important outcomes may take longer to appear. But it also warned that such metrics can drive negative behavior when they become targets detached from the outcomes that actually matter. Amazon's suggested response is not to abandon measurement, but to examine the relationship between inputs and outputs and investigate unusually high and low cases.
That is a useful distinction well beyond AI.
A metric can be accurate and still be a poor representation of the thing management actually cares about.
Customer tickets closed can rise while customer problems remain unresolved. Sales activity can increase while pipeline quality deteriorates. Employee utilization can improve while delivery slows because too little capacity remains for unexpected work. A company can improve the number and make the underlying system worse.
The metric is evidence. It is not the business itself.
What I would want to know before adding another dashboard
When I look at an operating reporting process, I increasingly think the useful question is not, "Do we have the right dashboard?"
It is closer to: When something important changes, how does that change become visible, acquire context, and reach the person who can decide what to do about it?
That question follows the information rather than the software.
A metric first has to be defined consistently enough to be trusted. There needs to be some meaningful reference point. A deviation has to be large or unusual enough to deserve attention. Someone needs to investigate what is behind it. And the explanation has to survive the journey from the person closest to the work to whoever is making the decision.
Every break in that chain creates a different failure.
If the definition is unstable, people debate the number. If there is no reference point, they do not know whether it matters. If nobody owns the exception, everyone sees it, and nobody investigates it. If the explanation disappears as information moves upward, management receives a clean chart and an incomplete picture.
Adding another dashboard does not fix any of these problems.
The reporting burden changes when the objective changes
There is a practical consequence to this.
If the purpose of reporting is to reproduce the entire state of a business every week or month, reporting will naturally become larger as the company becomes more complex. More products create more metrics. More teams create more reports. More investors or executives create more requests.
But if part of the purpose is to identify where reality has meaningfully departed from expectation, the system can work differently.
Stable areas need less explanation. Exceptions need more. A metric that is on plan and behaving normally may deserve only confirmation. A metric that moved sharply may need several paragraphs and investigation behind it.
That is not less rigorous reporting. In many situations it is more rigorous, because attention is being allocated according to what needs to be understood rather than according to how many numbers happen to exist.
There are limits, of course. Not every important change is visible in an existing KPI. Thresholds can hide gradual deterioration. New risks often appear first as anecdotes, customer behavior, or operational friction rather than a clean quantitative exception. Judgment remains necessary.
But that is precisely why I would be reluctant to treat the dashboard as the management system.
The dashboard is one layer.
The more difficult layer is the mechanism that decides what deserves attention, adds enough context to understand it, and connects that information to a decision.
A company can have excellent data infrastructure without that mechanism. When it does, the problem is no longer a lack of information in the technical sense.
There may simply be too much measurement and not enough interpretation.