This content originally appeared on HackerNoon and was authored by Vimal Dhupar
Most TPMs ask for data. I query it myself. The difference isn't efficiency — it's what you notice when nobody's filtering the answer for you.
\ A capacity review. Thursday afternoon. The data scientist presents a slide: "GPU utilization is trending up across all workload types. Fleet health is green."
\ I'm looking at the same data. But I ran the query myself that morning — broken out by hardware SKU, by team, by workload class. The aggregate is green. But one SKU is at 97% with a three-week job queue. Another is at 31%, allocated to a project that paused two months ago and never gave the capacity back. The slide says healthy. My query says we're about to miss a launch. I don't say, "The data is wrong." I say, "Can we pull up utilization by SKU?" The room sees it in ten seconds. The conversation shifts from status review to reallocation decision. We recover two weeks of blocked experiments before the end of the day. \n
That moment doesn't happen if I wait for someone else to pull my data.
How I Got Here
I didn't start as a data person. I started as a TPM who asked other people for data — analysts, data scientists, and engineers. Filed a request. Got a table back. Put it on a slide and presented it. The problem wasn't speed, though that was bad too. The problem was translation loss.
\ Every time I asked someone else to pull data, I was translating a nuanced program question into a data request. "How's the capacity looking for the ABC team?" The analyst hears: pull GPU utilization for that team's allocation. They return a number.
\ But what I actually needed to know was: are they burning through their quota faster than planned, and if so, will they run out before the model evaluation deadline on the 15th? That question requires joining allocation data with consumption rate, comparing against the experiment calendar, and checking whether their efficiency improvements landed.
\ No analyst is going to intuit that from a one-line request. Not because they're not good. Because they don't have the program context that makes the question meaningful.
\ So, I started writing my own queries.
What TPM Data Analysis Actually Looks Like
It's not data science. I'm not building models or running regressions. It's closer to investigative journalism — I have a hypothesis about the program, and I interrogate the data to confirm or destroy it.
Morning ritual: the sanity check.
Before any meeting, I run three to four queries that tell me the ground truth of whatever we're about to discuss. Capacity utilization by team and SKU. Job queue depth. Quota burn rate versus plan. Takes fifteen minutes. Saves an hour of "let me get back to you on that."
The join nobody asked for.
The most valuable analysis I do is connecting data from systems that don't talk to each other. Allocation data lives in one system. Actual consumption lives in another. The experiment calendar lives in a spreadsheet. Cost data lives in a third place. No single system gives you the full picture. But a TPM who can query all four and join them in a notebook sees things nobody else can see.
\ I once traced a capacity shortfall that three teams had escalated independently. Each team saw its own queue growing. Each filed their own ticket. Nobody connected them. I pulled job submission data across all three teams, joined it with the scheduler's priority assignments, and found the root cause: a single high-priority reservation — filed six weeks earlier for a project that had been deprioritized — was consuming 400 GPUs that the scheduler couldn't reallocate because the reservation was technically still active.
\ One query. One cancellation. Three teams unblocked.
The "that can't be right" moment.
This is the real value. When you pull your own data, you develop an intuition for what the numbers should look like. When utilization jumps from 60% to 85% overnight with no new workloads, you don't celebrate improved efficiency. You investigate. Maybe a reporting change inflated the metric. Maybe a stuck job is burning cycles without producing output. Maybe someone double-counted shared capacity.
\ An analyst who doesn't live in the program will report the 85% at face value. The TPM who's been watching the trendline for months will smell that something is off — because she's seen the data often enough to know what normal looks like.
The Tools Are Not the Point
People ask me what tools I use. It doesn't matter. SQL, notebooks, dashboards, and AI assistants that help me write queries faster. The tools change every year.
\ What doesn't change is the workflow:
- Start with the decision. Every query I write starts with: What decision will this data inform? If I can't name the decision, I don't run the query. Data without a decision is a hobby.
- Validate before you present. The most dangerous thing a TPM can do is present data she doesn't understand. I cross-check every number against at least one other source before it goes in a slide. If the two sources disagree, that disagreement is often more interesting than either number.
- Build the query once, run it every week. The first time I need a metric, I write a query. The second time, I templatize it. The third time, it's a dashboard. Half the dashboards I've built started as ad hoc queries I kept re-running because the program kept asking the same question.
- Know when to stop. I'm not trying to be a data scientist. I don't optimize query performance for fun. I don't build data pipelines. When the analysis gets complex enough to need a proper pipeline — persistent tables, scheduled refreshes, data quality checks — I hand it to engineering with a working prototype and a clear spec. The prototype means they're not guessing what I need. The spec means it gets built right.
Why Most TPMs Don't Do This
- "I don't know SQL." You don't need to. AI coding assistants write the query. You need to know what question to ask and whether the answer makes sense. That's domain knowledge, not technical skill.
- "That's the analyst's job." It is. And they'll do it better than you for complex statistical analysis. But the ad hoc question you need answered before a 2 pm meeting? You'll wait three days for that ticket. Or you can answer it in twenty minutes.
- "I might get the data wrong." You might. That's why you validate. But here's what's worse than getting the data wrong: making a program decision with no data at all because the data request is still in someone's backlog.
- "It's not in my job description." Neither was building dashboards five years ago. The TPM role is defined by what the program needs, not what the job posting says.
The Compounding Effect
Here's what surprised me: the value compounds.
\ The first query saves you one meeting. The tenth query gives you an instinct for the data. By the fiftieth, you're the person in the room who says "that number doesn't match what I saw this morning" — and you're right.
\ You stop being the TPM who asks, "Can someone check on this?" You become the TPM who says, "I checked — here's what's actually happening."
\ Leadership stops asking you for updates. They start asking you for an analysis. The shift is subtle but transformative: from tracking the program to understanding it.
\ The TPM who pulls her own data isn't doing an analyst's job. She's doing a TPM's job — with the one advantage that changes everything. She knows what she's looking at.
\ Vimal Dhupar is a Senior Technical Program Manager specializing in AI infrastructure and recommendation systems at scale. She has led large-scale AI capacity and infrastructure programs across major technology companies. Find her on LinkedIn.
This content originally appeared on HackerNoon and was authored by Vimal Dhupar
Vimal Dhupar | Sciencx (2026-05-15T01:56:01+00:00) The TPM Who Pulls Her Own Data. Retrieved from https://www.scien.cx/2026/05/15/the-tpm-who-pulls-her-own-data/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.