What is a GTM engineer? Skills, salary and how to hire

A GTM engineer is a revenue team member who builds automated go to market systems instead of running go to market by hand. They own the chain of data, enrichment, scoring, routing and outreach that used to sit across sales ops, marketing ops and a team of SDRs. What they leave behind is a system that keeps running after they log off.

That is the short version. The long version matters more, because the title is three years old, it is applied inconsistently, and a large share of the people carrying it are not doing the same job as each other.

This guide covers what the role actually involves, how it differs from RevOps, what the job ads ask for, what the market pays in the US and the UK, how many of these jobs genuinely exist once you strip out the title inflation, and how to hire and assess one without guessing.

The short answers

• Definition. A GTM engineer builds and owns automated revenue systems across three layers: data foundation, data modelling, and data activation.
• Origin. Clay coined the term in 2023. It spread through the outbound and RevOps community during 2024 and 2025.
• Pay. US medians reported in 2026 range from around $94,000 to around $176,000 depending on whose data you read and whether the figure is base or total compensation.
• Skills. Clay appears in about 69% of job ads, a CRM in about 55%, and Python or SQL in about 30%.
• Volume. Broad aggregate counts run to 3,000 or more open roles. Counts restricted to the literal job title land closer to 45 to 100 new postings a month.
• Who needs one. Companies that trust their numbers but cannot execute enough experiments. Companies that cannot trust their numbers need RevOps first.

Where the term came from

Clay coined “GTM engineer” in 2023 and has since built a large part of its brand around it. The term filled a real gap. There was no accepted name for the person who sat between the revenue team and the data, who could write a Python script on Monday and argue about ICP definition on Tuesday.

Before 2023 that person was called a sales ops analyst, a marketing automation specialist, a growth hacker, a demand gen lead, or nothing at all. None of those titles described the work. Sales ops implied reporting and marketing automation implied email. Growth meant product, which was usually a different org entirely. The actual work, building systems that generate and qualify pipeline without a human touching each record, had no home.

The term also spread because the economics changed underneath it. Between 2023 and 2026 the cost of building those systems collapsed. Enrichment waterfalls, LLM research steps, and workflow tools that used to require an engineering ticket became things one competent operator could assemble in an afternoon. The tooling made the role possible before anyone thought to name it.

Clay reports around 100 GTM engineering listings appearing each month. Its own team runs the function at co founder reporting level, working “like a product engineering team, with sprints, version control, and release notes”. Very few companies actually run it that way yet, which is worth knowing before you write a job description modelled on Clay’s.

What a GTM engineer actually does

Strip away the tool names and the work sits in three dependent layers. Each one only functions if the layer below it works.

Layer one: data foundation

Records have to be correct before anything can be built on them. This layer covers enrichment jobs, deduplication, merge and purge routines, field hygiene, and the rules that decide which source wins when two systems disagree about a company’s headcount.

It is unglamorous and it is where most GTM engineering projects die. A scoring model built on a CRM where 40% of accounts have a blank industry field will produce confident nonsense, and it will produce it fast enough that nobody checks.

Layer two: data modelling

Once the records are trustworthy, the engineer decides what they mean. This is ICP definition expressed as logic rather than as a slide. It covers fit scoring, intent signal weighting, account tiering, territory logic, and the research steps that turn a company name into a reason to contact that company this week rather than next quarter.

This layer is where commercial judgement shows up. Two engineers with identical technical skill will build very different models, and the difference comes from whether they understand the sales motion they are feeding.

Layer three: data activation

The system does something. Leads route to the right owner, sequences fire with the right message, records update themselves after a call, a slack alert fires when an account crosses a threshold, and a dashboard shows whether any of it moved a number.

Clay describes the working loop as: find a revenue bottleneck, build the workflow that fixes it, prove it on a small batch, and scale what works. Most live job ads for this role say considerably less than that.

A realistic week

Day	Typical work
Monday	Review last week’s experiment results, kill the two sequences that underperformed, pull the accounts that stalled at stage two
Tuesday	Rebuild the enrichment waterfall after a provider’s match rate drops, backfill 4,000 records
Wednesday	Sit with the AE team, find out why the new routing rule is sending mid market accounts to the enterprise pod
Thursday	Build and test a new research step, run it on a batch of 200, read every output by hand
Friday	Ship the batch to 2,000, document what changed, write the release note

