GTM Engineering: What GTM Engineers Build in 2026

GTM engineering is a data-engineering job wearing a sales badge. That is the part the top-ranking explainers underplay, because most of the pages ranking for "gtm engineering" are written by the vendors selling seats for it: Clay, Apollo, ZoomInfo, DealHub. Their definitions are correct, and some, ZoomInfo's included, walk through real workflows. A GTM engineer builds automated revenue systems using data enrichment, workflow automation, and AI. What they mostly skip is the build from the inside: what those systems are made of, where they break, and what they cost when you run them yourself.

This page is the builder's version. It takes the four-system decomposition Clay's own engineer laid out on stage last month, shows one of those systems running from a terminal with the receipts, and covers the thing that changed in September 2026, when the Clay-versus-Claude-Code argument resolved into "both." If you are a builder deciding whether this role is worth learning, or a founder deciding whether to hire one before your first SDR, the answer is in the systems, not the title.

The demand is real and still rising. US searches for "gtm engineering" went from about 1,900 a month in late 2025 to 3,600 by spring and 6,600 in July 2026, per Google Ads data we pulled this week. Job postings grew 205% year over year from 2024 to 2025 per Bloomberry's analysis of about 1,000 listings, cited by ZoomInfo, with roughly 100 new listings a month. Clay, the company that coined the title in 2023, raised $115M at a $7.1B valuation on September 9 and now counts more than 17,000 teams building on it. The role exists. The question is what it is made of.

What is GTM engineering, from the build side?

Everett Berry, who works on this at Clay, opened his AI Engineer talk in August with the cleanest framing we have seen: GTM engineering exists because "GTM teams have kind of realized that it is now possible to ship as fast as a product and engineering team." The best teams he works with push changes to their GTM structure "almost at the same cadence that an engineering team might be doing releases." At Clay that means new data, new automations, and new campaigns every two weeks.

He also called it "one of the first roles that actually is an index on the advances that we're making in AI." As models get more capable, the GTM engineer gets more leverage, because every system below is bottlenecked on reasoning over messy data.

His decomposition is four systems, and every working GTM engineer we read this month is building some subset of them:

1. Data. A virtual copy of your market: accounts, contacts, and the state each one is in.
2. Orchestration. Keeping ten to thirty tools in sync about that state.
3. Agents. Reasoning over an account's context and deciding what to do next.
4. Execution. Getting a message in front of a buyer without burning your domain.

Here is what each one actually involves, with the parts the vendor explainers leave out.

1. The data layer is an entity-resolution problem

The goal, in Berry's words, is "a perfect virtual copy of the market." The problem is that "accounts refuse to hold still." Companies get acquired, open offices, hire and fire, and you are also changing their state by marketing at them and booking meetings with them.

So the data layer is never a list. It is a set of records that need constant, selective refresh. Three techniques do the work:

• Waterfalling. No single provider has complete coverage. Berry's example: one phone-number vendor got "only halfway there" for a set of countries, so you layer providers until coverage is acceptable. Either you or your vendor "needs to run evals against these data providers" to know which is accurate for which field.
• Selective refresh. Buying data is expensive, so you cannot re-enrich every field on every run. Employee count changes constantly; headquarters location almost never. The refresh schedule is per field, not per record.
• Entity resolution. The same account looks different in each provider, so the records have to be matched before anything downstream can trust them. This is the unglamorous part that most "what is a GTM engineer" pages skip and most GTM engineers spend their first month on.

Deepline's September walkthrough adds a corollary worth writing down: "there's no best data provider, only the best order to try them in." Their restaurant-owner example had six standard B2B providers return zero, because restaurant owners are not on LinkedIn, and a chain of public datasets (liquor licenses, secretary-of-state filings, doing-business-as records, PPP data) plus skip tracing reached a 77 to 79% hit rate on a batch of 1,000. That is a vendor's own demo, so treat the exact numbers as theirs, but the pattern transfers to any population your usual providers cannot see.

2. Orchestration is a distributed-systems problem

Most teams run "a CRM, data warehouse, sequencer, a dialer, a note taker for call recording, and some chat interface like Slack," and in practice, Berry says, ten to thirty tools. Each has a different view of the world and different data needs: some want one record in real time, some want hundreds of thousands once a day.

