GTM engineering: what a GTM engineer does – and when you need one

Why everyone suddenly wants a GTM engineer

When I talk to revenue teams about their stack, there's one question I've been hearing more than any other: “Do we need a GTM engineer?” It's a fair question. The stack has grown: CRM, enrichment, a sequencer, intent data, a dozen automations, plus the first AI tools. Every tool has someone who brought it in, yet nobody owns making the whole thing work as a system that produces pipeline.

Marketing ops runs campaigns and automation, sales ops handles territories and quotas, RevOps owns process and reporting. In between sit the handoffs: who gets the lead? Which signal triggers which play? Where does the data come from, and who checks whether it's right? Pipeline gets won or lost at those handoffs, and on many teams nobody owns them.

That gap is where GTM engineering comes in. The role has picked up a lot of attention, and it's already changing again. The first wave was mostly about workflows. With AI agents, the work is shifting from wiring individual automations toward designing a system with a knowledge base, permissions and approvals.

I'll go through what a GTM engineer does day to day, how the role differs from RevOps and its neighbors, when to hire and when an external engineer or agents are enough. At the end I'll also say where I stand myself, since I call myself an AI-native revenue marketing engineer. That's close, though not quite the same thing.

One thing up front: a tool is not a system.

What is a GTM engineer, and where did the role come from?

A GTM (go-to-market) engineer builds and runs the technical systems a company uses to find customers, engage them and hand them to sales: data flows, enrichment, signals, routing, automation and, increasingly, AI agents. What sets the role apart from classic ops roles is less the toolkit and more the mindset. People in this role think like engineers: they break revenue processes into components, automate them, test them and measure whether they work.

The term was popularized by Clay, the company behind the enrichment and GTM workflow platform of the same name. In Clay's own guide to the role, the company says it coined the term in 2023. When it announced its Series C in August 2025, Clay described itself as the pioneer of the role, as Crunchbase News reported. Keep in mind that this is a vendor's account, and the vendor benefits directly from the role existing. I couldn't find an independent source on who used the term first.

Growing demand is still visible, at least in job postings. The data company Bloomberry analyzed roughly 1,000 GTM engineering job postings and reports a 205% year-over-year increase in new roles in 2025. eMarketer picked up that figure in an FAQ. I'd keep two caveats in mind. First, the base is small: triple-digit growth on roughly a thousand postings shows a trend, and it's a long way from a mass market. Second, job postings measure demand for a title, and what companies mean by that title varies a lot.

I find another number from the same analysis more interesting: according to Bloomberry, SQL and Python each appear in 38% of postings. Flip that around and close to two-thirds of postings don't explicitly ask for SQL. So the role is broader than its name. Many companies hiring under this title want someone who connects tools, keeps data in order and automates plays. That person doesn't have to be a software developer.

In the German-speaking markets where I do most of my work, the title is still rare. The work itself has been around for years, under names like marketing automation manager, RevOps engineer or simply “the person who actually understands HubSpot.” The definition I work with: a GTM engineer is responsible for reliably turning data and signals into the right action with the right person, and that has to show up in pipeline.

What does a GTM engineer do?

In job postings, the role often reads like tool operation: “experience with Clay, HubSpot and Zapier.” In practice, it spans six closely connected areas. Master only one of them and you build islands.

Data and enrichment

Every GTM system rests on account and contact data that's complete, current and consistent. That means building enrichment pipelines that query several data sources in sequence until a field is filled (often called a waterfall), normalizing industries, countries and company sizes, and preventing duplicates. It also means recording the origin and date of each record. It sounds pedantic, but under GDPR and similar privacy laws it helps you show where personal data came from.

Signals

Which events mean an account is relevant right now? New job openings, a leadership change, a funding round, repeat visits to the pricing page, third-party intent data. The engineer makes these signals technically available and condenses them into a priority. How fit, intent and timing work together is covered in depth in my article on intent scoring with fit, intent and timing.

Routing