Two of those five days involve writing anything technical. Hiring managers routinely budget for the opposite ratio, then wonder why the engineer they hired for Python spends most of the week in meetings.

GTM engineer vs RevOps vs sales ops vs marketing ops

The titles overlap and the overlap is genuine, not just sloppiness. The useful distinction is what each role is judged on.

	RevOps manager	GTM engineer	Sales ops	Marketing ops
Owns	The system of record and the numbers that come out of it	The automated systems that create and qualify pipeline	Territory, quota, forecast hygiene, sales tooling	Campaign infrastructure, attribution, lifecycle stages
Ships	Process, governance, reporting, forecast accuracy	Working workflows, enrichment pipelines, sequences, integrations	Comp plans, pipeline reviews, CRM discipline	Nurture flows, scoring, campaign tracking
Judged on	Whether leadership can trust the pipeline number	Whether volume and quality of qualified pipeline goes up	Whether reps hit quota and the forecast holds	Whether MQLs convert and spend is attributable
Fails by	Building governance nobody follows	Building clever systems that produce nothing commercial	Becoming a reporting service desk	Optimising a metric the sales team does not respect
Typical background	Finance, consulting, sales ops, analytics	Sales, growth, data, occasionally software engineering	Sales, sales management	Demand gen, martech

The practical test is short. If you cannot trust your numbers, you need RevOps. If you trust your numbers but cannot execute enough experiments against them, you need a GTM engineer. Hire the second while the first problem is open and you get the same confusion, automated.

We wrote a longer version of that decision in GTM engineer or RevOps manager: which do you need?.

A fourth answer is available and unpopular: some companies need neither. They need one clean CRM migration and a sales manager who runs a real pipeline review, which is a two month project with a budget line rather than a headcount.

The skills that actually appear in job ads

What a GTM engineer should know and what employers ask for are different lists. An analysis of 3,342 GTM engineer job postings published in March 2026 by GTME Pulse gives the frequency of the second one.

Requirement	Share of postings
Clay proficiency	69%
CRM, HubSpot or Salesforce	55%
Outbound sequencing tools	45%
Python or SQL	30%
API integration	25%
Workflow automation, Make, n8n or Zapier	20%

Clay is now a de facto requirement. Nearly seven in ten ads name it. The 2026 State of GTM Engineering survey, which collected 228 responses across more than 30 countries, put Clay adoption at 84% overall and 96% among agencies. No other tool in this category has that position. A candidate who has never touched it is not disqualified, but they are starting behind.

The other number worth staring at is 30%. Only three ads in ten require code, and this is the detail hiring managers get wrong in both directions. Some write a job description demanding five years of Python and then wonder why nobody applies. Others assume the role is a no code job and hire someone who cannot debug an API response, which caps the systems they can build at whatever the tool’s user interface allows.

Code sets the ceiling, not the entry point. The same 2026 survey found high code engineers earning $135,000 against $90,000 for low code operators, a spread of $40,000 to $45,000 inside one job title. The market has already priced the difference.

The skills nobody puts in the ad

Three capabilities separate a good GTM engineer from an expensive one, and none of them appear on a requirements list.

Diagnostic sequencing. When pipeline drops, does the candidate check the obvious causes first, or start with the interesting theory? Ops work rewards boring order. The person who checks whether the enrichment provider changed its schema before theorising about market conditions will fix problems faster for years.

Restraint. A GTM engineer with no constraint will automate things that did not need automating. The good ones price the system before they build it, and they are willing to say it is not worth building.

Translation. If the AE team does not understand why a lead was routed to them, they will ignore the routing. Worked around systems are worse than no system, because they keep producing data that looks real.

What GTM engineers get paid

Salary data for this role is messy, and the mess itself is informative. Different sources disagree by more than $80,000 for the same title. Here are the 2026 figures side by side, with what each one is actually measuring.

Source	Figure	What it measures
ZipRecruiter, August 2026	$94,573 average, $91,500 median, $78,000 to $108,500 interquartile	Aggregated US postings, base only. ZipRecruiter does not publish the role mix, and a figure this low suggests it is catching junior and adjacent roles
2026 State of GTM Engineering, 228 respondents	$135,000 US median base	Self reported by practising GTM engineers
GTME Pulse, 3,342 postings	$132,000 median	Advertised salary across 3,342 postings. Selection method not published
Apollo, January 2026	$176,000 median total compensation, $132,000 to $241,000 range	Total compensation including variable and equity

