If you were forwarded this newsletter, join 11,435 weekly readers—some of the smartest GTM operators & founders—by subscribing here:
Thanks for reading this hand-rolled, 100% organic (human-written) newsletter.
Presented by:
Clay is the infrastructure GTM engineers build on. Start building for free.
& Supported by:
Attention → AI Agents for RevOps.
Clarify → The Autonomous CRM. Sell more, admin less.
Clearskies → The Context Layer for Revenue AI.
Nooks → Revenue infrastructure for reps and agents.
Rox → Revenue Agent for the Global 2000.
Sumble → High precision GTM data + intelligence.
Terret → The answer-to-action engine for revenue teams.
The lines between “GTM Engineering” and RevOps can be pretty blurry. Some people would even say they’re the same thing.
I completely disagree. But maybe not for the reasons that other people do.
Here’s my main point: There are fundamentally new and critical JTBD that GTM orgs need, but that a current (already overloaded) RevOps function aren’t suited to take on. This is why companies need to specialize and hire someone to do these (new) tasks.
But what are those tasks, and how should RevOps and GTM Eng teams divvy up the work? That’s exactly what I’m mapping out, today.
Let’s get into it.
When I published The Rise of the GTM Engineer back in November 2024, there were only around 200 new job openings for the role. Then, in 2025, the number of GTM Engineers increased 5X. And it has grown another 3X already this year (so far). But, I still get the same question from GTM leaders and founders I talk with: “How is this role different from what my RevOps team does?”
And, it’s a fair question. The title can be confusing. Because it’s nuanced, defined differently for different companies, and quickly evolving! As GTM Engineering becomes more and more popular, understanding how it fits in with RevOps is more and more important. This new function (title semantics aside) is too important to be overlooked because it’s confusing.
I spent all of my time from mid-2024 to early 2026 hands-on consulting (across 14 companies) building go-to-market systems and helping them operationalize AI—from a data, systems and people perspective. With that experience, and talking to dozens of operators this year, here’s how I’ve come to see the distinction between RevOps and GTM Engineering:
System of Record (RevOps) versus System of Action (GTME)
This is not a perfect analogy, but it’s a helpful framework to think about the swimlanes between RevOps and GTMEs.
RevOps: The System of Record.
Jeff Ignacio is one of the most respected voices in RevOps (for good reason). Here’s his mental model for what RevOps is responsible for:
Designing workflows across sales, marketing, and CS, plus
Equipping teams with tools and training, plus
Serving as a strategic partner with data-driven recommendations, plus
Managing the tech stack.
The job is to make sure the business has reliable data, consistent processes, and reporting that leadership can actually trust. In one of my favorite articles on the topic (What RevOps Actually Owns), Jeff said:
Here’s the defining shift: RevOps doesn’t exist to report on performance. RevOps exists to design and operate the revenue system that produces performance.
That system spans how strategy turns into execution, how teams hand off work, how incentives shape behavior, how data flows between tools, and how decisions are made and enforced.
When RevOps is treated as “advanced analytics” or “CRM admin plus,” the function becomes downstream of problems instead of upstream of outcomes.
The RevOps mindset is: How do we create structure and consistency? GTM Engineers, on the other hand, own motion.
GTM Engineers: The System of Action.
Clay coined the term. Their canonical definition is:
GTM Engineers build revenue engines using AI and automation. They combine growth acumen with technical chops to create scaled systems. Instead of coding software, they’re coding revenue.
Sounds… a lot like the RevOps definition, huh? So my perspective is, yes, GTM Engineering can be a subset of the RevOps universe. (I share data on which departments GTMEs report into, further down in this article.) But it’s a very particular part, which is becoming even more important.
Where RevOps asks “is the data clean?” and “is the process being followed?”, GTM Engineers are generally actioning that data. They’re the ones stitching together Clay, enrichment APIs, intent providers, account scoring, putting customer campaigns in motion, automating sales materials, and using the latest AI models to build workflows that span the entire lifecycle of the buyer journey.
For instance, a GTM Engineer might build an end-to-end workflow that automatically emails a prospect. That’s something a RevOps person would never do. But, that workflow relies on the scaffolding RevOps built—things like: account enrichment+tiering, contact-sourcing+persona bucketing, account ownership per rep. So, these JTBD are distinct, but intertwined. Symbiotic even.
Let me also take a second to clarify: GTM Engineering is also not just automating a bunch of top-of-funnel activities. I wrote more about this in my piece: Most Companies Are Using GTM Engineers Wrong. The role is bigger than top-of-funnel. GTM Engineers are (or can be / should be) a leverage multiplier in every department across the entire go-to-market motion.
The GTM Engineering mindset is: How do we drive (quantifiable) outcomes?
(One personal example of this: when I was in RevOps at Zoom video, my OTE was ~5% variable bonus against my goals; which were things like... build a playbook for the team, redo comp plan, integrate this new technology, etc. Whereas when I was a GTM Engineer at Apollo, my variable comp was ~25% because my goal was so quantifiable, more similar to a seller. My goals were to 1) book 1,600 meetings/quarter into net-new accounts without any SDRs and 2) book 400 cross-sell meetings into the existing customer base.)
A Framework for Drawing the Lines
Jeff Ignacio has a useful model for this: map out what RevOps owns vs. influences vs. supports. You could apply the same logic to GTM Engineering. Where the Venn diagrams overlap, you need explicit agreements (ie: swimlanes).
Here’s how Jeff visualizes it in his article Designing a RevOps Org:
RevOps defines what goes into the system of record and how it’s structured. GTM Engineering has the freedom to build whatever it wants outside that system, as long as it respects the rules for what comes back in.
Where They Overlap (and Where They Clash)
This is my current opinion. I am sure (and even expect) that it continues to evolve over time, so reply to this email if you disagree, I’d love to keep learning.
Here’s how I would define the swimlanes between RevOps and GTMEs:
FAQs on getting started with GTM Engineering
If you’ve bought into the concept that “GTM Engineering” work is different than RevOps work (or even a subset or evolution of RevOps work), then the next questions are:
When should you hire a dedicated GTM Engineer?
When should you separate (hire a dedicated) GTM engineer from RevOps?
What department does GTM Engineering report into?