The Role & Your Charter
What you'd actually own as Cursor's Infrastructure TPM
The one-line charter
After this you can state, in a sentence, what this TPM is hired to change.
You are not being hired to run a Gantt chart. You are being hired to own the unit economics of running Cursor at 1M+ DAU - and to turn raw infrastructure cost and capacity data into decisions leadership can act on.
Read this section as the role contract. The diagram or table names the surface area, but the interview signal is whether you can turn it into a clear operating claim: what you own, what you do not own, what evidence proves the work is working and where judgment matters.
Most TPM roles coordinate a roadmap that someone else costed. This one starts from the cost. Inference and compute are the dominant line in an AI editor's cost of goods, so the question "what does an extra million users cost us and where?" lands on your desk, not Finance's alone.
Say the charter in one sentence in the recruiter screen and again in the hiring-manager round. It signals you read the job, not the title.
“The way I read this role: I own the unit economics of running Cursor at scale. I connect inference and compute spend to products and metrics, build the GPU capacity-planning framework and make R&D-investment tradeoffs legible to both engineers and Finance - and I build the models myself rather than chase status from a queue.”
Where you sitan intersection, not a lane
Because inference cost is a function of how ML serves models, how Infra provisions GPUs and how Finance books the spend, you live at the seam of all three. None of them reports to you. The whole job is moving decisions across that seam.
- ML / Research
- Owns model choice, routing and experiments. They generate the demand and most of the cost.
- Infrastructure
- Owns GPU fleet, serving, utilization. They convert your forecasts into reserved and on-demand capacity.
- Finance
- Owns COGS, gross margin and the budget. They need spend tied to products and unit metrics to plan.
- Your seat
- The translator and program owner in the middle - influence without authority by being the most prepared person in the room.
Three pillars, one mandatehow the JD decomposes
The JD frames the work as three program areas. They are not separate jobs. They are three angles on the same mandate: make the money spent on compute legible, allocated and worth it.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Every pillar serves the same mandate; attribution is the foundation the others stand on.
Connect inference and compute spend to products, features and teams.
Translate raw spend into unit metrics: cost per inference, per token, per active user.
Build the reserved-vs-burst planning framework.
Run recurring allocation reviews with ML and Infra leadership.
Separate training/experimentation spend from production COGS.
Frame investment tradeoffs: is this GPU-hour worth more than shipping?
An operator, not a coordinatorthe bar the JD sets
The JD is blunt about this: write the doc, build the cost model, dig into the dashboards, run the analysis. A TPM who only schedules other people's work fails this loop. The artifact is the deliverable and the artifact has your name on it.
If your instinct in a behavioral story is to describe the meeting you ran rather than the model you built, you will read as a process TPM. Cursor screens for action bias. Lead every story with the artifact you produced and the decision it changed, then mention the cadence that supported it.
How success is actually measured
Tickets closed and meetings held are inputs nobody scores. The outcomes are dollars and allocation: margin moved, spend correctly attributed, GPUs pointed at the highest-value work.
- Dollars saved - cost-optimization programs you drove to a measurable reduction.
- Margin improved - gross margin protected as DAU grows, not eroded by it.
- Capacity correctly allocated - GPUs going to the work with the best return, with idle waste falling.
- Decisions made faster - leaders acting on a trustworthy cost picture instead of waiting on a quarterly reconciliation.
Takeaway. In one line: you own the unit economics of running Cursor at 1M+ DAU, sitting between ML, Infra and Finance - and you're scored in dollars and allocation, not tickets closed.
Self-check
QHow should you summarize the Cursor Infrastructure TPM charter in a sentence?
Pillar 1 - Cost-attribution programs
After this you can explain how spend gets connected to products, features and metrics.
Attribution is the foundation pillar. Until spend can be traced to a product, a feature or a user, no one can decide whether it is worth it - and at Cursor's scale, ungoverned inference spend lands in a shared pool with no owner.
The work is a pipeline: instrument the spend, tag it to something meaningful, convert it to a unit metric, then publish a picture leadership trusts. Each step has a real failure mode if you skip it.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Each step has a failure mode if you skip it; the final publish step is where leadership trust is won or lost.
- 1Instrument. Get cost and usage data flowing from cloud bills, GPU-hours and inference logs into one place you can query - not a quarterly PDF from Finance.
- 2Tag. Attribute spend to a dimension that matters: product surface (tab vs. agent), feature, model, team or environment (prod vs. experiment).
- 3Normalize to a unit. Divide spend by the thing leadership cares about to get cost per inference, cost per token or cost per active user.
- 4Publish & defend. Ship a dashboard and a narrative so a leader can act and stand behind the assumptions when they are challenged.
The unit metrics and what each answersthe language Finance and ML share
Raw spend is a scary number with no decision attached. A unit metric turns it into a lever. Know which metric answers which question before someone asks.
- Unit metric
- Cost per inference / request
- What it answers
- Is a single model call getting cheaper or more expensive as we change routing?
- Who leans on it
- ML / Research
- Unit metric
- Cost per token
- What it answers
- How does prompt and output length drive spend - and what does a longer context window cost us?
- Who leans on it
- ML + Finance
- Unit metric
- Cost per active user
- What it answers
- Does each new user add margin or erode it as we grow?
- Who leans on it
- Finance + leadership
- Unit metric
- Gross margin / COGS %
- What it answers
- Is the business model healthy as inference scales with DAU?
- Who leans on it
- Finance + founders
| Unit metric | What it answers | Who leans on it |
|---|---|---|
| Cost per inference / request | Is a single model call getting cheaper or more expensive as we change routing? | ML / Research |
| Cost per token | How does prompt and output length drive spend - and what does a longer context window cost us? | ML + Finance |
| Cost per active user | Does each new user add margin or erode it as we grow? | Finance + leadership |
| Gross margin / COGS % | Is the business model healthy as inference scales with DAU? | Finance + founders |
A strong TPM moves fluently up this ladder, from a single request to the board-level margin story.
Showback vs. chargebackvisibility before accountability
These two words decide how much friction your program creates. Showback shows teams what they spend. Chargeback makes them pay for it from their own budget. Confusing them is a classic FinOps stumble in an interview.
- What it does
- Showback
- Reports each team's spend for visibility
- Chargeback
- Bills each team's spend against their budget
- Behavior it drives
- Showback
- Awareness, gentle peer pressure
- Chargeback
- Hard accountability and real tradeoffs
- When it fits
- Showback
- Early, when attribution is still imperfect and trust is being built
- Chargeback
- Once the data is trusted and ownership is clear
- The risk
- Showback
- Teams ignore a report with no teeth
- Chargeback
- Premature billing on shaky data poisons trust in the whole program
| Showback | Chargeback | |
|---|---|---|
| What it does | Reports each team's spend for visibility | Bills each team's spend against their budget |
| Behavior it drives | Awareness, gentle peer pressure | Hard accountability and real tradeoffs |
| When it fits | Early, when attribution is still imperfect and trust is being built | Once the data is trusted and ownership is clear |
| The risk | Teams ignore a report with no teeth | Premature billing on shaky data poisons trust in the whole program |
Sequence matters: most healthy programs earn trust with showback first, then move the metrics that matter to chargeback.
Traditional cloud FinOps assumes fairly stable, taggable resources. AI workloads break that. A single GPU pool serves production inference, an A/B experiment and a research training run in the same hour and demand swings with model launches and viral usage. Spend pools without an obvious owner unless you build the attribution layer deliberately - which is exactly why the role exists.
When asked to design a cost-attribution program, do not jump to a chargeback model. Say you would start with showback to build trust while the attribution data is still maturing, prove the numbers reconcile with the cloud bill, then graduate the high-signal dimensions to chargeback. Sequencing visibility before accountability signals you have actually run one of these, not just read about it.
Takeaway. Attribution is a pipeline - instrument, tag, normalize to a unit, publish - and you earn trust with showback before you impose chargeback, because dynamic AI workloads pool spend with no owner unless you build the layer.
Self-check
QA leader asks you to build a cost-attribution program for inference spend and wants teams held accountable for what they use. What's the strongest sequencing and why?
Pillar 2 - GPU & capacity allocation
After this you can describe the capacity-planning framework and review cadence you'd run.
Capacity is where cost meets physics. GPUs are expensive, power-hungry and slow to acquire, so you cannot just spin up more on a whim. The framework you build decides how much the company commits to versus how much it rents by the hour.
The core design choice is reserved baseline versus on-demand burst. Reserve too much and you pay for idle silicon; reserve too little and you scramble for expensive capacity the moment a model launch spikes demand.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The framework you build decides how much the company commits to versus rents by the hour.
Covers predictable, always-on production load like tab prediction.
Cheaper per GPU-hour when sustained usage is high - committed capacity needs roughly 60-80% sustained utilization to beat on-demand.
The risk is paying for it whether or not you use it.
Absorbs spikes, experiments and uncertain new-feature demand.
Higher per-hour price, but you only pay when you run it.
The risk is unbounded cost and scarcity exactly when everyone wants capacity at once.
Utilization is the efficiency leverwhere the wasted money hides
Idle GPU time is money already spent for nothing. GPUs commonly run at 15-30% utilization, which means a fleet can be enormous and still mostly wasted. Driving utilization up is often the single biggest efficiency win available, ahead of buying more hardware.
- Typical utilization
- Often 15-30% - most of the fleet is idle at any given moment unless actively managed.
- Reserved breakeven
- Committed capacity generally beats on-demand only above ~60-80% sustained use.
- The lever order
- Raise utilization first (free capacity you already paid for), then decide reserve-vs-burst, then buy more.
- Demand driver
- Capacity demand tracks DAU, request volume and new model rollouts - forecast against those, not last quarter's average.
Industry-typical ranges to anchor a conversation, not Cursor's published figures.
Tie demand to product signalsforecasting, not guessing
A capacity plan that extrapolates last month's GPU-hours misses the things that actually move demand. The forecast should be a function of product reality: how many users, how many requests each and what new capabilities are about to ship.
- 1Anchor on a demand model. Tie GPU demand to DAU growth, requests per user and the inference cost of each request type.
- 2Run scenarios. Build base, high and aggressive cases - a viral week or a heavy new agent feature can change the answer by a lot.
- 3Stress the assumptions. Sensitivity-test the inputs that swing the result most, usually request growth and per-request cost.
- 4Convert to a commit decision. Translate the forecast into a reserved baseline plus a burst headroom you can defend to Infra and Finance.
The allocation review you runthe forum is the deliverable
You build the framework and you run the forum, but you do not make the final call on who gets the GPUs. That is the influence-without-authority test in its purest form: you set the agenda, bring the evidence and force a clear decision from the leaders who do own it.
- Cadence
- Recurring (often monthly or per planning cycle), so allocation is a standing decision, not a fire drill.
- Who's in the room
- ML/Research and Infra leadership - the people who own demand and supply respectively.
- What you bring
- Current utilization, the demand forecast, requests on the table and the tradeoff each implies.
- What you own
- The framework, the data and a forced, documented decision - not the allocation verdict itself.
If asked how you'd allocate GPUs across teams, resist naming a winner. Describe the framework and the review instead: "I'd bring utilization and a demand forecast to a recurring review with ML and Infra leadership, surface the tradeoff each request implies and drive them to a documented decision. I own the framework and the forum; they own the call." That answer shows you understand the role's authority boundary.
Reaching for "buy more GPUs" as the first answer is a tell. The efficient move is almost always to raise utilization on capacity you already pay for before committing to more. Naming utilization first separates someone who has managed a fleet from someone who has only requested one.
Takeaway. Balance reserved baseline against on-demand burst, drive utilization up before buying more, forecast demand from DAU and request growth - and own the framework and the review forum while the allocation call stays with ML and Infra leadership.
Self-check
Pillar 3 - R&D efficiency & strategic partnership
After this you can separate production COGS from R&D spend and frame investment tradeoffs.
The third pillar is where you stop being a cost reporter and become a thought partner. The job is to help senior leaders decide which experiments and investments are worth their GPU-hours - and to keep R&D spend from being confused with the cost of serving the product.
The first discipline is not conflating two very different kinds of spend. Production inference is COGS: the cost of delivering the product you already sell. R&D is investment: training runs and experiments that may or may not pay off. They are governed, budgeted and judged on different terms.
- What it is
- Production inference (COGS)
- Compute to serve live users - tab, agent, completions
- R&D spend (investment)
- Training runs, evals, experiments, research
- How it scales
- Production inference (COGS)
- With DAU and usage - more users, more cost
- R&D spend (investment)
- With ambition and bets, not directly with users
- How it's judged
- Production inference (COGS)
- Gross margin and cost per active user
- R&D spend (investment)
- Expected value vs. cost and opportunity cost
- The mistake
- Production inference (COGS)
- Letting it silently erode margin as you grow
- R&D spend (investment)
- Treating speculative bets as if they were fixed overhead
| Production inference (COGS) | R&D spend (investment) | |
|---|---|---|
| What it is | Compute to serve live users - tab, agent, completions | Training runs, evals, experiments, research |
| How it scales | With DAU and usage - more users, more cost | With ambition and bets, not directly with users |
| How it's judged | Gross margin and cost per active user | Expected value vs. cost and opportunity cost |
| The mistake | Letting it silently erode margin as you grow | Treating speculative bets as if they were fixed overhead |
Conflating these two is one of the fastest ways to give a leader a misleading margin picture.
Framing an R&D tradeoffthe thought-partner skill
"Is this experiment worth it?" is the recurring question. You answer it by making three things explicit so the owner can decide with eyes open.
What does success buy - a better model, lower serving cost, a new capability?
Size it honestly, including the chance it doesn't land.
The GPU-hours and engineering time the bet consumes.
Stated in the same currency as everything else competing for capacity.
What those GPU-hours could do instead - including shipping.
The question that's usually missing: what are we not doing to run this?
Drive efficiency programs end-to-endowning the outcome, not just the analysis
Beyond framing single decisions, you run standing efficiency programs to completion. These are real programs with a goal, owners and risks - cost optimization, migrations, reliability - and you carry them from problem to measured result, not just to a recommendation.
- Cost optimization - a measurable reduction in cost per inference or per active user, tracked to a number.
- Migrations - moving serving onto cheaper or faster infrastructure, sequenced so production never blinks.
- Reliability - keeping latency and uptime within SLA while costs come down, since a cheap service that misses its latency budget is worthless.
Your real edge is translationthe value that's hard to hire for
Engineers reason in latency, utilization and model quality. Finance reasons in margin, budget and forecast. The reason this role exists is that few people speak both fluently. You make a financial argument legible to an ML researcher and a technical argument legible to a CFO.
“To Finance I'd frame it as: routing simple queries to the smaller model cuts cost per active user by X% with no measurable quality regression, which protects gross margin as DAU grows. To the ML team I'd frame the same change as: here's the latency and eval budget it has to stay inside. Same decision, two languages.”
Do not pitch yourself as pure cost-cutting. A TPM who only ever argues to spend less will lose credibility with a research org whose whole job is to spend on bets that compound. Frame yourself as protecting margin while making sure the right bets get funded - efficiency in service of ambition, not against it.
Takeaway. Keep production COGS separate from R&D investment, frame every bet by expected value, cost and opportunity cost and remember your edge is translating a financial argument for engineers and a technical one for Finance.
Self-check
QWhy does the JD treat R&D spend differently from production inference COGS and how should a TPM frame whether a costly experiment is worth running?
What 'hands-on, flat, talent-dense' means for the bar
After this you can calibrate to Cursor's culture before you prep tactics.
Before you drill tactics for the loop, calibrate to the culture, because it changes what "good" looks like in the room. Cursor is flat, talent-dense and founder-engaged and a behavioral answer that wins at a big-tech bar raiser can read as bureaucratic here.
Flat and talent-dense means high autonomy and thin management cover. There is no layer to escalate through, so influence is not a soft skill on the side - it is the mechanism by which the job gets done.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Ranked by how heavily Cursor's flat, founder-engaged culture weighs each signal.
- Rewards
- Building the artifact, having a real point of view, changing your mind when the data says so, getting to an outcome.
- Penalizes
- Process for its own sake, hiding behind ceremony, escalating instead of persuading, agreeing to keep the peace.
- The flat-org reality
- No thick management layer - you persuade senior technical leaders directly or the program stalls.
- Founder-engaged
- Expect to meet a founder or senior leader; expect spirited, truth-seeking debate, not a scripted Q&A.
Truth-seeking and spirited debatestated values you'll be screened on
Cursor names truth-seeking and spirited debate as values. The practical meaning: being agreeable is not the same as being right. In the behavioral and values round, the interviewer may push back hard to see whether you defend a position with evidence or fold to avoid friction.
You surface an uncomfortable cost reality even when it's unwelcome.
You change your conclusion when someone brings better data and you say so out loud.
Winning the argument by seniority or volume.
Holding your line after the evidence has clearly moved against it.
Operate at every altitudethe range they test for
The same person who writes the board-ready margin narrative has to be able to drop into a raw dashboard and query the usage table. Interviewers probe both ends to make sure you are not only comfortable at one altitude.
Have an authentic point of view on the productthe cheapest signal to fake, the easiest to catch
This is a company that builds for engineers and expects you to use what you build. Generic praise - "I love how it boosts productivity" - reads as someone who installed it the night before. A specific, lived take on Cursor and its inference cost tradeoffs is the credibility shortcut.
“I live in tab prediction - it needs tens-of-milliseconds latency, so it can't run on the biggest model, which is a real cost-and-quality tradeoff I find interesting. Agent mode is the opposite: I'll happily wait longer for a multi-step result and that's where the expensive long-context calls pile up. Those two surfaces have completely different unit economics and that's exactly the kind of thing I'd want to attribute and optimize.”
When a founder or senior leader pushes back on your cost recommendation, treat it as the test, not an attack. Hold your position with the data, then say what would change your mind: "I'd revise this if per-request volume on the agent surface is growing faster than I assumed - what are you seeing?" Defending with evidence while staying genuinely open is the exact behavior the values round screens for.
The agreeable candidate who concedes the moment a senior person pushes back fails the truth-seeking screen as surely as the one who bulldozes. Calibrate to the middle: change your mind on evidence, not on rank.
Takeaway. Cursor's flat, founder-engaged culture rewards building the artifact, defending a view with data and operating from board narrative down to a raw query - and it screens out process-for-its-own-sake and folding under pushback.
Self-check
QIn Cursor's values round, a founder pushes back hard on your cost recommendation. What response best fits a flat, truth-seeking, talent-dense culture?