They are not contradicting each other. They are measuring four different things. If you are budgeting a hire in the US, the number you want sits between the survey median and the postings median, so roughly $130,000 to $140,000 base for a mid level hire who can build without supervision.

US bands by seniority

Level	Base	Total compensation
Junior, 0 to 2 years	$90,000 to $120,000	$110,000 to $140,000
Mid, 3 to 5 years	$130,000 to $170,000	$160,000 to $200,000
Senior, 6 years plus	$170,000 to $210,000	$210,000 to $280,000
Lead or staff	$180,000 to $250,000 plus	Varies widely with equity

Figures from Apollo and GTME Pulse, January and March 2026.

What moves the number

• Code. Python or SQL adds $45,000 to the median. This is the largest single lever.
• Location. San Francisco, New York and Austin account for around 45% of US postings. An SF based role requiring Python advertises at $150,000 to $180,000. A fully remote role with no coding requirement advertises at $100,000 to $120,000.
• Company stage. Series B and Series D companies lead at around $145,000 median. Seed stage pays less in cash and more in story.
• Equity. Only 35% of postings mention equity at all, and nearly 68% of surveyed practitioners report holding little or none that is meaningful. In a negotiation, treat it as upside on top of the cash number.

The UK picture

The bigger UK difference is naming. Many British companies are hiring the same job under RevOps manager, marketing operations manager or sales operations manager. If you are recruiting in the UK and searching only for the literal title, you are looking at a fraction of the available market. If you are a candidate in the UK, applying only to roles called GTM engineer will cost you most of the opportunities.

Non US practitioners report a median of $75,000 against $135,000 for their US peers. The report frames that as an 80% premium for US talent. Some of the gap is genuine market rate. Some of it is that the strongest non US operators are increasingly employed by US companies on US adjacent packages, which pulls them out of the local sample entirely.

How many GTM engineer jobs actually exist

The counts disagree by two orders of magnitude, and which one you believe changes what you budget for. There are either 3,000 open GTM engineer roles or about 45 new ones a month.

The broad count is real. Aggregators reported more than 3,000 openings in January 2026, up from more than 1,400 in mid 2025. Growth across 2025 as a whole ran at 205%. Neither Apollo nor GTME Pulse publishes how it selected postings, and the size of the gap against title-restricted counts points to keyword matching that catches any ad mentioning GTM engineering anywhere in the text, including RevOps roles listing it as a nice to have.

Kyle Poyar’s narrower count, restricted to postings genuinely titled GTM engineer, found 45 in a month and 128 across three months in mid 2025. Against other revenue titles in the same window there was roughly one GTM engineer posting for every 5 RevTech or MarTech roles, every 14 RevOps roles, every 35 sales ops roles, and every 92 SDR roles. Clay’s own figure of around 100 listings a month sits between the two.

Then there is the supply side. Poyar found that 45% of people presenting as GTM engineers are agencies or consultants, not employees. Clay’s partner directory alone lists more than 120 agencies. A large share of your inbound will be agencies pitching a retainer. Median minimum fees sit around $5,000 a month and median maximums around $8,000, on a full range of $1,000 to $33,000.

What this means if you are hiring

The talent pool of people who have done this job in house, at your stage, for more than eighteen months is small. Small enough that you should not build a hiring process around filtering a large applicant pool. You should build one around evaluating a small number of people accurately.

It also means the title on a CV proves very little. A person who called themselves a GTM engineer in 2024 was making a bet on a new label. Some of them were doing sophisticated systems work. Others renamed themselves and carried on sending sequences. The title does not separate them and neither does the interview.

What this means if you are a candidate

The scarcity is in your favour, with a condition attached. Employers are increasingly suspicious of the title precisely because it has been claimed so widely. Evidence beats claims. A candidate who can show a system they built, explain why they built it that way, and name what it produced will beat a candidate with a longer CV every time.

Do you need a GTM engineer?

Five tests. If you cannot answer yes to at least three, the hire will not work yet.

