Program Execution & Driving Without Authority
Deep dive: the execution round
Scoping a program from ambiguity
After this you can turn a vague mandate into a scoped, owned plan.
The execution round usually opens with a deliberately fuzzy ask, because that is how the work actually arrives at Cursor. A founder says “our inference bill is scaring me” in a Slack thread and three weeks later there needs to be a program. The interviewer is watching whether you convert that into something a flat, fast org can act on without a planning committee.
The first move is to refuse the activity framing. “Optimize inference” is not a goal, it is a vibe. A goal is a number with a direction and a date attached to it, owned by someone whose name you can say out loud.
- Vague mandate
- “Optimize inference”
- Scoped goal
- “Cut inference COGS per active user 15% by end of Q3 without regressing tab-completion p95 latency”
- Why the rewrite wins
- Names the metric, the bound, the guardrail and the date - now it is testable
- Vague mandate
- “Get capacity under control”
- Scoped goal
- “Hit 55% sustained GPU utilization on the reserved fleet while keeping burst headroom for a 2x DAU spike”
- Why the rewrite wins
- Turns a feeling into a target and an explicit constraint you can plan against
- Vague mandate
- “Make migrations safer”
- Scoped goal
- “Zero customer-visible incidents across the serving-stack migration, with rollback under 10 minutes at every step”
- Why the rewrite wins
- Defines success as an outcome and a recovery SLO, not a checklist of tasks
| Vague mandate | Scoped goal | Why the rewrite wins |
|---|---|---|
| “Optimize inference” | “Cut inference COGS per active user 15% by end of Q3 without regressing tab-completion p95 latency” | Names the metric, the bound, the guardrail and the date - now it is testable |
| “Get capacity under control” | “Hit 55% sustained GPU utilization on the reserved fleet while keeping burst headroom for a 2x DAU spike” | Turns a feeling into a target and an explicit constraint you can plan against |
| “Make migrations safer” | “Zero customer-visible incidents across the serving-stack migration, with rollback under 10 minutes at every step” | Defines success as an outcome and a recovery SLO, not a checklist of tasks |
Every good scope is a metric movement plus a guardrail. The guardrail is what stops you from cutting cost by tanking latency.
Cost programs are dangerous precisely because cost is easy to cut if you ignore everything else. Quantize the model, batch more aggressively, route to a smaller model and you can save real money while quietly making tab-prediction feel sluggish. Stating the latency or quality guardrail in the goal itself is what separates a TPM who has run a cost program from one who has read about one.
Scope before you schedulethe order matters
Committing a date before you understand the dependency chain is how TPMs lose credibility in their first quarter. Walk the structure first, then the calendar falls out of it.
- 1Write the one-line goal. Metric, direction, guardrail, date. If you can't fit it on one line, you don't understand it yet.
- 2Name the owner of each work-stream. Not a team - a person. In a flat org, “Infra owns this” is a way to own nothing.
- 3Map the dependencies. What must finish before each piece can start? The longest chain is your real timeline, not the sum of optimistic estimates.
- 4Surface the top three to five risks now. Name them and the leading indicator you'll watch for each, while it's cheap to plan around them.
- 5Only then commit a date. Add explicit buffer where the critical path crosses a team boundary, because handoffs slip.
Right-size the process to the problemoutcomes over ceremony
Cursor screens hard against process-for-its-own-sake. A two-week cost spike does not need a steering committee, a RACI matrix and a weekly 12-person sync. It needs a one-page doc, two owners and a daily glance at one dashboard.
Living risk register with named owners.
Weekly written status, monthly leadership review.
Explicit rollback gates and validation at each cutover step.
One scoping doc, two owners, one dashboard.
Async status in a thread; escalate only on a real blocker.
No standing meeting - the doc is the meeting.
The doc is how a flat org alignswrite it down or it isn't real
There is no thick management layer at Cursor to carry context between rooms. The scoping doc is the mechanism that lets a founder, an ML lead and a Finance partner align without sitting in the same meeting. It is also your strongest interview artifact, because the JD says the doc is the deliverable.
- Goal
- The single metric-movement line, with guardrail and date
- Why now
- Two sentences on the business pressure that makes this worth doing
- Owners
- A named person per work-stream, plus the decision-maker for tradeoffs
- Plan
- The critical-path sequence, not an exhaustive task list
- Risks
- Top risks with a leading indicator and a planned response for each
- Out of scope
- What you are deliberately not doing, so nobody assumes it later
The “out of scope” line prevents more thrash than any other section. Unstated assumptions are where programs silently grow.
When the prompt is vague, narrate the rewrite out loud before you plan. “I'd first turn ‘optimize inference' into a target - say cut COGS per active user 15% by Q3 without regressing tab latency - because I can't scope what I can't measure.” That single sentence shows the interviewer you scope from outcomes and it earns you the right to ask clarifying questions about the real constraint.
Takeaway. Convert the mandate into one line - metric, direction, guardrail, date - name a person per work-stream, walk the dependency chain before you commit a date and put it in a scoping doc, because in a flat org the doc is how alignment happens without a meeting.
Self-check
QA founder asks you to “get our inference costs under control.” You have a 60-minute execution round to show how you'd scope it. What's your opening move and what makes it a good scope?
Dependencies, migrations & sequencing
After this you can sequence technical work to de-risk delivery.
Migrations are where TPMs earn or lose trust with infra leaders and they show up directly in this charter - the JD lists migrations alongside cost and capacity as programs you'll drive. The interviewer wants to see that you sequence to shrink blast radiusHow much breaks if a change goes wrong; the scope of potential damage., not just to finish fast.
Start with the dependency map. A plan that lists ten tasks with ten dates hides the one fact that matters: which chain of work, end to end, is the longest. That chain is the critical path and it sets the realistic timeline no matter how parallel everything else looks.
Find the critical path before the calendarthe longest chain wins
- Step
- Instrument cost telemetry
- Depends on
- -
- Duration
- 1 week
- On critical path?
- Yes - nothing downstream starts without it
- Step
- Build the attribution model
- Depends on
- telemetry
- Duration
- 2 weeks
- On critical path?
- Yes
- Step
- Validate model vs. Finance ledger
- Depends on
- model
- Duration
- 1 week
- On critical path?
- Yes
- Step
- Design the dashboard
- Depends on
- (parallel) telemetry
- Duration
- 1 week
- On critical path?
- No - slack available
- Step
- Pilot showback with one team
- Depends on
- validated model
- Duration
- 1 week
- On critical path?
- Yes
| Step | Depends on | Duration | On critical path? |
|---|---|---|---|
| Instrument cost telemetry | - | 1 week | Yes - nothing downstream starts without it |
| Build the attribution model | telemetry | 2 weeks | Yes |
| Validate model vs. Finance ledger | model | 1 week | Yes |
| Design the dashboard | (parallel) telemetry | 1 week | No - slack available |
| Pilot showback with one team | validated model | 1 week | Yes |
Critical path here is 5 weeks (telemetry → model → validation → pilot). The dashboard runs in parallel and has slack, so a slip there doesn't move the date - a slip in validation does.
Padding every task equally is amateur scheduling. Buffer belongs on the critical path and at cross-team handoffs, not sprinkled uniformly. A week of slack on the parallel dashboard task buys you nothing; a week of buffer before the Finance validation handoff buys you the whole program's safety margin.
Incremental cutover beats big-bangblast radius is the metric
When you migrate a serving stack at 1M+ DAU, the question is never “did it work” but “how many users felt it if it didn't.” Big-bang cutover bets the whole user base on a single switch. Incremental cutover bets 1%, watches, then 5%, then 25%.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Each gate is a guardrail-metric check, not a timer - you advance on evidence, with rollback kept hot the whole way.
- 1Shadow first. Run the new path alongside the old, take production traffic, compare outputs and latency, serve nothing from it. Zero blast radiusHow much breaks if a change goes wrong; the scope of potential damage., real signal.
- 2Canary at 1%. Route a sliver of live traffic. Watch error rate, p95/p99 latency and cost-per-request against the baseline you captured in shadow.
- 3Ramp on evidence. Move to 5%, 25%, 50% only when the canary's guardrail metrics hold. Each ramp is a decision, not a timer.
- 4Hold a bake period. Sit at 50% long enough to catch slow leaks - memory creep, cache cold-start, a tail-latency regression that only shows under sustained load.
- 5Cut over and keep the rollback hot. Don't decommission the old path the same day. Keep it warm until you've survived a peak traffic cycle.
A validation gate is the question “how will I know this step is safe to advance past?” answered before you take the step. A rollback is the answer to “if it isn't, how fast can I undo it and from how far?” If you can't state the rollback time and what it reverts, you don't have a migration plan - you have a hope.
Cross-team seams are the highest-risk jointsover-communicate here
Most migration failures don't happen inside a team's own work. They happen at the handoff, where one team's “done” doesn't match the next team's “ready.” At Cursor those seams run between Infra, ML/Research and Finance and nobody owns the gap by default.
Interface assumptions diverge - units, schema, SLA expectations.
Each side assumes the other is watching the metric during cutover.
Timing mismatch: one team ramps Friday, the other is out Monday.
Write the contract down: inputs, outputs, who watches what, when.
Name a single owner for the seam, even if it's you.
Schedule the handoff inside business hours with both sides present.
When asked to sequence a migration, lead with blast radiusHow much breaks if a change goes wrong; the scope of potential damage., not speed. “I'd run it shadow → 1% canary → ramp on guardrail metrics, keeping rollback under ten minutes at every step, because at a million-plus DAU a bad cutover is a company-visible incident.” Then point at the seam: “the riskiest moment is the Infra-to-ML handoff, so I'd own that contract directly.”
Takeaway. The longest dependency chain - not the task count - sets your timeline; migrate incrementally (shadow → canary → ramp) with a stated rollback time at every step and treat cross-team handoffs as the highest-risk seams worth over-communicating around.
Self-check
QYou're sequencing a serving-stack migration at 1M+ DAU and an engineer proposes a single weekend big-bang cutover to “rip the bandaid off.” How do you respond?
Risk management & operating cadence
After this you can run a program with a rhythm that catches problems early.
A program without a cadence is a program that surprises you. The execution deep-dive probes exactly this: how do you set up a rhythm where a problem shows up as a yellow flag with two weeks of runway, instead of a red one the morning of the deadline?
The spine of the rhythm is a living risk log. The common TPM framing is RAID - risks, assumptions, issues, dependencies - and the word “living” is doing real work. A risk register that nobody updates is decoration.
- Letter
- Risk
- What it tracks
- Something that might go wrong
- Example on a cost program
- Finance ledger and our telemetry may disagree on what counts as a billable inference
- Owner does what
- Watches a leading indicator; has a planned response
- Letter
- Assumption
- What it tracks
- Something you're treating as true but haven't verified
- Example on a cost program
- GPU reserved pricing stays flat through Q3
- Owner does what
- Validates it or converts it to a risk if it cracks
- Letter
- Issue
- What it tracks
- A risk that already materialized
- Example on a cost program
- Telemetry is double-counting retried requests
- Owner does what
- Owns the fix and the timeline to closure
- Letter
- Dependency
- What it tracks
- Work blocked on someone else
- Example on a cost program
- Attribution model blocked on Finance's chart-of-accounts mapping
- Owner does what
- Tracks the handoff and escalates if it slips
| Letter | What it tracks | Example on a cost program | Owner does what |
|---|---|---|---|
| Risk | Something that might go wrong | Finance ledger and our telemetry may disagree on what counts as a billable inference | Watches a leading indicator; has a planned response |
| Assumption | Something you're treating as true but haven't verified | GPU reserved pricing stays flat through Q3 | Validates it or converts it to a risk if it cracks |
| Issue | A risk that already materialized | Telemetry is double-counting retried requests | Owns the fix and the timeline to closure |
| Dependency | Work blocked on someone else | Attribution model blocked on Finance's chart-of-accounts mapping | Tracks the handoff and escalates if it slips |
Every row has a single named owner. A risk with no owner is a wish that someone, eventually, deals with it.
Make green/yellow/red mean somethingstatus without theater
Status colors rot into theater when nobody defines them, so everything stays green until it abruptly turns red. Define the thresholds up front, in the doc, so the color is a fact rather than a mood.
- Green
- On track to hit the goal and the date with current plan and owners - no decision needed
- Yellow
- A risk is now likely to hit the date or metric; mitigation underway, may need a decision soon
- Red
- Will miss the goal or date without an intervention this week; a specific decision is required now
Yellow is the most valuable color. A program that goes green-to-red with no yellow in between has a broken cadence.
Watermelon status - green on the outside, red on the inside - is the classic failure of a flat, optimistic org. People keep reporting green because nobody wants to be the bearer of the slip. You fix it by making yellow safe and expected and by defining red as “a decision is required,” which reframes escalation as helping the decision-maker rather than admitting failure.
Escalate with a recommendation, not a problemmake the decision easy
Cursor's leaders are time-poor and founder-engaged. Dropping a raw problem on them - “Finance and Infra disagree on attribution” - costs them the work of diagnosing it. Bring the decision pre-chewed.
- 1State the decision needed in one line. “We need to pick the source of truth for billable inference by Friday.”
- 2Give the two or three real options, each with its cost and consequence, not a strawman and a favorite.
- 3Make your recommendation and say why. You're closest to the data; have a point of view.
- 4Name the deadline and what happens if it slips. Tie the decision to the date it puts at risk.
A risk register earns its keep only if every entry resolves to one of three states: mitigated (you took action and it's handled), accepted (leadership chose to live with it, on the record) or escalated (it's now a decision in someone else's hands). A risk that just sits “open” for six weeks is a risk you're pretending to manage. Driving each one to a verb is the discipline interviewers are listening for.
Takeaway. Run a living RAID log where every entry has a named owner and resolves to mitigated, accepted or escalated; define green/yellow/red by explicit thresholds so status isn't theater; and escalate with a recommendation and a deadline so the decision is easy.
Self-check
Influence without authority
After this you can drive cross-functional work with no formal power.
This is the whole job and the JD says so directly. A Cursor TPM holds senior technical leaders accountable to commitments without managing any of them. There is no thick layer to escalate through, so the lever is credibility, not the org chart.
Authority is the cheap version of influence - it works until the moment someone outranks you or simply doesn't care about your deadline. What actually moves an ML lead who has ten things more interesting than your cost program is that you are reliable, prepared and right often enough to be worth listening to.
What you actually trade oncredibility compounds
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Ranked by what moves a senior technical leader when you hold no formal power over them.
You do what you said, when you said.
Your numbers hold up when someone checks them.
Over a quarter, this is the asset that compounds.
You walk in with the model already built and the tradeoff already framed.
You've read the dashboard before the meeting, not during it.
You make the expensive people's time cheap.
You name the uncomfortable cost reality out loud.
You disagree in the room, on the facts, not in the hallway after.
Truth-seeking is a screened Cursor value - this is where it shows.
You make each stakeholder's incentive visible, then find the overlap.
You frame your ask as their goal advanced, not your box checked.
People help programs that help them.
Align by making incentives visiblefind the overlap
Cross-functional friction is rarely about who's right. It's about two people optimizing different things and not seeing it. The ML lead wants model quality and experiment velocity; Finance wants predictable COGS; Infra wants reliability and headroom. Your job is to surface those tensions on paper and find the move that advances more than one of them.
- Partner
- ML / Research
- What they optimize
- Model quality, experiment velocity, freedom to burn compute
- The shared win to find
- Model routing that cuts cost on easy queries and frees GPU budget for experiments
- Partner
- Finance
- What they optimize
- Predictable, attributable COGS; gross-margin story
- The shared win to find
- Showback that gives them clean unit economics and gives ML a fair budget defense
- Partner
- Infrastructure
- What they optimize
- Reliability, utilization, capacity headroom
- The shared win to find
- Capacity plan that raises utilization and protects burst headroom they care about
| Partner | What they optimize | The shared win to find |
|---|---|---|
| ML / Research | Model quality, experiment velocity, freedom to burn compute | Model routing that cuts cost on easy queries and frees GPU budget for experiments |
| Finance | Predictable, attributable COGS; gross-margin story | Showback that gives them clean unit economics and gives ML a fair budget defense |
| Infrastructure | Reliability, utilization, capacity headroom | Capacity plan that raises utilization and protects burst headroom they care about |
When you can state the other side's incentive better than they can, they trust that your proposal accounts for it.
The artifact is neutral groundargue the doc, not the people
Spirited debate is part of the culture here and it goes better against a shared document than across a table. A written cost model with stated assumptions turns “I think we're overspending on the big model” into “line 14 assumes a 40% routing rate to the small model - is that the number we disagree on?” The disagreement gets specific and specific disagreements get resolved.
“I don't need you to agree with my conclusion yet - I need us to agree on the assumptions. Here's the model. If you think the routing rate or the GPU price is wrong, change that cell and we'll see what falls out. I'd rather be wrong on paper now than expensive in production later.”
Know when to escalate vs. drive consensustwo different tools
- Drive consensus yourself
- The disagreement is factual or about how - the data can settle it and the call is inside the teams' shared authority
- Escalate to a decision-maker
- It's a genuine priority tradeoff between teams (cost vs. velocity) that only a leader who owns both can adjudicate
- The tell you're escalating wrong
- You're escalating because consensus is uncomfortable, not because it's actually a leadership-level tradeoff
Escalating a fact you could've resolved with a query burns credibility. Failing to escalate a real cross-team priority call burns the timeline.
In the partner round, expect a question like “an ML lead won't commit to the capacity number you need - what do you do?” Don't reach for authority or escalation first. Show the sequence: understand their incentive (experiment headroom), put the tradeoff in a shared doc with explicit assumptions, find the routing-and-budget move that gives them headroom while hitting your cost target and escalate only if it turns out to be a real priority tradeoff a leader has to own.
Takeaway. Influence runs on credibility - reliability, preparation and directness - not the org chart; align partners by making their competing incentives visible and finding the shared win, resolve disagreement against a written artifact and escalate only genuine cross-team priority tradeoffs, never facts you could settle yourself.
Self-check
QAn ML lead keeps resisting the GPU-budget cap your capacity program needs and you have no authority over them. You feel the urge to escalate to a founder. Is that the right first move?
Metrics, dashboards & status comms
After this you can instrument a program so progress is self-evident.
A well-instrumented program barely needs status meetings, because anyone can look and see where it stands. The JD is blunt about the bar: they want someone who digs into the dashboards and builds the view, not a TPM who waits for an analyst to send a number.
Start by choosing a small set of metrics that actually predict success. The instinct to track everything produces a dashboard nobody reads. Pick the few signals that, if they move, tell you the program is or isn't working.
Leading vs. laggingyou steer by the leading ones
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Same cost program, two kinds of metric - one lets you change course, the other only confirms the result.
- Metric
- Inference COGS per active user
- Type
- Lagging
- What it tells you on a cost program
- The outcome the program exists to move - but it lands after the fact
- Metric
- % of queries routed to the small model
- Type
- Leading
- What it tells you on a cost program
- Moves first; if routing isn't shifting, the cost number won't either
- Metric
- GPU utilization on the reserved fleet
- Type
- Leading
- What it tells you on a cost program
- Idle reserved capacity is money already spent; rising utilization predicts savings
- Metric
- p95 tab-completion latency
- Type
- Guardrail
- What it tells you on a cost program
- The thing you must not break while chasing the cost number
| Metric | Type | What it tells you on a cost program |
|---|---|---|
| Inference COGS per active user | Lagging | The outcome the program exists to move - but it lands after the fact |
| % of queries routed to the small model | Leading | Moves first; if routing isn't shifting, the cost number won't either |
| GPU utilization on the reserved fleet | Leading | Idle reserved capacity is money already spent; rising utilization predicts savings |
| p95 tab-completion latency | Guardrail | The thing you must not break while chasing the cost number |
Lagging metrics prove success; leading metrics let you steer toward it before it's too late to change course.
On this charter, a program metric that doesn't ladder up to a cost or capacity outcome is vanity. “Routing rate is up 12%” is only interesting because it implies a COGS reduction. Always be able to finish the sentence: “…which moves cost-per-active-user by roughly X.” That translation - from a technical signal to a business number - is the literal job description of a TPM who bridges the technical and financial domains.
Write status a founder absorbs in 60 secondsstate, change, decision
A busy founder reads status on a phone between meetings. Bury the lede and you've wasted the only attention you'll get. Three lines, in order: where it stands, what moved since last time, what you need from them.
INFERENCE COGS PROGRAM - wk 4/8 - YELLOW
State: On track for the 15% target; tracking 9% so far.
Change: Routing rollout hit a p95 latency regression at 25%;
held the ramp, root-caused to cold-start on the small model.
Decision: Need a call by Thu - accept a 1-week slip to add
model warm-pooling or ship at 10% cost savings now.
Recommend the slip; warm-pooling unblocks the full 15%.That update is yellow on purpose, names the regression honestly and hands the founder a pre-framed decision with a recommendation. It is the written form of every behavioral theme in this role.
Make the data trustworthy before it's prettycredibility is the real asset
An elegant dashboard built on a number that's quietly wrong does more damage than no dashboard at all, because people act on it. The fastest way to lose a senior technical leader's trust is to show them a cost figure they can disprove from their own knowledge.
- 1Reconcile against a source of truth first. Tie your cost telemetry to the Finance ledger before you publish anything. If they disagree, that gap is the first finding.
- 2Spot-check the edges. Pull a single inference request end to end and confirm it's attributed once, to the right product, at the right price.
- 3Show your assumptions on the dashboard. Routing rate, GPU price, utilization basis - state them, so a viewer disputes a number instead of distrusting the whole view.
- 4Only then make it legible. A clean view on reconciled data earns trust; a clean view on bad data spends it.
Before any cost dashboard goes to leadership, run one check: does the total match the bill? If your attributed inference spend for the month is within a percent or two of what Finance actually paid the cloud provider, the model is trustworthy. If it's off by 20%, you have an attribution bug and shipping the dashboard anyway is how you lose the room.
When they ask how you'd report on a program, don't describe a dashboard - describe the trust chain. “I'd reconcile attributed spend to the Finance ledger first, surface the assumptions on the view and write status as state/change/decision so a founder can act in a minute.” That answer hits the JD's three explicit asks at once: build the view yourself, bridge technical and financial and make the doc the deliverable.
Takeaway. Pick a few leading metrics you can steer by plus the lagging outcome and a guardrail, reconcile the data to a source of truth before you make it pretty, tie every signal back to the dollar and write status as state, change, decision so a busy founder can act in 60 seconds.
Self-check
QYou've built a clean inference-cost dashboard and you're about to share it with leadership. What's the single most important thing to do before you hit send and why?