A lead that lands with the wrong owner or sits in a queue for four hours often costs more than a lead that never came. Routing logic decides who gets an account or contact: by territory, segment, existing owner, score and capacity. On top of that come fallbacks for everything that isn't clear-cut (which is more than you'd expect on the first draft).

Workflows and plays

A play connects a signal to an action. Say an account visits the integrations page three times: it gets researched, the buying committee gets filled in, a draft gets written and a task gets created for the owner. Plays like this get built in Clay, in automation tools such as n8n, Make or Zapier, in HubSpot or Salesforce workflows, or in custom code.

AI agents

Now that LLMs are reliable enough for research, classification and drafting, agents are part of the toolkit. The engineer decides which steps an agent takes on, what context it works with and how its output gets checked.

CRM architecture

Objects, properties, lifecycle stages, associations between contacts, accounts and deals. It's the least glamorous of the six areas and the most important. Every automation, every report and every agent sits on top of this data model. If it's crooked, everything above it is crooked.

What all six have in common is the goal: someone who does this role well leaves behind systems that keep running without them. In theory, at least. More on that below.

Define the role by its tools and you'll get someone who operates tools. A GTM engineer is responsible for making data turn into pipeline.

GTM engineer vs. RevOps, marketing ops, sales ops and growth engineer

I get asked about the boundaries more than anything else, and most org charts leave them unanswered. The roles overlap, but they have different core questions and get measured on different things.

Clay draws the line to RevOps this way in its guide: RevOps keeps the existing motion running, GTM engineering changes what the motion is. I find the distinction useful, if a bit too neat for real life. At companies with 50 to 200 people, RevOps and systems building often sit with the same person, who then has two jobs, and the more urgent one always wins. Usually that's the forecast for the board call. The new play waits.

The role most often confused with this one is the growth engineer, who usually works inside the product: onboarding, activation, upgrade paths in a self-serve model. In sales-led SaaS with multi-stakeholder buying committees, the payoff lies elsewhere, before the product: in accounts, roles and handoffs to sales.

The way I usually put it: RevOps owns the process, the GTM engineer builds the machine inside it, and marketing owns the message that runs through the machine. Take one of them away and the machine keeps running, just in the wrong direction.

Which skills does a GTM engineer need, and which stack?

When I look at why GTM systems fail in practice, it's rarely missing coding skills. More often, what's missing is an understanding of how a deal actually comes together. So this skill sits at the top of my list:

• Revenue understanding: ICP, buying committee, deal stages, sales cycle. If you don't know why an account buys, you'll automate the wrong steps.
• Data modeling, meaning how contacts, accounts, deals and activities relate. SQL helps, but it isn't the core.
• APIs and integrations: REST APIs, webhooks, authentication, rate limits. A large part of the job is getting systems to talk to each other reliably.
• Automation with workflows that catch and flag errors. The errors that get passed along quietly are the expensive ones.
• Working with LLMs and agents: providing context, structuring output, checking results. Prompting is the smallest part of it.
• Documentation and communication, which tend to get underrated. That means writing specs other people understand, and talking to sales in a way that gets the systems used.

It helps to think of the stack in layers. The tools inside them change; the layers stay:

Examples of tools in these layers: a CRM like HubSpot or Salesforce as the system of record, Clay for enrichment and table-based workflows, n8n, Make or Zapier for automation, a sequencer for outreach and, at larger data volumes, a data warehouse. Agents add LLMs such as Claude via API and, increasingly, the Model Context Protocol (MCP), which gives agents a standard way to access tools and data. The right tools depend on your stack. What matters more is that every layer has an owner.

What separates a good engineer from a busy one rarely shows in the workflow itself. It shows in what sits next to it: a spec. This is the kind I expect for every production automation:

Purpose:     Demo requests reach the right owner in < 10 min
Trigger:     “Demo” form or handoff from chat
Inputs:      CRM contact, enrichment (size, industry, country)
             Score from fit × intent × timing (0–100)