The classic failure he describes: your CRM and your sequencer sync with each other on their own schedule, so when you create a contact in the CRM you have to "wait for that contact to sync to the sequencer before you can then take action on it," which forces waits and polling loops into every workflow. Add fan-out to multiple systems and the failures that come with any distributed setup, and "this turns into a fairly complex data engineering problem."

Clay's answer internally is a graph of general-purpose nodes: nodes that run agents, nodes that make tool calls, conditional nodes, code nodes, and a map-reduce node that fans work out and collects it back. That is the same shape as the agent graphs in our graph engineering guide, which is not a coincidence. GTM orchestration is agent orchestration with a CRM at the end.

3. Agents are long-running and account-scoped

The agent pattern Berry says Clay has landed on: one agent per account, with persistent state, that runs over the weeks or months of a deal cycle. Because it is dormant most of the time, it needs "smart triggers or a heartbeat" to wake it, and when it wakes it ingests the current account context from the data and orchestration layers.

Three GTM-specific constraints make these agents harder than a coding agent:

• Long horizon. Weeks to months, not one session.
• High cost of error. The output is customer communication. A bad send is not a failed test, it is a lost account.
• Unstructured in, structured out. The agent produces reasoning; the CRM wants fields. The mapping is where things go wrong.

His most practical rule: "separating the fields that agents are updating from the fields that deterministic systems are updating or that people are updating." Give agents their own columns. His example agent, a closed-lost reawakening agent, reads Gong, email, the CRM, and the warehouse, is triggered on a timer so you do not re-approach an account the day after you lost it, and writes only to its own fields. He is candid that the continual-learning part, an agent that updates its own view of what works across accounts, "is not fully solved yet."

Clay's Alex Lindahl described the feedback loop they do run: when the messaging system serves a draft to an SDR and the SDR edits it before sending, the diff is captured and fed back to the GTM engineering team to improve the model. That is the software pattern (ship, observe usage, iterate) applied to a sales floor.

4. Execution is where the margin lives

The uncomfortable numbers, as Berry presented them: across roughly 20 million emails in SmartLead's data, cold email replies land "somewhere between a half a percent and 1%." Sequence 100 contacts and about one replies. LinkedIn, in the same comparison, runs "three to four times more effective than cold email," and cold calling sits roughly level with email.

