The CFO Didn't Want Better Dashboards

The call came in from Metro's corporate digital team, and I can still quote it: "Croatia says their local tool gives them functionality we don't have. Go show them what the platform can do. They just need to see nice charts."

So we built the nice charts. Interactive, fast, insightful — the kind of demo that wins a room. We flew to Zagreb and presented to the CFO, the financial controller, operations, and IT.

The CFO watched the whole thing and said: "This looks great. But this is not what we need."

What they needed, it turned out, was every invoice line in the business — store, item, customer, day — rolled up instantly from the CFO's view to the store floor. Sales, margin, inventory. Distinct counts of customers and articles that most engines choke on. A daily load that had to finish inside two and a half hours. Corporate KPIs and local KPIs side by side. And one constraint that settled the matter: no schema changes allowed.

The person who laid that out wasn't from Zagreb at all. He was an experienced controller from Metro's Serbian business, and the CFO had brought him in from Belgrade for this project because he trusted him from earlier work. He knew the business down to the invoice line and he could write the SQL to prove it — so when he said what the layer had to do, there was no argument left to have. We engineered the solution. He was the business mind behind it from the first day, and the project would have been a different project without him.

That meeting taught me the pattern I have watched repeat for fourteen years, in every industry we've worked in: everyone wants the visualization. Nobody wants the layer beneath it.

Everyone wants the dashboard. Nobody wants the layer underneath.

It isn't malice, and it isn't ignorance. It's visibility. A dashboard is something a leadership team can see, click, and show the board. The data layer underneath — the grain, the definitions, the pipelines, the lineage — is invisible when it works. The only time it becomes visible is when it fails, and by then the conversation is about the dashboard that showed the wrong number, not the layer that produced it.

So budget flows to what can be seen. The visualization gets the project, the sponsor, the launch. The layer gets whatever is left, and a quiet assumption: the data is fine; we just need a better way to look at it.

In the manifesto that opened this series I called the customer-facing agent on weak foundations "fresh paint on a cracked foundation." The dashboard was the original paint. Same logic, one generation earlier: a real improvement at the surface, financed by an untreated condition underneath — and the better the surface looks, the longer the condition goes untreated.

What "data you can trust" actually means

In Zagreb we did not defend the tool. We redesigned the system — the modeling, the partitioning, the aggregation strategy, the caching, the row-level security — so that the layer could carry the business the CFO described. After several months, 150+ daily users were working on invoice-level data with sub-second roll-ups, from the finance office to the shop floor.

Romania saw what Croatia had built and wanted the same capability. But Romania was a different problem: more stores, greater volumes, 300+ expected users, and a legacy platform so rigid that even minor changes were painful. We didn't copy the dashboards. We carried the architecture into a larger environment, replaced the legacy platform entirely, and extended what it could do — deeper drill paths, sharper margin logic, and every morning a set of daily sales and margin reports delivered to corporate automatically. If anything failed, corporate knew, the CFO knew, and we heard about it before breakfast. And once again the layer had a business mind behind it on the client side: a BI specialist who understood what the stores needed and what the database could give, and who held both sides of every conversation.

Two countries. Different operating realities. The same discipline underneath.

Today that is 450+ people, every day, on invoice-line granularity — not because the visualization is pretty, but because the layer underneath was engineered rather than assumed. And it has outlived its own infrastructure: when the warehouse behind it later moved from Teradata to Google BigQuery and the migration struggled, what we protected first was not the dashboards. It was the KPI definitions.

The charts can be rebuilt in a week. The agreement about what "margin" means cannot.

That experience is the most useful definition of the data pillar I know, because it is written in outcomes rather than adjectives. Data you can trust means:

One governed meaning per metric, with a name next to it. Finance margin and operations margin may legitimately differ. What may not differ is whether the organization knows which one it is looking at, who owns it, and why.

Granularity preserved to the grain. The invoice line, the transaction, the event — kept, not pre-summarized into something that can never be questioned again.

Pipelines that fail loudly. You learn a feed broke from a monitor, not from a business user holding a stale dashboard.

Lineage you can walk. From any number on any screen back to the rows that produced it, by someone other than the person who built it.

Definitions that survive a migration. If moving the warehouse changes the numbers, you never had definitions — you had a coincidence.

None of this is exotic. All of it is unglamorous, and all of it is exactly what gets cut when the budget is for "a better way to look at the data."

What the faked version looks like

You already know it, because every enterprise has run on it. Two reports disagree, and an analyst reconciles them by hand before the meeting — every month, forever, while the root cause stays. A metric has four meanings and the meeting uses the one that suits the argument. A column was repurposed in 2019 and nobody wrote it down. The dashboards agree because a skilled team made them agree in the presentation layer — the story I told about a Fortune 500 financial services client, and the reason the warning we put in writing there was about architecture, not charts.

The faked version has a tell: it depends on specific people being present to make the numbers trustworthy. Not people who govern the layer — every real system needs those — but the one analyst who remembers which revenue table is the live one and which exception was approved verbally three years ago. Take that person out of the room and the layer reveals itself. The controller from Belgrade and the specialist in Romania were the opposite case: people who knew the business well enough to design the layer so that it would hold without them. Same ingredient, opposite architecture. Ownership — the pillar that decides whether trust is structural or voluntary — gets its own installment later in this series.

Why the model is the harshest reader you've ever had

For fourteen years we have built systems where a wrong number doesn't just make an embarrassing dashboard. It moves a purchasing decision, a price, an inventory position, a daily finance report, the operations of hundreds of stores before nine in the morning. Data quality, in that world, is not an architectural virtue. It is an operational requirement, and you learn what it costs when it's missing.

Through all those years the consumer of the data layer was a dashboard, and behind the dashboard a human — someone who would squint at an odd number, remember the migration last quarter, and ask a colleague before trusting it. That human was a quality gate the architecture never had to pay for.

A model is a different kind of reader. It can spot a contradiction — but it cannot know which side of it is true unless someone wrote that down somewhere it can read. It does not know the second revenue table was deprecated in 2022, or that finance and operations mean different things by "margin." Without that context it turns every unresolved ambiguity into an authoritative answer — fluently, confidently, at scale. Point it outward on top of a faked layer and you have built a machine for distributing your reconciliation debt to your customers.

That is why the move into AI was a pass for us and not a pivot. Data and analytics are the foundation. AI is the acceleration layer. The discipline of cleaning, structuring, and semantically aligning enterprise data did not change when the consumer changed from a dashboard to a model. Only the tolerance did. The dashboard forgave what the model will amplify.

And it is why the inward-facing agent from the manifesto has its first and best job here. Point it at the estate and have it find the tables that disagree, profile the columns nobody can explain, draft the meanings for the humans who own them to confirm, and map the lineage nobody had the capacity to document. It is the audit every data team wanted for a decade and never got budget for — and it is now the fastest way to find out whether your layer was engineered or assumed, while the only audience watching is you.

The CFO in Zagreb was right, and he was right about more than he knew. The charts were never the point. The point was whether the thing underneath could hold the business — and now, whether it can hold a reader that will turn every unresolved ambiguity into a confident answer.

If you believe your data layer is ready for that reader, test the belief rather than the dashboards. We built a short assessment around the four foundations — about ten minutes, a scored result, no sales call. The first five questions are about exactly this layer: meaning, granularity, reliability, lineage, resilience. Tell it where you think you are; it tells you where the evidence says you are.