1. Can you trust your pipeline number today? If leadership argues about whether the forecast is real, you have a RevOps problem. Automation applied to untrusted data produces more untrusted data, faster.
2. Do you have more validated ideas than capacity to run them? The role exists to increase experiment throughput. If your team is not generating experiments, adding an engineer gives them nobody to build for.
3. Is your ICP narrow enough to encode? A GTM engineer turns targeting into logic. If your answer to “who do we sell to” is a paragraph of adjectives, that logic cannot be written.
4. Does someone own the commercial outcome? The engineer builds the system. Someone still has to be accountable for whether pipeline goes up. If that person does not exist, the engineer will be judged on activity.
5. Can you name the bottleneck in one sentence? “We cannot research accounts fast enough to personalise at volume” is a brief. “We need to be more efficient” is not.

When not to hire one

• Under roughly 15 people on the revenue team. At that size the founder or the first ops hire covers it. Read what to look for in a first ops hire.
• When the real problem is that your product does not sell. Automation puts a bad message in front of more people, faster, at higher volume, with better formatting.
• When you have no CRM discipline. If reps do not update records, no system built on those records will function.
• When you want the cost of an SDR team removed. The role can reduce the headcount required to generate pipeline. Pitch it internally as a one for one swap and you have set the hire up to fail before they start.
• When nobody senior will defend the experiments. Early experiments fail. If the first failure triggers a review, the engineer will stop taking risks and you will have bought an expensive maintenance function.

How to hire a GTM engineer

Write the job description backwards

Most GTM engineer job descriptions are a list of tools. That is why they attract the wrong people. Start with the bottleneck instead.

Open with the specific problem: what you sell, to whom, what breaks at volume today, and what a good six months looks like. Then list the systems the person will own. Put the tools last, and mark which are required and which are learnable in a month. Clay is learnable. Commercial judgement is not.

State the salary band. In a market where 65% of postings say nothing about equity and candidates have learned to distrust the title, publishing the number filters in your favour.

Related reading: why your RevOps job description attracts the wrong people.

Expect a small, noisy pipeline

Applicants arrive in three groups: agencies pitching retainers, operators with real systems experience under a different title, and people who added the title to their profile last year. The middle group makes the best hire and matches your keyword filter least, because their last job was called RevOps analyst or growth operations.

So search on the work. A marketing ops manager who built an enrichment waterfall and a lead scoring model has done this job. A person titled GTM engineer who ran sequences somebody else built has not.

Do not rely on the interview

An interview measures how someone describes their work. It does not measure the work. For a role this new, that gap is unusually wide, because the vocabulary is easy to acquire and the underlying skill is not. Anyone who has listened to a few podcasts can talk fluently about waterfalls, signals and orchestration.

The problem got worse rather than better in the last two years. Written applications no longer carry information. CVs and cover letters are drafted with the same tools for every candidate, so the written layer tells you almost nothing about the person who submitted it. That pushes the entire weight of the decision onto the interview, which was never built to carry it. We covered this in AI written applications broke technical screening.

Use a work sample

The reliable method is to watch someone do a piece of the job. Give them a realistic problem, ask them to work through it out loud, and record it.

A recorded, narrated task surfaces four things an interview cannot:

• Decision sequencing. Whether they check obvious causes before speculative ones.
• Elimination logic. Do they rule possibilities out systematically, or jump to a conclusion and then defend it?
• Pause points. Hesitation is information. The question is whether it reads as care or as unfamiliarity.
• Acknowledgement of gaps. In operations, the person who guesses silently is the liability. Listen for whether they say when they do not know.

Compare it to the alternative in work sample tests compared with interviews, and see what a recording shows that an interview cannot.

A four part assessment that works

If you build your own, cover these four areas. Sixty to seventy minutes is enough.

1. Diagnostic. Give them a broken funnel with a real cause buried in the data. Watch how they narrow it.
2. Process design. Ask them to design the workflow that prevents it recurring. Look for whether they consider who maintains it.
3. Data modelling. Give them a messy account list and ask them to build a scoring approach. Look for whether they question the data before modelling it.
4. Communication. Ask them to explain the result to a sales manager who does not care about the plumbing.

Score against a published standard. Ranking three candidates against each other tells you who was best in a sample of three. A benchmark tells you whether any of them clear the bar, which is the question you actually have.

What good looks like in the first 90 days

A GTM engineer who is working out will produce evidence early, because the job has short feedback loops.

Weeks 1 to 4. They map the current state and find at least two things that are broken and nobody knew. They will ask uncomfortable questions about data quality. Let them.

