I ran an audit recently for a client whose analytics team felt overwhelmed without being able to articulate why. The team was modestly sized and reasonably staffed for the work the executive team was asking of them. The complaint, repeated by every senior on the team, was that they could not get to anything new because they were buried by maintenance.
The audit found four thousand seven hundred dashboards in their BI tool. About sixty per cent had been opened by fewer than three distinct users in the last ninety days. About fifteen per cent had not been opened at all in twelve months. The team was paying maintenance cost on every one of them.
What the tax looks like
Every dashboard is a permanent commitment to keeping it running. When the upstream schema changes, somebody has to update it. When the calculation behind a metric is corrected, somebody has to propagate the change. When the BI tool is migrated, somebody has to migrate it. When a stakeholder leaves and a new one arrives, somebody has to introduce them to it.
None of those costs are visible on the day the dashboard ships. They are invisible until aggregated, at which point they show up as a team that is permanently underwater.
Why it happens
Dashboard sprawl is not the result of bad analysts. It is the result of an asymmetric incentive. Building a dashboard is a positive event. The stakeholder is happy. The analyst gets credit. Retiring a dashboard is a negative event. There is no celebration. There is sometimes a quiet conversation with a stakeholder who has not opened it in a year but feels that removing it is a slight.
Without an explicit retirement discipline, you end up with a system in which the population of dashboards only grows. Headcount grows linearly while the maintenance burden grows super-linearly. The team's velocity drops, and the executive team starts asking why analytics is so slow.
The retirement protocol that worked
The pattern I now insist on with clients has three parts.
First, every dashboard has an owner and a stated purpose at build time. If neither is true, it does not get built. The purpose has to describe a decision the dashboard supports. Reporting for visibility is not a purpose. Track quarterly churn against the retention target is a purpose.
Second, every dashboard has a review date. Six months by default. On the review date, the owner has to confirm the dashboard is still being used to support the stated decision. If the owner has left or cannot confirm, the dashboard is archived.
Third, the analytics team runs a quarterly amnesty in which any dashboard with low usage is moved to a deprecated state unless the owner intervenes. Deprecation is not deletion. Anyone who needs the dashboard back can have it back. In practice, fewer than one in twenty deprecations is reversed.
What it returned
The client I audited ran their first amnesty four months after the audit. They retired or deprecated about sixty per cent of their dashboards. The team's velocity on new work approximately doubled inside a quarter. None of the senior stakeholders raised a complaint that survived a single conversation, because nobody actually wanted the dashboards that were retired.
The lesson is uncomfortable for analytics leaders, because the sprawl is partly our doing. We say yes to dashboard requests without negotiating retirement. We celebrate launches. We do not run amnesties. The discipline of retirement is one of the highest-leverage habits I have seen a function adopt, and one of the rarest. It is not glamorous. It also is not optional, not at the scale most teams are operating at now.