Data teams get credit for what they build. They rarely get credit for what they turn off. When you turn off the dashboards, pipelines, and tables nobody uses, you cut cost faster than any new build can.
A dashboard for one meeting
A team builds a dashboard for one meeting. The meeting ends. The dashboard stays.
A pipeline feeds a report that someone replaced last year. The pipeline still runs every night. Someone copies a table for a quick test, and the copy becomes a source.
Nobody planned the pile. Each piece made sense on the day someone built it. Nobody owns the decision to stop it.
What the pile costs
This looks like harmless clutter. It is not. Every piece in the pile costs something:
- Compute and storage, every day it runs.
- Alerts and failures that someone has to read.
- Time from engineers who fix things nobody uses.
- Trust, when two tables give two answers to the same question.
The last cost hurts most. When a leader finds two numbers for the same metric, they do not ask which table is old. They ask if they can trust the data team. That is a trust problem, and a new tool does not fix it.
When a data team falls behind, it builds something new. Each new model or dashboard adds to the pile.
Count the assets that someone uses to make a decision. That count is your value. The rest is work.
I wrote before about automation drift, where routines keep running long after their need has passed. A pipeline with no user is the same problem.
Find what to turn off
Start with the assets that cost the most or cause the most noise. For each one, ask:
- Who used this in the last 90 days? Use the access logs, not memory.
- Which decision depends on it?
- Does another table or dashboard answer the same question?
No user and no decision means it is a candidate. When two assets answer the same question, keep one and retire the other.
An asset with no owner and no users goes first.
Make the switch easy to undo
Do not delete things in a hurry. Use an off switch that you can undo.
- Name an owner for the decision.
- Tell the people who might care, and give them a date.
- Turn it off, but keep the code and a backup.
- Wait until the date.
If nobody asks by the date, delete it. If someone does, you learn who the real user is.
Count what you turn off
The same idea works for alerts. In alert fatigue, I wrote that an alert nobody acts on is noise you have not deleted yet. Data assets work the same way.
Put retirements on the same scoreboard as launches. Each week, report two numbers:
- Assets you turned off this week.
- Assets on the list for next week, each with an owner.
If you only count launches, the pile only grows.
Your first ten
Open the access logs on Monday. Pick the 10 most expensive or noisiest assets you run, and ask who uses them.
Turn off the ones nobody claims. Then tell your leaders what you turned off, and why it made the numbers easier to trust.