A Stable Dashboard Is the One to Worry About
The dashboard held steady for six weeks, so nobody checked it. The pipeline broke in March; the board's ARR slide was stale by $300K.
A dashboard that holds steady looks like a dashboard that works. Often it's the opposite. At one company, the ARR slide in a board meeting read $4.2M while billing said $3.9M, a gap already six weeks old. The pipeline feeding the dashboard had broken in March. Nobody noticed, because the dashboard kept producing a number, the number stayed flat, and flat read as fine.
The board asked, reasonably, why the founder had been reporting an inflated figure. He hadn't known it was inflated. The warehouse had drifted from production. The pipeline still ran. The transformations still executed. The dashboard still rendered values. None of the values were current.
A schema change in the billing system in early March had quietly broken the incremental load. The warehouse was serving a late-February snapshot plus cruft from partial loads in the weeks after. The numbers looked stable because the underlying data had stopped moving. No error. No alert. A slowly drifting set of figures nobody was checking against ground truth.
This is one of the most common quiet operational failures at growth stage, and it's structural. Pipelines are fragile. They depend on upstream systems whose schemas and APIs change without warning. The people who own them are usually a small data team busy shipping new dashboards, not maintaining old ones. When a pipeline breaks, it often breaks silently: the dashboard keeps emitting values, and the values stop being true.
Drift survives because gradual drift looks like stability. A number that repeats day over day looks healthy. A number ticking up looks like growth. The eye can't separate this is correct and rising from this is stuck while the company grows faster than the chart admits. Only reconciliation against an independent source catches the difference. It's the same discipline as reading your metrics off the right cohort before you trust the trend.
The reconciliation habit is small and almost always skipped. Revenue, weekly, against the billing system. Operational metrics like active users, support volume, and churn, monthly, against application-database queries. Everything else, quarterly. Fast enough to catch drift before it reaches a board slide. The work is unglamorous: a one- or two-page report comparing warehouse numbers to ground truth, with every delta explained or flagged.
The credibility cost of one wrong board number outruns any reconciliation budget. The founder's trust in the data team takes the hit. The board's trust in the next number takes it too. Neither comes back cheap. The following meeting opens with more skepticism, the data team second-guesses its own outputs, and leadership starts privately re-checking numbers before sharing them. That's the tax on a figure nobody reconciled, and it's the same quiet erosion I traced through a forecast that stopped being a forecast.
So budget reconciliation as scheduled work, owned by a named analyst or data engineer, with time on the calendar and the output surfaced to the head of finance. For each critical metric: the source-of-truth value, the warehouse value, the delta, and an explanation when the delta isn't zero. The deeper habit is upstream. Most pipeline breaks trace to a schema change in a source system that nobody thought to mention. Get the source teams to warn the data team before they ship, and half of these failures never happen.