By now, everyone in RevOps circles knows about the GTM Engineer. Some companies are paying $200–250K for one right now, while others think the role's days are numbered. Regardless, LinkedIn posts about it are racking up thousands of impressions.
The GTM Engineer wave isn't just a hiring trend. It's a snapshot of how quickly AI is reshaping go-to-market strategy and where things are really heading. Here's what's actually happening, stripped of the hype.
This role belongs to RevOps, so go claim it
Let's start with the most important thing.
GTM Engineering — the discipline of connecting tools, data, and workflows so the revenue motion runs without constant human intervention — is being positioned as a standalone function inside high-growth companies. Some organizations are letting Sales Ops or Marketing Ops claim it. Some are spinning up entirely new teams.
RevOps should own this.
RevOps already controls the systems, the data, and the process design. GTM Engineering is a natural extension of that ownership into the architecture layer, and into AI. If you're building your 2026 roadmap and this isn't on it, someone else will build the function without you.
Scale Venture Partners surveyed 300 GTM leaders on AI adoption and found that when RevOps was involved in AI initiatives, those initiatives had a 20% higher impact. RevOps isn't just a stakeholder in GTM Engineering — it's the function that makes it work.
Clay is table stakes now
A year ago, Clay fluency was a differentiator. Today, it's a baseline requirement.
Every GTM Engineer job posting we've looked at lists Clay as a must-have, and not at a beginner level. Multi-step enrichment waterfalls. Claygent workflows. Custom API integrations. Advanced filtering logic. One job description calls it flatly "non-negotiable," adding: "If you've coached others on Clay or competed in the Clay Cup, we want to hear from you."
Clay has also gotten dramatically more accessible. Operators who couldn't have touched it two years ago are now building functional pipelines without engineering help. As Hayes Davis wrote in Uncharted Territory: Clay's "stroke of genius was to unbundle the whole thing and then empower people to piece it back together again" — and in doing so, they essentially invented the GTM Engineer role. Now they're trying to re-bundle, which means the specialist skills that defined the role are becoming table stakes across the market.
What this means for RevOps teams: Stop treating Clay as advanced tooling. Build fluency across the team. The question isn't whether to use it anymore; it's whether your team is using it well enough to generate real pipeline signal rather than just impressive-looking workflows.
AI is now a layer in your stack, not just a tool you log into
The way companies are using AI in GTM has shifted materially. The expectation is no longer "use ChatGPT to help write emails." It's building Claude, OpenAI, or other LLM APIs directly into GTM systems as a functional layer.
One company describes it clearly in their GTM Engineer posting: they want someone who can "build custom internal tools powered by Claude (Anthropic API), using HubSpot as the core data layer and leveraging Claude Code." Another explicitly says: "You're comfortable building with Claude and other leading models — not just prompting them, but wiring them into real workflows."
This is a meaningful distinction. Prompting an AI is a feature. Wiring it into your enrichment logic, your qualification workflows, your post-call follow-up automation — that's infrastructure.
The implication: RevOps teams need to develop literacy not just with AI tools, but with AI APIs. You don't need to become an engineer. But you need to understand how these integrations work and be able to direct the people building them.
Your CRM is the frontend now, not the brain
This one has big architectural implications.
Multiple sources, including job postings and thought leaders, as well as the agents they use to write posts about AI, are converging on the same point: the CRM is increasingly the display layer, not the intelligence layer. The logic that used to live inside Salesforce or HubSpot workflows is migrating upstream.
Hayes Davis argued this directly in his Composable GTM Ecosystem series: the era of CRM-centrism is waning as AI removes "the final thing holding CRM-centrism together: the requirement to always have a human in the loop." The locus of competition is shifting from closed platforms to distributed, interoperable components — with the CRM increasingly serving as one output surface among several, not the center of everything.
Enrichment, lead scoring, qualification logic, intent signals, routing rules: these belong in a data layer (and increasingly in AI agents), not in CRM workflows. CRM records and surfaces the result of that logic. It doesn't generate it.
This has real consequences for how RevOps teams think about investment. If you're spending the majority of your architecture time inside Salesforce or HubSpot, you may be optimizing the wrong layer. The leverage is in what feeds the CRM, not in the CRM itself.
The GTM engineer role is already splitting into two
Here's the nuanced take that most of the hype misses.
Dave Breshears, a GTM strategist with a sharp read on the market, argues that the original GTM Engineer — the person whose core value was technical fluency with Clay, enrichment waterfalls, and webhooks — is being rapidly commoditized. As the tools become more accessible, the assembly work gets absorbed into the platforms. The "Clay wizard" whose entire value was making the tools do tricks is becoming less valuable, not more.
Hayes Davis makes a similar point from a different angle: GTM Engineer titles are "a symptom of things being too damn complicated right now." As the technology matures and becomes more accessible, the specialist role fades — not because the underlying work disappears, but because it gets absorbed into what everyone on the revenue team is expected to do.
What survives is two distinct profiles:
1. The RevOps systems builder. This person handles genuinely complex infrastructure: CRM architecture, attribution modeling, data hygiene, deliverability engineering, multi-system orchestration. This is close to traditional ops engineering, and the complexity isn't getting abstracted away anytime soon. This is squarely in RevOps territory.
2. The operator-engineer hybrid. This is the rare, increasingly valuable person who has both technical ability and deep understanding of the buyer, the message, and the funnel. They can iterate end-to-end without translation loss between strategy and execution. They don't just build the pipeline — they know what should flow through it.
What's dying is the person in the middle: technically capable but commercially disconnected. Breshears puts it bluntly: "A pure technical GTM Engineer — someone who builds the pipes but doesn't understand the revenue motion — is increasingly redundant."
For RevOps leaders: The second profile (operator-engineer hybrid) is who you want to develop internally or hire for. Technical skill is increasingly table stakes. Commercial judgment — understanding why a signal matters, why a message will resonate, why a workflow will actually generate pipeline — is the differentiator.
Outbound automation is everywhere and that's the problem
There's a hard truth buried in all of this.
Reply rates across the outbound industry have been declining. Not because the tools got worse — because the tools got too good, and everyone is using them the same way. Inboxes are flooded with AI-personalized emails that mention a prospect's recent funding round but say nothing meaningful about why it should matter to them. Signal-based triggers fire on signals that don't actually predict buying intent. Beautiful automation delivering generic messages at scale.
As Breshears writes: "A lot of GTM Engineering output over the last two years has been technically impressive and commercially mediocre."
The constraint has shifted. The bottleneck is no longer technical — it's message quality, segmentation logic, signal relevance, and offer fit. None of which the engineering skill set, on its own, addresses.
This is a significant reframe for RevOps. The value of investing in GTM automation infrastructure is real. But it only pays off if the strategy behind it — the what-to-say and who-to-say-it-to — is actually differentiated. Automation amplifies your GTM logic. It doesn't replace the need to have good GTM logic.
The full funnel is now fair game
One final shift worth naming: the scope of GTM automation has expanded well past outbound.
The GTM Engineer job descriptions we reviewed consistently describe automation across the entire revenue lifecycle: lead capture, qualification, handoffs, onboarding, expansion, and renewal. This isn't just a Sales Development function. JobNimbus explicitly wants their GTM Engineer to eliminate manual work across Sales, Marketing, Implementation and Support in a unified system.
This is both an opportunity and a responsibility for RevOps. The function that owns this end-to-end view is RevOps. But that also means RevOps needs to be actively building automation that serves Customer Success and post-sale teams, not just the top of funnel.
What to do with all of this
If you're a RevOps leader, here's the practical read:
-
Claim GTM Engineering as a RevOps function. Name it, scope it, and put it on your roadmap. Don't let it get captured by another team.
-
Build Clay fluency now. It's not a nice-to-have. If your team can't work at Clay power-user level, you're operating behind the baseline.
-
Invest in your data layer, not just your CRM. Where your enrichment logic, scoring models, and signal architecture live is increasingly where GTM leverage lives.
-
Develop the operator-engineer hybrid. The people who combine commercial judgment with technical ability are rare and increasingly valuable. Grow them deliberately.
-
Pair automation with strategy. More automation without better signal relevance and message quality just means more efficient noise. The infrastructure is only as good as the thinking behind it.
The GTM Engineering moment is real, and it's moving fast. RevOps teams that build this capability in 2026 will have a compounding advantage. The ones that watch from the sidelines will find the function and the leverage that comes with it owned by someone else.
Have thoughts on how your team is approaching GTM Engineering? We'd love to hear what's working and what isn't.
