Running a data team
Two people and four thousand objects
Small data teams inherit estates sized for the organisation, not for the team. The failure modes are identical to a large estate; the slack is not.
1 minute read
A common shape: a company of a few hundred people, a warehouse with several thousand objects accumulated over a decade, and two or three people responsible for all of it. They are competent and they are busy. The estate has the same problems a very large one has — dead objects, drift, cost leaks, loosened tests — in the same proportions. What it does not have is anybody whose job is to go looking.
Why the usual advice does not apply
- Platform teams, data governance functions and centres of excellence all assume headcount this team does not have.
- Tooling priced per seat is affordable; tooling priced per estate is not, and the estate is the large number here.
- Any practice that requires a weekly meeting of several people is a practice that will not happen.
- Migration projects are impossible: there is no second team to keep the lights on.
What does work
Anything that reduces a day of investigation to a five-minute decision. Not advice, not a dashboard of metrics to interpret, and not a list of two hundred issues — a small number of specific, evidenced, actionable items with the work already done, arriving at a rate the team can absorb. The constraint to design against is attention, not capability.
For a team of two, a backlog of two hundred findings is indistinguishable from no findings at all.
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