I Read 82 Live GTM Engineer Job Postings. Zero of Them Say It Replaces Your SDR Team.

TL;DR: I read 82 GTM engineer job postings that were still open on 15 August 2026, pulled from the employers' own applicant tracking systems. Not one describes the role as replacing SDRs. Only 18 mention SDRs at all, always as colleagues the GTM engineer builds for. The single most-required named tool is Clay, in 44 of the 82. Writing code is required in 47; 17 are pure no-code tool configuration. Median advertised midpoint is $168,750, and only 39 of the 82 publish a range at all. The rule that falls out of the data: hire one when you already run a manual go-to-market workflow that works and cannot keep up with it. Do not hire one to go find you a workflow.

"GTM engineer" is a job title Clay says it invented. Clay's own page claims that "since we coined this role in 2023" it has spread to Cursor, Lovable and Webflow, and that about 100 new listings go live every month. The pitch around it is that one technical operator plus AI tooling replaces a team of sales development reps. I wanted to know whether employers say that in a job description rather than a LinkedIn post.

What did the postings actually say?

I started from the public feed behind Cargo's GTM engineer job board, which on 15 August 2026 held 815 unique postings dated April through August 2026. That is a sampling frame, not evidence, so I trusted none of its fields. I filtered to the 245 postings whose title named a GTM engineering role on an applicant tracking system with a public API, then queried each against the employer's own system: Ashby, Greenhouse, Lever. Workable's 17 would not resolve, so I excluded them rather than count them closed.

Of the 228 I could check, 106 were still open and 122 had been pulled. Filtering on the ATS's current title and dropping duplicates left 82 live postings from 79 companies. Everything below is a tally of those 82 full descriptions.

Named in the posting	Count	Share
Clay	44	54%
SQL	40	49%
Salesforce	39	48%
HubSpot	34	41%
Python	31	38%
Zapier	29	35%
n8n	28	34%
JavaScript or TypeScript	26	32%
Claude Code	15	18%

Clay's count excludes Clay's own four postings. Fifteen of the 82 name no mainstream GTM tool at all.

Three findings changed how I would answer the question. First, 47 of the 82 name a programming language or ask for scripting, version control or a software engineering background. Seventeen ask for no code at all and describe configuring Clay, Zapier, n8n and a CRM. The other 18 wire APIs and webhooks without naming a language. Second, this is not a sales role: by the department field the employer set, 29 sit under marketing or growth, 24 under ops or RevOps, 11 under a standalone GTM team, 6 under engineering, and only 10 under sales. Third, it has escaped sales tech: only 12 postings come from companies that sell software to revenue teams, and the other 70 are buyers, among them a home battery company, a property insurance underwriter and an HVAC software startup.

Who is this for?

You have a go-to-market motion you can describe in steps, you are running those steps by hand, and the constraint is throughput rather than whether the motion works. That is the buyer. If you cannot write the steps down, you have a positioning problem, not a GTM engineering one, and no enrichment waterfall will fix it.

What are the steps?

1. Write the workflow down, with today's volume and today's conversion rate, before you write the job posting. Failure mode: you cannot fill in either number, so you hire someone to invent a motion instead of scaling one, and find that out nine months later.
2. Run that workflow by hand for two weeks. Failure mode: you buy the tool first and then pay a person to make the tool look busy. Clay in particular punishes learning in production, which is why its credit math is worth doing before you sign rather than after.
3. Pick the department the role reports into and put it in the posting. Failure mode: the hire reports to a committee of sales, marketing and ops, and spends the first quarter arbitrating between them. Sales is the least common answer in my sample, at 10 of 82.
4. Decide whether you are buying code or configuration, and interview for exactly that. Failure mode: you write a Zapier job and interview Python candidates. Among postings that publish a range, code roles run a median midpoint of $170,000 against $130,000 for configuration-only roles, a $40,000 gap on a question most job descriptions answer by accident. Only 5 configuration-only postings published a range, so treat that as directional.
5. Give them one system of record before day one. Failure mode: 21 of the 82 postings name both Salesforce and HubSpot, which usually means two CRMs, and the first quarter goes to reconciliation instead of pipeline.
6. Publish the salary band. Failure mode: 43 of the 82 do not, so you negotiate blind against a market whose USD median midpoint is $168,750 and whose published ranges run $85,000 to $260,000.

What goes wrong most often?

The dominant failure is buying the pitch rather than the job. Of the 82 postings, 18 mention SDRs or BDRs, and all 18 describe the GTM engineer building systems that SDRs and AEs then use. Hamming AI's posting draws the line explicitly ("We're hiring a GTM engineer. Not an SDR. Not an AE."), and Rebar's says the hire works alongside the Head of Sales, "not instead of him." Zero postings, under any phrasing I could search for, describe the role as replacing headcount. If you are hiring one to shrink a team, you are the only person in the transaction who believes that, which is where the evidence behind the SDR replacement claim also lands.

The second failure is hiring the role to validate a tool. A GTM engineer will make whatever you point them at run faster, including a motion that does not work, and the tools themselves rarely do what their marketing pages claim.

How do you know it is working?

Measure two things, and neither is volume. First, cycle time: days from "we want to test this play" to "the play is running." Second, conversion at flat or falling send volume. Volume is the easiest thing for a new GTM engineer to deliver and the most expensive thing to be wrong about. Reachium's study of 180,155 matured LinkedIn connection requests found acceptance peaked at 32.0% for accounts averaging 10 to 19 invites a day and fell to 26.7% at 20 to 29. Doubling output can hand you a worse funnel while every dashboard shows more activity.

A baseline from the postings themselves: 47 of 82 employers attached a pipeline number to this role. If yours cannot, you are not ready to measure the hire, which means you are not ready to make it.

What does this not prove?

My sample skews to venture-backed startups: 65 of the 82 sit on Ashby. Bigger, slower companies advertise elsewhere and would pull the median down. Henley Wing Chiu's analysis of about 1,000 GTM engineering postings, published October 2025 and updated January 2026, found a median of $127,500, well under my $168,750 midpoint, and put Outreach at 49% where I found its category at 13%. Some of that is ten months of drift and some is sample composition; I cannot cleanly separate the two.

His study also reaches a conclusion mine cannot refute: nine of the ten most common GTM engineer responsibilities also appear in RevOps postings, so his verdict is that the two jobs are the same. My data agrees: the 24 postings under ops or RevOps read almost identically to the 29 under marketing. What would change my mind is a run of postings where the GTM engineer owns outbound volume directly and reports into sales, the shape the pitch implies. In 82 live postings I found 10 under sales, and none of them said that.