Logic:       1  Suppressed or existing customer? → CSM, stop
             2  Account has an owner?           → owner
             3  Score ≥ 70 and tier 1/2         → AE round robin, region
             4  Score 40–69                     → SDR queue, task 4 h
             5  Score < 40                      → nurture, no task
Fallback:    Enrichment missing → queue “manual review”, SLA 2 h
Permissions: Routing = L3 · approved rule
             Message to the lead = L2 · only after go
Owner:       RevOps lead · reviewer: head of sales
Metrics:     Speed to lead, misrouting rate, meetings from inbound
Change log:  v3 tier 2 threshold 75 → 70 (go: head of sales)
             v2 added existing-customer check (misrouted to SDRs)

A spec like this is unglamorous work, so it's rare. It answers the questions someone will ask three months from now: why did this lead end up with an SDR? Who changed the threshold? What happens when enrichment fails? A workflow without a spec works as long as the person who built it is still around.

How AI agents change the GTM engineer role

The first generation of these systems ran on deterministic workflows: if A happens, do B. That's stable and easy to test, but rigid. Every new exception is a new branch, every strategy change a rebuild. After a year, an active team has dozens of these workflows, with the logic scattered across Clay tables, Zaps and CRM rules.

Agents work differently. Within a frame, they make their own judgment calls: is this account relevant? Which role is missing from the buying committee? Which message angle fits? That makes them more flexible, and it moves the engineering work. “How do I wire step 4 to step 5?” matters less. What matters more is what knowledge the agent works from, what it's allowed to do and who checks it.

That creates four new core tasks:

1. Knowledge goes into a knowledge base. ICP, buying committee, message angles, approved claims and routing rules belong in one shared knowledge base that every agent works from. When strategy changes, you update one module and leave twenty workflows alone. I describe how to structure one in my article on the AI marketing knowledge base.
2. Permissions per task. In RevPrime^®, I use a permission ladder: L0 read, L1 propose, L2 write after go, L3 approved rule. Each agent gets the level it needs for each task, and nothing above it.
3. Approvals for anything with external effect. A message to a contact, a budget, a new audience: all of it needs a human go. Internal prep work may run on approved rules.
4. A log for every decision. Every proposal, every go and every no goes into the change log with a reason. Recurring corrections become rules in the knowledge base.

The division of labor gets sharper as a result. Agents research accounts, enrich data, classify signals, write drafts, propose routing changes and prepare reports. Humans decide which accounts get priority, what goes out to contacts, which rules apply and when the ICP changes. How that's safeguarded in detail is covered under governance in RevPrime^®.

Agents do the work. Humans make the decisions. The GTM engineer of the next few years will mostly build the guardrails in between, with individual automations becoming a side job.

In projects I keep seeing teams bolt AI onto their existing workflows and get more of everything: more research, more drafts, more sequences, more reports nobody reads. Output ↑. Pipeline →. AI without a system just produces the wrong thing faster. For a broader view of which agents move the needle in B2B marketing, see my guide to AI agents for B2B marketing.

Hire, build externally or use agents? The decision matrix

“GTM engineer, yes or no?” usually falls short. The more useful question is what kind of GTM systems work you need right now, and how much of it. That comes down to two factors. First, how mature your revenue logic is: are ICP, buying committee, priorities and handoffs to sales defined and documented? Second, how much ongoing systems work there is, meaning new plays, experiments, integrations and data maintenance.

Two things stand out to me in this table. The hiring question only comes up once the revenue logic is in place, and that's deliberate: anyone who joins a company without a clear ICP becomes a reluctant strategist or builds whatever gets shouted loudest. Agents also change the math, without making the role redundant. When they take over research, routing and reporting, you often don't need another full-time hire. You need an owner who runs the system. That can be a RevOps person who gets the time to do it.

Before you post a job opening, go through these points without kidding yourself:

• Your ICP, including exclusion criteria, is written down somewhere outside the founder's head
• The buying committee for your typical deals is written down: roles, objections, proof
• There's a clear definition of when a lead or account gets handed to sales
• The CRM is the system of record, with no competing versions of the truth in spreadsheets
• You can name at least five concrete plays the person should build
• The role reports to someone who carries revenue responsibility
• You know how you'll measure the person after 90 days, and the answer is pipeline

