The Role & Your Charter

You build the infrastructure that powers go-to-market, not the campaigns that run on top of it. The title says engineer on purpose: the deliverable is durable systems and reusable primitives, not a calendar of sends.

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.

Cursor is the AI code editor built by Anysphere. This seat lives in Growth Programs inside Marketing and the JD frames it as someone who turns messy, manual GTM workflows into simple, scalable, AI-native systems. The fastest way to mis-read the role is to pattern-match it to Marketing Ops, where the work is configuring a tool someone else picked and running the motions a marketer designed.

The distinction is not seniority. A GTM Engineer owns the connective tissue between systems, while Marketing Ops owns a funnel and RevOps owns the revenue process. You sit across Marketing, Growth, Data and Engineering rather than inside any one of them.

There is a useful way to organize the whole discipline as three rungs of a ladder. The role touches all three, but its center of gravity is the activation layer where systems take action.

1. 1Data foundation. Clean, deduped, identity-resolved sources of truth for leads and accounts - the raw material everything else depends on.
2. 2Data modeling. Scoring, segmentation, ICP logic and the audience definitions that turn raw data into decisions.
3. 3Data activation. Routing, enrichment workflows and agents that push the right action to the right system at the right time.

Why would a company that builds an AI coding tool want this seat at all? Because use and automation are the product thesis applied internally. Cursor's whole pitch is that one engineer with the right AI tooling outproduces a larger team without it. Hiring a GTM Engineer is that belief turned inward: remove human toil from go-to-market with systems instead of adding headcount to run it.

Plumbing is the JD's own word and it is exact. You own the connective layer: how data moves, who qualifies for what, where a lead goes and whether the whole thing keeps running at 2am without a human watching it.

Break the abstraction into five concrete surfaces. Each is a system with inputs, transformations and failure modes - the kind of thing you can be paged about, not a slide you present once.

The fifth surface wraps the other four: measurement and feedback loops so each program can be evaluated, iterated and scaled. A workflow you can't measure is a workflow you can't improve and the JD treats instrumentation as part of building the system, not a follow-up project.

It helps to trace one lead end to end. A self-serve signup arrives and the plumbing decides everything that happens next.

1. 1Capture. A developer signs up or fills a form; the event lands in the system with a stable identifier.
2. 2Dedup + identity. Resolve it against existing leads and accounts so you don't create a duplicate or split a known account.
3. 3Enrich. Hydrate the record with firmographic and technographic data, often through a waterfall of providers to maximize match rate.
4. 4Score. Apply ICP and intent logic to produce a number that decides priority.
5. 5Route. Send high scores to a rep with an SLA, lower scores to nurture, with a fallback if no owner exists.
6. 6Instrument. Log every hop so you can measure match rate, routing accuracy, time-to-first-touch and downstream conversion.

Cursor grows the way developer tools grow: bottom-up. Individual engineers adopt it, the habit spreads through a team and eventually a company buys it. The plumbing you build has to serve that shape and a generic B2B-SaaS answer will read as someone who didn't think about this business.

The motion is developer-led PLG: self-serve adoption that expands into teams and lands as enterprise. That changes what your systems optimize for. You aren't pushing leads through a top-of-funnel form fill; you're reading product usage signals to find accounts that are already adopting and routing them at the right moment.

The JD names three Growth Programs explicitly. Treat each as a distinct audience primitive with its own entry rules, data and actions - not three flavors of the same campaign.

Now the explicit design constraint makes sense. The JD says systems must be scalable across segments, geographies and program types. That clause is a warning against building three bespoke pipelines, because a fourth program is always coming. The reusable thing is a program abstraction; the throwaway thing is a one-off per audience.

The hardest seam in a PLG-to-enterprise business is the self-serve-to-enterprise handoff and it is exactly where GTM plumbing earns its keep. Product emits a signal - seats growing in one org, usage crossing a threshold - and the system has to translate that into a sales motion without a human watching every account.

The audience itself changes your craft. Engineers are the buyers and users, which reshapes enrichment, qualification and personalization in concrete ways.

The single idea that separates a GTM Engineer from an automation tinkerer is building a program as a primitive. Define it once and every future program becomes a configuration instead of a new build.

A program primitive has four parts. Hold them together and you have an abstraction; pull them apart per campaign and you have a maintenance problem waiting to happen.

The trap on the other side is bespoke automations per campaign. One marketer asks for a Zap, then another asks for a slightly different Zap and a year later there are forty undocumented flows that only one person understands and nobody dares to touch. That is the mess the JD is hiring you to prevent, not produce.

Knowing where to expose a knob versus hardcode it is the judgment call that keeps a primitive usable. Config-over-code lets non-engineers run programs without filing tickets; too much config creates a fragile machine anyone can break.

Documentation, runbooks and training are first-class deliverables in this role, not chores you do after the real work. The JD lists keeping the team self-sufficient as a responsibility. A primitive nobody else can operate isn't generalizable; it's a bus-factor of one.

When an interviewer hands you a messy ask, the systems-thinking move is to refuse to build the one-off and reframe it as a primitive out loud.

1. 1Restate the underlying need. Strip the specific ask to the recurring pattern beneath it.
2. 2Name the primitive. Show the request is one instance of a reusable audience + entry + actions + measurement shape.
3. 3Mark the config surface. Say which knobs a non-engineer would tune and which logic stays fixed.
4. 4Define success and the feedback loop. State the metric the program reports and how you'd know it's working.

The hiring manager will probe whether you can turn an ambiguous mandate into a concrete plan. Have a 30/60/90 ready and anchor every milestone in toil removed rather than tools touched.

Start from the bar Cursor actually sets. This is a small, flat, talent-dense team and the expectation is a functioning senior IC who ships from week one, not a junior who ramps for a quarter. Your plan should open with something shipped, not something studied.

Day 30 is reconnaissance with a deliverable. You map how data flows today, where the manual handoffs are and which workflow burns the most human hours. The output isn't a doc for its own sake; it's a ranked list of friction with the most impactful target named and quantified.

1. 1Map the stack. Inventory the tools, integrations and data flows that exist, including the undocumented Zaps and spreadsheets.
2. 2Quantify the toil. Find where humans copy-paste, reconcile or manually route - and put hours or error rates on it.
3. 3Pick the wedge. Name the one workflow whose automation buys the most time or removes the most risk and say why.

Day 60 turns the wedge into a shipped system with a feedback loop attached. Day 90 is the proof you build primitives, not one-offs: the same workflow or its abstraction, gets adopted by a second team or extended to a new segment without you rebuilding it.

Underneath all three horizons is one scorecard and it isn't artifacts. The unit you're measured on is impact: human hours removed, manual steps eliminated, programs that now run without you in the loop.