Here's what seems to be true:

• More than half of companies are either already hiring or planning to hire a GTM Engineer, according to Scale Venture Partners and job listings for the role have roughly doubled over the past year. That said, it’s still early days, and not every company has jumped on board yet.
• Most GTM Engineers currently have less than 5 years of professional experience. (I actually ran a quick analysis using a table in Clay pulling LinkedIn profiles and calculating average years in the workforce.)
• The term “GTM Engineer” was coined by Clay, and much of the early skillset is tied to building Clay workflows.
  ‍

So yes, the role is real. But the more interesting questions are: Why is it emerging now and where does the role actually belong in the org chart? 

Our view: GTM Engineers should live in RevOps.

Why the GTM Engineer Exists

AI, AI, AI. Of course. But honestly, the rise of the GTM Engineer has just as much to do with how revenue teams have been operating over the last decade.

1. Teams are tired of buying point solutions

For years, the answer to every GTM problem was to buy another tool. Need enrichment? Buy a tool. Need routing? Buy a tool. Need sequencing? Buy a tool. Eventually companies woke up and realized they had built incredibly expensive, fragile stacks.
‍

At the same time, budgets and headcount are under much heavier scrutiny. The result is more DIY inside GTM teams. Instead of buying another product, teams are asking: “Can we just build this ourselves?” That’s where the GTM Engineer comes in.

2. Data is easier to access

Data used to be extremely expensive and difficult to work with. But now you can easily pull company information, identify buying signals, and micro-segment prospects. You no longer need a full engineering team to do serious research on accounts. But you do need someone technical enough to stitch it all together.

3. Top-of-funnel performance is getting worse

This one is uncomfy but true. Across B2B companies, many teams are seeing declining response rates, lower inbound volume, and saturated outbound channels. That means the old playbooks aren’t working as well. Companies need innovation in outbound and prospecting to hit their numbers, and that innovation is increasingly technical.

4. It’s easier than ever to build

APIs are everywhere, automation platforms are accessible, and AI coding tools have made it easier for operators to build things themselves. “Vibe coding” might be a meme, but it reflects a real shift: operators are getting more comfortable building internal tools. GTM Engineers are essentially the natural extension of that trend.

What a GTM Engineer Actually Does

If you read enough GTM Engineer job descriptions, they tend to emphasize the same traits. They’re looking for someone who is:

• Technical: Comfortable working with APIs, automation, and data workflows.
• A builder: Someone who would rather automate something once than repeat it manually forever.
• Experimentation-driven: Constantly testing messaging, segmentation, and outbound approaches.
• A technologist: Curious about new tools and systems.

Part of the reason this role feels so different is that RevOps over the past decade has focused heavily on buying technology. We became very good at vendor selection, implementation, and system administration, but we didn’t spend as much time building systems ourselves.

That’s changing now. And the GTM Engineer is a reflection of that shift.

Why GTM Engineers Belong in RevOps

Note: I’m specifically centering this around mid-market and enterprise companies. That’s who we work with at Go Nimbly and where my expertise lies. For companies with fewer than ~200 employees or very simple GTM motions, some of this may look different.

But at scale, I have a strong opinion: A true GTM Engineer should live under RevOps.

Here’s why:

RevOps works across silos

RevOps teams sit across the entire revenue lifecycle. They understand the full funnel, not just top-of-funnel. GTM Engineers have developed a reputation for focusing on outbound. But that’s not really the point of the role. The real opportunity is modernizing and streamlining revenue systems across the entire funnel. That’s exactly what RevOps is responsible for.

RevOps adds the right level of governance

GTM Engineers love to build things and experimentation is good. But large companies also have very low tolerance for operational mistakes. You don’t want a campaign going out with bad data, private data accidentally exposed, or workflows breaking core CRM systems. RevOps provides the structure and oversight that allows experimentation without compromising system integrity.

RevOps should own AI innovation in GTM

The future of revenue operations is more technical than the past. RevOps leaders will become more and more responsible for automation strategies, AI deployment, GTM data architecture, and experimentation infrastructure. If GTM Engineers are driving that work, it makes sense for them to sit inside the team already responsible for revenue systems.

But Some Teams Put GTM Engineers Elsewhere

I recently surveyed my network on LinkedIn to understand where GTM Engineers are rolling up to in org charts. The most common answer? RevOps or Sales Ops, which, frankly, is encouraging. It suggests that companies recognize that revenue infrastructure still needs centralized ownership. Still, there are a couple alternative models.

GTM Engineers inside sales teams

There is a real argument that GTM Engineers should sit directly within GTM teams, particularly SDR organizations. The logic goes like this: if GTM Engineers sit close to the sellers, they can move faster and better understand the sales process.

There’s some truth there. There is a type of GTM Engineer that focuses almost entirely on outbound: sequence design, subject line experimentation, and list building. If the scope is that narrow, placing them in sales can work. Just like campaign operations sometimes sits within marketing.

But the moment we start talking about broader systems, data pipelines, and revenue architecture, the argument starts to fall apart. Revenue infrastructure shouldn’t be fragmented across teams.

GTM Engineers under systems teams

At very large companies, GTM Engineers sometimes sit under systems or platform teams. Frankly, I’m not hearing this one as much.

The main problem GTM Engineers are trying to solve is speed, while systems teams typically optimize for stability and governance. That can naturally slow experimentation. That said, the tension between systems stability and GTM innovation is probably healthy.

The Bigger Shift Happening in RevOps

The GTM Engineer isn’t just a new job title. It’s a signal that revenue operations itself is shifting. The next generation of RevOps teams will be more technical, more experimental, and more focused on building internal systems. Not just managing software. And that’s a good thing.

‍