What does a GTM engineer cost, and what risks come with the hire?

I haven't found reliable salary data for this role in the German-speaking markets I work in, and I won't make any up. The only systematic source I know is the Bloomberry analysis mentioned above. It reports a median advertised salary of around $127,500. That figure comes from salaries listed in job postings, not from actual contracts, so treat it as a rough signal rather than a benchmark. Still, it points in one direction: companies are looking for a senior profile that combines revenue understanding, data skills and engineering. People like that aren't cheap.

Salary is only part of the math, though. Enrichment platforms and data providers often bill by credits or volume, and LLM usage by tokens. Those costs grow with every new play, and that often only becomes visible when the invoice arrives. Then there's ramp-up: even an experienced engineer needs weeks to understand your product, market, stack and the unwritten rules of your sales team.

Maintenance is the part people tend to underestimate. APIs change, fields get renamed, vendors rework their pricing, and after the first year much of the work is upkeep. Finally, every new play affects sales, so without time for alignment the engineer ends up building past the people who are supposed to use it.

Some risks don't show up in any budget. The biggest is the single point of failure: one person spends a year building a system nobody else understands. When they leave, the logic behind routing, scoring and data flows walks out with them. Shadow systems are a close second, meaning logic that lives in Clay tables or personal automation accounts and never shows up in the CRM. The third risk is data protection. If you enrich contact data and reach out to people automatically, you need a legal basis, documented sources and a process for handling objections. Sort that out with your data protection officer before you start.

A system only one person understands isn't a system. It's a risk with a salary.

Example: the first 90 days with a GTM engineer or an agentic system

A worked, fictional example makes the decision more concrete. Imagine a scale-up selling SaaS for maintenance planning to manufacturers. Around 80 employees, Series B, six account executives, four SDRs, two people in marketing and one RevOps manager. The CRM is HubSpot, plus a sequencer and a Clay account an SDR set up a year ago. The symptoms are familiar: inbound leads often land with the wrong owner, outbound runs on a single sequence for everyone, and nobody can say which activity leads to pipeline.

Option A: they hire a GTM engineer

The first three weeks go into onboarding and an audit: data model, properties, existing workflows, conversations with sales. The new hire finds duplicates, orphaned properties and three routing rules that contradict each other. In weeks four to eight, they build an enrichment pipeline, fix inbound routing and set up the first signal-based plays, for instance for accounts posting maintenance roles. Weeks nine to twelve add the first AI workflows for account research.

After 90 days, a lot runs better, though two things are still open. Which segments have priority, which buying committee roles get engaged and which message applies to whom was pieced together from conversations along the way. That revenue logic isn't written down anywhere; it lives in the workflows. Documentation, meanwhile, covers whatever the engineer happened to think was important.

Option B: they set up an agentic system

In option B, the work starts at the revenue logic, and the stack comes later. The first two weeks go to diagnosis and the knowledge base: ICP with exclusion criteria, buying committee, message angles, priorities and routing rules, agreed with sales and marketing. In weeks three and four, CRM, Clay and the website get connected, with read access for analysis and write access only for approved actions. From week five, the first three agents go live: a Signal Agent for prioritization, an Outreach Routing Agent for correct assignment and a Pipeline Reporting Agent for the weekly review. All with a human go and a change log.

From week nine, it's about cadence: daily proposals, a weekly pipeline review, and the RevOps manager takes over as owner of the system. She doesn't need to code for that. What she needs is time and explicit accountability.

Honestly, neither option is better by default. In my experience, the best sequence is often a combination: revenue logic and system first, then a GTM engineer who builds on top. That person then walks into a knowledge base, documented rules and running agents, and can start building new plays in week one. There's little legacy to clean up.

What to measure after 90 days

Whichever option you pick, don't measure the result by the number of workflows built. These metrics tell you more:

