Push, Don't Provide
“Most data teams run a reactive service desk — answer the question, paste the number, repeat. The best ones push: they deliver the number that changes a decision before anyone thinks to ask.”
Every data team I've worked with is quietly running a service desk it never meant to open. A question lands in Slack — "quick one, what was enterprise churn last month?" — and someone stops what they're doing to answer it. The number gets pasted into the thread, the thread dies, and three weeks later someone asks the same question again.
The team calls this being helpful. It's really being reactive, and reactive is a ceiling. The best data teams I've seen don't wait to be asked. They push.
The provider trap
A provider answers questions. That sounds like a virtue right up until you count what it costs.
- Your most senior people spend the week re-deriving numbers that were already answerable, one Slack thread at a time.
- The organization learns to treat the data team as a lookup service — a faster search bar — instead of a partner in the decision.
- And the worst cost is the one nobody sees: the number that would have changed a call never gets pulled, because no one thought to ask for it.
A service desk optimizes for response time. A data team should optimize for decisions changed. Those are not the same job, and you can't do the second one from behind a ticket queue.
Pushing is delivering the number before the question
To push is to decide, in advance, which numbers actually move decisions — and to put them in front of the person who owns that decision the moment they move.
Not a dashboard with forty tiles nobody opens. A message: "Net revenue retention for enterprise just slipped under 108% for the first time in four quarters, and it's one cohort dragging it down. Here's the cohort."
The difference is subtle and total. A provider makes data available. A pusher makes a decision impossible to miss. One waits at the counter; the other walks the number over.
You can't push what you can't trust
Here's the catch that keeps most teams stuck in provide mode: pushing raises the stakes on the model underneath.
A wrong number someone pulled is an embarrassment. A wrong number you pushed — unbidden, with your name on it, into an executive's inbox — is a credibility event. You don't get to say "well, you asked for it." You sent it.
So push forces a discipline that reactive work lets you skip. You can only push a number you can define once and defend: a grain you can state in a sentence, a single canonical definition of "active user," a metric that's an instrument someone acts on rather than decoration nobody reads. Push and the data model is the product turn out to be the same bet from two directions — you can't proactively serve a number you haven't modeled well enough to trust.
The mechanics: instruments, thresholds, an owner
Pushing well is not "more alerts." An inbox full of noisy alerts is just a service desk that pages you. The unit of a push is a small set of instruments, and every instrument carries three things:
- an owner — the person whose decision it feeds,
- a threshold — the value at which something should change,
- a channel — wherever that person already works, not a dashboard they have to remember to open.
When the number crosses the line, it goes and finds the owner. When it doesn't, it stays quiet. Five numbers delivered at the exact moment they change a decision will beat a hundred always-on tiles every time — because the tiles ask the reader to notice, and pushing does the noticing for them.
This is the whole idea behind serving data when it matters instead of standing up one more place to go look for it.
Push one number first
You don't earn the right to push everything by building a platform. You earn it one number at a time.
Pick the single metric your leadership currently checks by gut — the one they'd feel in their stomach if it moved the wrong way — and build the push for that one before your next planning cycle. Give it an owner, a threshold, and a channel. The first time it fires and someone acts before they would otherwise have noticed, you'll have stopped being the org's lookup service and started being its early-warning system.
Answer fewer questions. Deliver more of the ones that matter before anyone thinks to ask.