Running a data team
Measuring the value of a data change
Data teams are asked to justify themselves in numbers they do not have. A few are genuinely measurable; most of what gets reported is not.
1 minute read
Sooner or later somebody asks what the data team delivered this quarter, and the honest answer — twelve things stopped being broken and nobody noticed — does not survive contact with a budget review. So teams reach for proxies: tickets closed, models shipped, uptime. None of them is value, and everybody in the room knows it.
What can actually be measured
- Money not spent: a warehouse saving, computed from the same metering the invoice is computed from, before and after a specific change.
- Time not spent: a failure that used to recur weekly and now does not, multiplied by what it cost to handle.
- Risk removed: a test restored, a drift detected before it reached a report — countable, though not in currency.
The first of those is the only one that converts cleanly to a number a finance team will accept, which is why it is worth being rigorous about. Measured means measured: the metering before, the metering after, the same workload, and an honest note about anything that changed at the same time.
What cannot, and should be stated rather than modelled
The value of a correct figure in a decision nobody can trace. The cost of a report somebody quietly stopped trusting. The hours a schema change would have consumed had it not been caught. These are real and they are not quantities. Reporting them as modelled dollars does not make the case stronger — it gives a sceptical reader a number to attack, and they will attack the weakest one on the page.
One measured saving beats five modelled ones, because the five invite an argument about the model.
More on running a data team
Run this against your own estate
Gecko reads metadata and query history — never the rows in your tables — and tells you what it found.
Get started