• Speed to lead: time between a request and first contact by the right owner.
• Misrouting rate: share of leads and accounts that have to be reassigned manually.
• Data coverage: share of tier-1 accounts with complete required fields and a documented source.
• Correction rate: share of agent proposals that get changed before the go. If it stays high, rules are missing.
• Pipeline from plays: opportunities and pipeline value traced back to a signal or play.
• Documentation coverage: share of production automations with a spec, an owner and a change log.

The most common GTM engineering mistakes

Tools first

A team buys Clay, an intent provider and an AI SDR tool, then looks for someone to “make it all work.” The architecture is decided before anyone has asked which problem it's supposed to solve. Method before tool: revenue logic first, then the tools that execute it.

No revenue logic

Automation without a clear ICP, without a buying committee model and without defined handoffs to sales scales assumptions. The engineer then builds very efficient processes for accounts that will never buy.

No documentation

“It's in the workflow” isn't documentation. Every production automation needs a spec, an owner and a change log. That takes maybe an hour per workflow and saves days later.

Single point of failure

When one person built the entire GTM system and is the only one who understands it, the company is exposed, at the latest on the day that person is out sick or hands in their notice. At least one other person has to be able to read the system and operate the basics.

Counting workflows as success

Twenty new automations sound like progress. Activity isn't impact. Pipeline is impact. Measure someone on the number of builds and you'll get lots of builds.

Agents without governance

The newest mistake is giving agents write access to the CRM or sequencer without a permission ladder, approvals or a log. That works right up until an agent emails a hundred contacts with the wrong message.

My take: GTM engineer, revenue marketing engineer and where igromo fits

People often ask me whether I'm a GTM engineer. Partly, I'd say. I call myself an AI-native revenue marketing engineer, and each of those words is deliberate.

The overlap is big. Like a GTM engineer, I build instead of recommending: I connect CRM, ads, data and web, write the agents, define routing and signals and hand over a system that runs. I think in data flows, specs and failure cases. Anyone watching me work would probably give me that title.

The difference lies in the starting point and the yardstick. I come from more than 15 years of B2B revenue marketing. Before I build anything, I want to know who you sell to, who sits on the buying committee and which message carries for which role. For me, revenue logic isn't a byproduct of the workflows. It's their prerequisite. AI-native means agents are part of the architecture, not an add-on. Everything gets measured against pipeline and revenue; nobody cares in the end how many automations I shipped.

The second difference: I don't want to be the person your system can't run without. Ideally, a GTM engineer is a permanent part of your team. I build a system and hand it over with documentation so your team can run it. The knowledge base sits at the center, with eight core agents plus the custom ones your business needs, a permission ladder, a human go and a change log. All of it runs inside your tools; I don't build parallel universes.

That leads to the two ways I work. With Build, I set up marketing as an agentic system from the start: revenue logic and knowledge base from day one, hub and data connections from week three, the first agents from week five. That fits if you're wondering whether this role should be your first hire. With Repair, I couple an existing setup back to pipeline and plug agents in where your team burns time today. It's the right route if you already have tool sprawl and can no longer tell what's working.

If you need someone who builds new outbound experiments and debugs Clay tables every day, hire a GTM engineer. I'm not that person, and I don't want to be. What I can do is make sure they walk into a system they can build on, without having to fix it first. You can read more about how I work on my about page.

My concrete recommendation, in four steps:

1. Write down your revenue logic. ICP, buying committee, message angles, handoffs to sales. If you can't, you've found your real problem, and an engineer wouldn't solve it.
2. Inventory the systems work. List every recurring task in data, signals, routing and reporting, and mark which ones are clear enough for agents.
3. Start with two or three agents. The ones with the biggest pipeline impact, with a human go and an internal owner.
4. Decide on the role after 90 days. If building new plays fills a full-time job by then, hire. The person then walks into a system they can learn.

If you want to know where you sit in the matrix, book a free 30-minute diagnosis call. We'll look at your stack and your revenue logic and work out whether Build, Repair or your own GTM engineer is the better next step. No pitch.