At those rates, every execution mistake is expensive, which raises the bar for anything an agent sends. And the human problems are as hard as the technical ones. Do you send as the rep (everett@clay.com reaching out directly, with the company's domain reputation on the line) or from secondary domains, which then forces you to route replies back to the rep's inbox? If a call books a meeting, the email sequence has to stop and the lifecycle campaign has to unenroll the contact. Multi-channel is a coordination problem before it is a copy problem.

The mechanics matter as much as the message. Spychalski says 60 to 70% of the companies he talks to "just have deliverability problems," and his rules are the ones the sending-tool vendors also publish: never send cold from the primary domain, 15 to 20 emails a day per inbox, at most three inboxes per domain, a 50/50 split of Google and Microsoft mailboxes, set up by hand. Two more rules recur in every serious playbook we read this month and match our own Grok Bot for GTM findings: outreach agents draft, humans send; and the outreach identity is separate from your personal one so a bad sequence cannot burn your sender reputation.

GTM engineer vs RevOps vs sales engineer vs growth engineer

Lindahl's version of the RevOps line: RevOps "is more about placing guardrails" and tends to be reactive, building reports; GTM engineers are "much more proactive," going to sit next to reps, finding the bottleneck, and building. Clay does not even call the function RevOps anymore. It is the "revenue platform team," modeled on a software platform team that builds reusable primitives so the rest of go-to-market can ship faster.

Practitioners police the boundary from the other side too. One of the more upvoted replies in r/gtmengineering this month: "GTM engineering is more for a sales guy who has learned how to code than a dev who has learned how to connect items into a sales pipeline." The consensus reply to newcomers was blunter: GTM "isn't/shouldn't be glorified list building."

The stack, two ways: seats or a terminal

Through 2025 the GTM engineer's stack was a set of seats: Clay for orchestration and enrichment, Apollo or ZoomInfo for data, HubSpot or Salesforce as system of record, Instantly, Smartlead, or Outreach for sending, and n8n, Make, or Zapier for glue. ZoomInfo's July survey of postings has Clay, HubSpot, and Outreach as the three tools employers ask for most.

What changed in the last nine months, in Brendan Short's telling on September 15: "Then, in Dec, most people started using Claude Code. For 6+ months, I watched many of the early Clay power users post about the workflows they built in Claude Code, that replaced Clay." Clay's response this summer was an API, a CLI, an MCP server, and audiences, and he now sees some of those early adopters "start to use Clay again (often within their Claude Code/Codex/Cursor/Grok Bot setups)."

So in 2026 there are two shapes, and many working GTM engineers run a mix.

Michael Saruggia, who says he has trained more than 120 GTM engineers, put the shift in one line on September 5: "You no longer need one expensive platform to run everything. You can operate the entire stack from Claude or Codex." His caveat is the one to keep: "'Build me a cold email campaign' is not a strategy." You still have to know where the right data lives, how to validate it, who to contact, and what message fits the segment. "AI accelerates good GTM thinking. It does not replace it."

The most balanced verdict came from Patrick Spychalski, an ex-Clay employee who now builds these systems for clients from solo founders to the Fortune 5, in an 82-minute walkthrough published September 2. Clay's moats, in his telling: the provider marketplace, concurrency at hundreds of thousands of rows, and compliant, deterministic pushes into the CRM. Claude Code's: the best models, cheap and flexible workflows, and a friend of his running "millions of emails a day" on it. His split is the one we would give a new team: Clay for anything that touches the CRM at volume, Claude for nearly everything else, and either way, "how to run tools like Claude Code is an absolute must."

Deepline's walkthrough makes the technical case for code-first that the MCP crowd tends to miss: an MCP call is right for "a small number of rows or a simple task like I just need a phone number." At scale, "you need code to be the substrate," because the agent has to create files, call tools, iterate, and hand you a script you can re-run next week.

A GTM workflow you can run from a terminal, with the receipts

The most common first system, and the one every playbook this month starts with, is the verified lead list: source accounts that fit an ICP, find the right person, get a work email, verify it is deliverable, and hand a clean CSV to the sequencer. Here is the code-first version, using the numbers from a run our team published on August 26.

Setup. One coding agent, one data registry. We use treg, which our team built for exactly this after getting tired of holding six vendor API keys; it is source-available and self-hostable if you would rather run it on your own keys. Any per-call registry with a catalog the agent can search works the same way. On a fresh machine it is three commands and a restart:

curl -fsSL https://treg.to/install.sh | sh   # the CLI
treg login                                   # GitHub sign-in (or --email for a one-time code)
treg mcp install                             # registers the tools with Claude Code
# restart Claude Code; until then the same calls work through the CLI

The prompt was a paragraph, not a pipeline: build a lead list of 50 US software companies with 51 to 200 staff that raised a Series A, find the marketing lead at each, verify a work email, pull the three most recent news events for an opener, and return a CSV sorted with deliverable results first.

What the agent did, step by step, with the per-step catalog price it read before calling:

The receipt: 50 companies requested (746 matched the filter, first page taken), 47 with usable domains, 40 contacts found, 31 emails found, 27 verified deliverable. Data spend $3.62, or $0.13 per deliverable lead. That is the enrichment bill only; the coding agent, the CRM, and whatever sequencer you load the list into bill as they always did. The 4 addresses that failed verification stayed in the CSV with their verdict marked and sorted to the bottom, so nobody sends to them by accident. The receipt also discloses its own rough edge: two providers were settled at list rate on misses, $0.56 of the total, because they do not report the charge in their response, a treg-side fix in progress.

Three things about that run are the actual lesson:

1. The agent priced the job before running it. The catalog search returns the price per call, so the plan is costed before a cent is spent. Deepline's demo does the same thing and pauses for approval at the estimate.
2. The waterfall was chosen per step, not designed up front. The agent picked a primary provider and a fallback for each capability based on measured success rates, which is the "no best provider, only the best order" rule made automatic.
3. The run documents itself. The receipt is the ordered list of calls, providers, and prices, and the natural next step is to ask the agent to save those steps as a script, so the next run is one command with a different ICP. Check that into a repo and it is a play; schedule it and it is a system, which is the whole point of the Loop Engineering build order.

One user of this setup, posting on September 3, described the same shape end to end: ICP defined in plain English with a link to their sales page, companies sourced, contacts found, emails verified across five services, the list loaded into Instantly with dynamic variables and an A/B split. Self-reported, one person, but it matches the run above.

For comparison, the seat version of the same list is a Clay table with one column per step and a credit meter, which is more visual and easier to hand to a non-builder, and which many teams still prefer for exactly that reason. The point is not that one replaces the other. It is that the data behind the list is now a one-paragraph prompt plus about four dollars, and that changes what you can afford to test.

The plays worth building after the list

The list is table stakes. These are the plays working GTM engineers described building this month, in rough order of value.

Signal-triggered outbound. Namanyay Goel, who runs GTM for a set of YC companies, says the highest-leverage change is to "kill static lists": search Greenhouse, Lever, or LinkedIn Jobs for companies that posted an opening for your target pain point in the last 72 hours, because a team that is budgeting and interviewing for the problem replies at a multiple of a cold list. His seven-day numbers are self-reported and from a vendor, but the shape is right, and it is the same job-posting monitor Cody Schneider described building the same week: an agent watching LinkedIn and Indeed daily for a title, an ICP filter, org mapping to the decision maker, waterfall enrichment, and Instantly at the end. Spychalski calls job listings "the most underrated signal on the market" and says to read the text of the posting, not the boolean. Keep company fit and buying signal as separate scores: a static firmographic score (below about 40, skip; 90 and up is tier one) and a dynamic signal score that fires the notification. Calibrate both against ten to twenty accounts you know are a perfect fit and ten to twenty you know are not before you trust them on the grey middle. A company can match your ICP perfectly and have no reason to buy today.

Inbound speed-to-lead. Lindahl's team ran an experiment that doubles as a lesson: agents filled out more than 6,000 companies' demo forms with an email and phone number attached to another agent, and measured the response. About a third of companies ever replied, and of those, the share that replied inside five minutes with something personalized and qualified was "pretty low." If you sell to anyone with a web form, the play is routing plus a research agent plus a five-minute SLA, and it is one of the least crowded plays because most teams never measure it.

Win/loss signal scoring. Feed 100 closed-won and 100 closed-lost accounts to an agent with website scraping and enrichment, and ask what differs. Deepline's demo for a security customer found accounts mentioning FDIC on their site were 1.6x more likely to win, accounts with "customer identification program" in their terms 3x, and accounts advertising SOC 2 Type II an eighth as likely. Their numbers, their customer, but the method is the point: negatives are what make a score predictive, and in Deepline's experience almost nobody includes them.

Account memory outside the CRM. Lieben's second skill is a "usable memory of what already sells": CRM history, call transcripts, and past outreach results matched to the same account, with the buyer's actual words kept next to your notes. A thread in r/gtmengineering this week described moving account history out of Salesforce for exactly this reason, because required fields fill up with "good call" and "follow up." Whatever you use, the GTM engineer's job is the join between systems, not the note-taking.

Content engineering. Fivos Aresti's sixth workflow: sales calls captured, objections surfaced, content ideas generated, marketing notified. Clay runs a version of this on its own executives, and Lindahl said a single executive post has driven a thousand people to a webinar. That is the same "marketing as a media team" motion we cover in the growth marketing skills guide, run by the GTM engineering team instead of a content team.

The rule for choosing among these came from Lindahl, answering a new GTM engineer whose company had low adoption and no roadmap: "find a metric that leadership cares about," find the system behind it, interview people about the bottleneck, and "build this one thing that's going to remove that bottleneck." Then repeat. Plays have a half-life. Clay reviews theirs every three to six months and retires the ones the data says have stopped working.

Skills, salary, and how people are getting in

What the job pays. ZoomInfo's July 2026 compilation: entry roles from about $85,000 (DevCommX US range), a mid-level average of $127,500 (Bloomberry, about 1,000 postings), and senior roles up to $241,000 (Apollo and DevCommX), with early-stage companies adding equity. Lieben's post cites offers up to $230,000 and explains the math from the employer's side: a good GTM engineer "can take on the prospecting work of 5+ people."

What the postings ask for. ZoomInfo's read of the same data: advanced CRM configuration, API integration fluency, and functional SQL and Python. Not software-engineering depth. The strategic half is commercial thinking and the ability to turn a business problem into a workflow and measure it.

How people are actually getting hired. The r/gtmengineering thread on breaking in with no experience is the most honest source we found. One reply: "become your own first client," launch the simplest business you can, and do its GTM engineering yourself. Another, from someone hiring: "we're hiring juniors right now because once the business got the hang of what our team can do the ideas are literally flooding in," with the only requirement being "that you're curious and super smart with AI." A third, on portfolios: automated lead enrichment workflows, interest-based outbound triggers, and agent-driven lead routing in a CRM are what a hiring manager wants to see. Anthropic's own example is an account executive with 600 to 700 accounts who built a Claude-powered inbox-drafting tool, saved two to three hours a day, and moved into a go-to-market architect role.

Hire from either side. Lindahl's rule for Clay's internal team: you can come from engineering or from the business, but "the engineer needs to have the slope to understand the go-to-market and business side very quickly and vice versa." He has no computer science background and builds MVPs on customer sites during roadmap meetings. The business person will never be as technical as the engineer "but that person can probably still have an outsized impact."

What goes wrong

• Alert fatigue kills good signals. Lindahl's team once piped every signal, brief, and pre-meeting note into Slack until reps stopped reading any of it. Route by priority or route to nobody.
• Fake enrichment is worse than a gap. Every playbook we read this month agrees: unknown is a valid value. An agent that guesses a title or an email costs you a send, a reply rate, and eventually a domain.
• Old signals re-trigger. Lieben's rule: keep the date checked next to every finding, so a hiring post from March does not start a campaign in September.
• Agents writing to shared CRM fields. Give agents their own columns. If an agent and a rep both own "next step," neither does.
• Tool knowledge as your only moat. Deepline's founder said it plainly: expertise about which data providers are good "is quickly collapsing" as a differentiator. What remains is the engineering: systems that are testable, that iterate on their own results, and that do not make serious changes "without going through the entire funnel and knowing that it's not going to break anything."
• Agents writing the whole email. Spychalski's rule from hundreds of client systems: hire a copywriter, template the message, and let the agent fill the variables, with about half the copy static. "Every syllable, every line break, every dash matters," and a model writing 1,000 unique emails gets none of them right.
• Volume as the goal. The teams getting the most out of these systems are sending fewer emails, not more, per the same talk. Better targeting, more pipeline from email as a channel, fewer total sends.

The shape underneath

Strip the vendor names and GTM engineering is the same architecture as every working agent system: a data layer you can trust, narrow agents with their own state and their own fields, a human at every send, and a loop that observes results and feeds them back. The GTM engineer is the person who builds that for a revenue team and is measured on what it produces. Spychalski's forecast for where the role ends up is the one we would bet on: GTM engineers "will be orchestrators of agents and visionaries for systems," and everything else gets built, tested, and run by the agents.

If you want the systems half of the job, the Agent Skills 101 course covers how a workflow like the lead list above becomes a reusable skill, and Loop Engineering covers how that skill becomes a system that runs on a schedule behind a quality gate. The sales-specific skills, sixty of them with install commands, are in the Claude Code sales skills guide.

Related Content

• Claude Code Sales Skills - 60+ agent skills for outreach, CRM automation, and pipeline work, with install commands.
• Claude Code for Growth Marketing - The marketing-side skills and the shared-context pattern that makes them useful.
• Grok Bot for GTM - An insider's ten-Bot GTM roster and the outreach rules that keep it safe.
• Graph Engineering Guide - The orchestration pattern Clay's node graph maps onto.
• How to Build an AI Team - Roster size, build order, and when to add a coordinator.

Join AI Builder Club