Build the machine that
makes revenue happen.

A GTM engineer builds and operates the revenue system: the data infrastructure, enrichment, scoring, routing and automation that decide who a company sells to, when, and with what message. Sales teams talk to customers; GTM engineers build the machine that makes those conversations happen. It is an engineering role with a revenue mandate rather than a sales role with tools.

Four layers, and most teams run one tool per layer: a system of record, an enrichment layer that composes several data providers into a waterfall, an orchestration layer that scores, routes and triggers, and a sequencer that sends. Clay is the most common answer for enrichment and prospecting, n8n for generic workflow glue, LeanData for Salesforce-native routing. Cargo is the system of record and the orchestration layer together: companies, contacts and deals are stored, synced and unified in Cargo, built for scale (billions of records, SQL throughout). The engine that scores, routes and acts on them is defined in code the team owns. The CRM is the engagement layer reps work in, not the source of truth.

One where those are the primary interface rather than an escape hatch. The practical test is whether you can define a data model, write the logic, and deploy it without opening a UI, and whether the result is a file you can review in a pull request. Cargo is built for that path: the engine is declared in TypeScript, planned as a diff and deployed from a CLI, and it is operable over MCP so a coding agent can change it directly. n8n is the honest alternative when you want to own the runtime and are willing to build the GTM semantics yourself.

Very few, which is the gap the role keeps hitting. Most GTM tools keep their logic in a visual builder or a spreadsheet, so there is no diff, no history of the system as a whole, and no way to replay a past run against new logic. What to look for: the logic stored as files in your own repository, a plan step that shows what a change will do before it does it, per-run execution logs, and the ability to roll back. Cargo is designed around that model; a warehouse-plus-dbt stack gets you part of the way for the data layer but leaves routing and actions unversioned.

Owning all four in one place is the distinguishing requirement, because splitting them across tools is what creates the reconciliation work the role exists to remove. Point tools cover one each: enrichment platforms own data, routing products own assignment inside a CRM, sequencers own sending. An orchestration layer that treats accounts, contacts, territories, enrichment waterfalls, scoring and routing as first-class primitives is what lets one person hold the whole engine. That is the category Cargo, and to a lesser extent LeanData and Default within their scopes, sit in.

Use a deterministic workflow whenever the rule can be written down, and reserve agents for the steps where the input is unstructured or the judgement is genuinely open. Routing, scoring thresholds, deduplication and field mapping are rules: an agent makes them slower, more expensive and non-reproducible. Research, summarising a call, drafting a first message and classifying an ambiguous signal are judgement. The failure mode in both directions is real, but the expensive one is putting an agent where a rule belonged, because it becomes untestable.

End to end means one system holding the data model, the enrichment, the scoring, the routing, the plays and the agents, with a single place to review a change to any of them. Cargo is built for that specific shape, which is also its limitation: teams that will not adopt a CLI or read a diff get a smaller share of what it is for. A team that only needs inbound routing and scheduling is better served by a narrower tool.

Yes. Across 1,350 job descriptions analysed in 2026, 59 percent require API work, 40 percent Python, 38 percent SQL and 27 percent JavaScript. With AI coding agents, reading and reviewing code matters more than writing every line by hand, but the reviewing still requires knowing what you are looking at.

The US median is $159K, from 509 disclosed salaries in postings between April and July 2026, with senior roles at a $175K median. Full breakdown by seniority, location and remote status is on the salary page.

Charter, not seniority. RevOps runs and governs the existing revenue process: forecasting, territory design, CRM hygiene, reporting. GTM engineers build new revenue machinery. In smaller companies one person does both, and in most postings the GTM engineer reports into RevOps or Revenue Systems leadership.