Weeks 5 to 8. One system shipped. Small, tested on a batch, with a measured result attached. Not a roadmap. A working thing.

Weeks 9 to 12. A second system, and the first one still running without their attention. The second half of that sentence carries the weight. Anything that only works while the builder is watching it will break the first week they take off.

If at week twelve you have a detailed audit document and no shipped workflow, the hire is drifting toward consulting. If you have five shipped workflows and no measured result, they are building for the pleasure of building. Both are cheap to correct at twelve weeks and very expensive at twelve months. See why ops hires fail in the first ninety days.

How to become a GTM engineer

The route in is unusual because there is no established pipeline. The 2026 survey found nearly 30% of practitioners are between 18 and 22, and another 25% between 23 and 26.

That works in a candidate’s favour. Credentials carry less weight here than they would in an established function, and demonstrated systems carry more.

Your starting point sets your gap. Most people arrive from SDR or AE roles, from marketing ops, from RevOps analyst positions, and occasionally from software engineering. Sales people have to learn data. Engineers have to learn the commercial motion, and that is the harder of the two to close.

The tool order that works: a CRM first, because everything else attaches to it. Then Clay, named in 69% of ads. Then SQL, which is the cheapest large upgrade available to you. Then Python, if you intend to compete for the top of the band. Around 70% of practitioners now use AI coding assistants such as Cursor or Claude Code, which has taken a lot of the pain out of that last step.

Build one thing and measure it. A certificate proves attendance. What gets you hired is a single system described honestly: the problem, what you built, what it produced, and what you would do differently. One documented system with a number attached beats a page of tool logos.

The label will move. Some of these roles will be called forward deployed engineer, revenue engineer or growth engineer within two years. If you are weighing this against adjacent paths, what RevOps and GTM engineering roles pay has the comparison.

The tool stack, and how much it matters

For reference, the 2026 picture:

Tool	Share	Source
Clay	84% of practitioners, 96% among agencies	State of GTM Engineering survey
Salesforce or HubSpot	88% of practitioners	State of GTM Engineering survey
AI coding assistants, Cursor or Claude Code	around 70% of practitioners	State of GTM Engineering survey
Apollo	40% of job ads	GTME Pulse postings analysis
Instantly or Smartlead	25% of job ads	GTME Pulse postings analysis

Do not over index on this. Tool lists in this category date within a year or two, and a candidate hired for fluency in one platform is a candidate you have to rehire when it is displaced. Hire for the reflex, which is the ability to learn a tool by taking it apart. Clay’s own guidance says the same thing: backgrounds vary widely, so “the reflex is the constant, not the resume”.

The thing worth checking is not whether a candidate knows your stack. It is whether they can explain why they chose the last one they used, and what they would have used instead.

Five mistakes hiring managers make

1. Hiring a GTM engineer to fix a data trust problem. That is a RevOps hire. Getting this backwards is the most expensive mistake on the list, and the most common.
2. Filtering on the title. The strongest candidates are frequently titled something else. Filtering on the literal title selects for people who rebranded early, which is not the same as people who are good.
3. Interviewing for tool knowledge. Tool knowledge is a month of learning. Judgement is years. You can test for the second and most processes only test for the first.
4. Giving the role no commercial owner. Without someone accountable for pipeline outcomes, the engineer is measured on shipping, and shipping is easy to fake with volume.
5. Expecting a result in six weeks. The data foundation layer usually takes longer than anyone budgets for, and skipping it guarantees the two layers above it fail. Set the expectation of a first measured result at week eight.

We looked at the wider version of this pattern in why ops hires fail in the first ninety days.

The title will not tell you who is good

That is the practical problem with hiring a GTM engineer in 2026, and no amount of CV screening solves it. The people who are genuinely good at this work are frequently called something else. A meaningful share of the people using the title are describing work they did not do.

What separates them is watching someone work. Give a candidate a real problem, ask them to narrate it, and record what happens. Sixty five minutes of the actual job tells you more than four rounds of interviews, and it tells you the same thing every time, which is the property a hiring process is supposed to have and almost never does.

Related reading

• GTM engineer or RevOps manager: which do you need?
• What RevOps and GTM engineering roles pay
• How to hire a RevOps manager
• RevOps interview questions that predict performance
• Work sample tests compared with interviews
• What a recording shows that an interview cannot
• Why your RevOps job description attracts the wrong people
• Why ops hires fail in the first ninety days