The 90/90 rule for the dashboard dumpster
A scream test for your reporting layer
Dashboard sprawl is a very common problem for data-driven organizations. Complaining about a lack of trusted dashboards is another one. Business stakeholders rarely understand that these two are the opposite sides of the same coin.
Stakeholders usually push for velocity, self-serve, and removing red tape. But a single source of truth requires friction and access control, by definition. You can’t have both for free. It is not that dissimilar from aiming for fewer incidents and bugs in software engineering. Either you go fast and break things, or you go slow and introduce friction by reviewing every change with a magnifying glass. AI is probably making this worse rather than solving it, with the increase in the amount of software generated.
I don’t think there is a silver bullet for dashboard sprawl, but only mitigation and hygiene. A while ago, I pulled some usage stats about how many dashboards we had in our reporting surface (either created by us or by business teams), and how many had been opened at least once in the previous quarter. The first number was in the hundreds, the second in the dozens. Roughly 9 in 10 data artifacts were dead. Dead but still running, scheduled, refreshing on a cadence, issuing expensive queries against the data warehouse every morning to render charts that nobody would look at.
Data teams and businesses in general accumulate these data artifacts because creation is more visible and sellable than deletion. Deprecation and sunsetting are valuable but thankless work. Hard to get promoted with deprecations. Not impossible, if the savings are significant, but hard. The incentive structure points more in one direction, so the catalog only grows. I have never seen a data team in trouble because it built too little.
If you cannot stop sprawl, the second-best option is to manage and contain it. This fix has four parts.
Instrument everything
You need good telemetry about usage. Total views, unique viewers, last refresh, last query date, owners. The BI layer must be able to tell you that, it is the first gap to close if it can’t. Ideally you should also collect cost data (queries run, compute, storage), because it will be handy for step 4.
Apply the 90/90 rule
No views in 90 days: the artifact gets archived. Archived means stopping the refresh and hiding the report from search and navigation. It remains recoverable in one click. This is a scream test: you remove access and wait to see if anyone screams.
Silence for another 90 days means deletion. Depending on the BI stack, deletion could be soft delete (e.g. the code stays in version control), or hard delete and the dashboard is nuked for real. This step is the one that gets the most pushback. Archiving feels safe and deleting feels irreversible, so people propose keeping everything archived forever. That is the goal of the second 90-day period, to force thinking and a decision while the context is still fresh.
Exempt the certified tier
Some dashboards have limited usage and are opened twice a year but still matter. So it’s safer to maintain a small certified tier immune to the 90/90 rule. You can leave that dashboard built only for the CTO alone.
Count deletions like launches
Once a quarter, communicate what was removed and take a victory lap. Artifacts deleted, pipelines switched off, storage saved, compute spared. These numbers make this maintenance work visible and relatable to leadership.
The 90/90 rule is a hacky solution, it does not fix the incentive structure, but it is a decent workaround worth a shot.
Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews