Running a data team
"The number changed" is the hardest ticket
No error, no failure, no alert. Just a figure that is different from last week and somebody who needs to know why by lunchtime.
1 minute read
Everything else in a data team's queue has an artefact to start from: a failed run, a stack trace, a test result. This one has a person's recollection and a screenshot. It is the most common serious ticket, the slowest to resolve, and the one most likely to end in a shrug that costs the team credibility.
Why it is slow
Because the answer could be in six places and only one of them keeps a history: the source data changed, the transformation changed, the schedule changed and the figure is stale, the filter in the report changed, the definition changed, or the figure never was what the person thought it was. Most estates can reconstruct the second with git and none of the others at all.
What makes it tractable
- Snapshots of shape and summary statistics, so "what did this table look like last Tuesday" is a query rather than a guess.
- Column-level lineage, so the search space is the two upstreams that feed this figure, not the eleven that feed the table.
- Run history with timing, so staleness is ruled in or out in a minute.
- A record of definition changes that is not only in the repository — because the definition people mean often lives in the BI layer.
None of that is exotic. All of it has to exist before the ticket arrives, which is the real reason it is rarely there: it is infrastructure whose value is only visible on the day somebody asks, and on that day there is no time to build it.
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