I get the question "should I hire RevOps or GTM Engineering?" almost weekly from founders. The answer is almost always: both. And in this article I show why — and how to have these two disciplines work together under one roof. Spoiler: in our practice we do both.
Over the past two years there's been unfortunately too much written pitting GTM Engineering against RevOps. "RevOps is dead, long live GTM Engineering." "GTM Engineers are only relevant for enterprise." Nonsense. The truth is more nuanced and pragmatic: they're two complementary disciplines serving different parts of the revenue machine. Those who use both well, win. Those who choose, miss half.
This is part 6 in the series. For background read What is GTM Engineering? and RevOps: Why marketing, sales, and service should be one team.
Definitions first
Before discussing the collaboration, the dividing line must be clear. Apollo, Factors.ai, and Tabula have all articulated this well. My synthesis:
RevOps is the discipline ensuring governance, predictability, and alignment across marketing, sales, and customer success. RevOps owns funnel definitions, KPI hierarchy, SLAs between teams, forecast, comp plans, territory logic, and the single source of truth in the CRM. It's, in essence, the governing body of your revenue machine.
GTM Engineering is the discipline building new systems: enrichment pipelines, signal detection, AI agents, custom CRM extensions, automations that multiply revenue-team productivity. It's, in essence, the product team of your revenue machine.
RevOps maintains. GTM Engineering builds. RevOps works with rules and definitions. GTM Engineering works with code and flows. Both are essential. Neither works without the other.
The Build vs Run model
The cleanest way to conceptualize the collaboration is "Build vs Run," a model that emerged among GTM leaders in 2025-2026. Apollo describes the concept: the most successful organizations implement a clear operating model where GTM Engineering is responsible for architecting new systems, running experiments, and prototyping, while RevOps governs, maintains, and optimizes.
Concretely:
- GTM Engineering (Build): designs and builds new systems, runs experiments, prototypes workflows, integrates tools, writes custom code and API integrations.
- RevOps (Run): maintains existing systems, manages data formats, runs release processes, monitors SLAs, runs forecasts, and governs KPI definitions.
The analogy I often use: if your revenue machine were a software product, RevOps is your site reliability engineering team, and GTM Engineering is your product engineering team. One keeps existing infrastructure running. The other builds new features extending existing infrastructure.
Five ways they reinforce each other
How does this collaboration look in practice? Five concrete examples.
1. Lead scoring: RevOps defines, GTM Engineering builds
RevOps defines what constitutes a qualified lead - which firmographics, fit criteria, behavioral signals. That's not a technical decision; it's a go-to-market decision sales and marketing leaders must agree on.
GTM Engineering then builds the system operationalizing that definition: integration with enrichment providers, a real-time scoring model, automatic routing based on score, sync to sales engagement tools. The definition is RevOps. The build is GTM Engineering. The handoff is a specification both parties understand.
2. Forecasting: RevOps drives, GTM Engineering augments
RevOps runs the weekly forecast: pipeline coverage, weighted forecast per stage, win-rate trends. That stays RevOps's work. But GTM Engineering builds tooling that makes forecasting more accurate: ML models predicting win probability per deal, dashboards integrating signals from product usage and email engagement, AI agents automatically reclassifying deals on specific signals.
RevOps remains the forecast owner. GTM Engineering delivers tools that make RevOps smarter.
3. CRM architecture: joint ownership
This is where the dividing line is hardest. Who owns the CRM? My experience: the object model and lifecycle definitions are RevOps. Technical implementation, custom objects, complex automations, and third-party integrations are GTM Engineering. The line runs through "what's the definition" (RevOps) versus "how is it executed" (GTM Engineering).
In a healthy organization, RevOps is in the CRM architecture planning, and GTM Engineering does the actual configuration. Both review changes before they go live.
4. Outbound: GTM Engineering builds, RevOps measures
A new signal-based outbound flow? GTM Engineering designs it: which signals, which data sources, which triggers, which templates, which routing. Then RevOps measures it: bounce rates, reply rates, qualified conversations, pipeline generated, win rate of pipeline from this channel versus others.
One role builds the instrument. The other measures if it works. Together they decide what to scale, stop, and iterate.
5. Tooling decisions: joint evaluation
Buying a new tool? This intersection matters. RevOps sets criteria: does it fit our data architecture, meet our SLAs, integrate with our single source of truth? GTM Engineering evaluates technically: API quality, automation possibilities, total maintenance burden, whether it supports new build projects.
The decision is made together. If either role vetoes, the process restarts. That sounds slow, but it prevents the "shiny tool" syndrome plaguing many B2B companies.
Three organizational models that work
How do you organize this practically? In my practice I see three models, each suited to a different company stage.
Model 1: One person, two hats (early-stage, <$3M ARR)
In seed/Series A you have one person doing both. A "Head of GTM Operations" or similar title who defines (RevOps) and builds (GTM Engineering). Prerequisite: this person must combine both skills, which is a rare profile.
In this phase we often support the work ourselves as interim GTM lead — because the profile is expensive and hard to find internally. Interim builds the foundation; a junior takes over afterward.
Model 2: Two separate roles, one manager (scale-up, $3M-$15M ARR)
Between $3M and $15M ARR you typically split the roles organically. One RevOps person (defines, governs, measures) and one GTM Engineer (builds, automates, integrates). Both report to a Head of RevOps or VP Operations.
Weekly sync is critical in this model. Weekly check on what's being built and what's being measured. Quarterly planning on which build projects get priority. Without that cadence the classic pitfall emerges: GTM Engineering builds things misaligned with what RevOps needs.
Model 3: Two teams (enterprise/late-stage, $15M+ ARR)
Above $15M ARR you split into two sub-teams. The RevOps team (often 3-6 people, led by a Head of RevOps) and the GTM Engineering team (often 2-5 people, led by a Lead GTM Engineer). Both report to a CRO or VP RevOps.
Here the risk emerges that both teams pursue their own agendas. The fix: joint OKRs. Both teams are evaluated on the same top-level revenue metrics, not on separate team metrics. That forces collaboration.
The three most common pitfalls
What goes wrong when this collaboration fails? Three patterns I regularly see.
Pitfall 1: The "build cowboy." GTM Engineering builds without RevOps input. Result: technically impressive systems disconnected from the organization's definitions, processes, and KPIs. Sales doesn't use it. Marketing doesn't understand it. The build gets dismantled six months later.
Fix: every build project starts with a RevOps brief defining what needs building and why. GTM Engineering determines how.
Pitfall 2: The "RevOps blockade." RevOps wants to approve everything in advance, bureaucratizes the build process, makes experimentation impossible. Result: GTM Engineering stops taking initiative, innovation stalls.
Fix: agree upfront which decisions need RevOps approval (production systems, customer-facing automations) and which are free experiments (internal tooling, prototypes, sandbox environments).
Pitfall 3: The dual tool stack. Both roles have their own tools and data sources that don't sync. RevOps works from Salesforce reporting, GTM Engineering from a separate data warehouse. Both are right about different numbers.
Fix: one single source of truth, captured in a data dictionary both teams maintain. When numbers don't match, the problem gets solved, not waved away with "yes, that's why we look at our version."
Why "we do both" works in our practice
In my work — and that of Pack of Nodes — we explicitly combine both disciplines. Not because it's trendy, but because most Dutch scale-ups need an interim partner who can serve the whole playing field.
Concretely: for a scale-up of €5M ARR with 8 sales/marketing people and no RevOps or GTM Engineer on staff, we can in 3-6 months:
- Lay the RevOps foundation: lifecycle definitions, KPI hierarchy, SLAs, forecast process, comp plans;
- Build the GTM Engineering layer: enrichment flows, signal detection, AI agents, custom integrations;
- Train the team to take over: documentation, onboarding, knowledge transfer to a first internal hire.
This hybrid model works because an external partner in early-scale-up phase often delivers more value than two full-time hires — if the partner masters both disciplines. A pure-RevOps consultant can't build the tech. A pure-GTM-Engineer can't lay the governance. Whoever can do both delivers a complete foundation in one engagement.
The "which first?" question answered
Back to the original question: if you must choose, RevOps or GTM Engineering first?
For most B2B SaaS companies the answer is: RevOps first, GTM Engineering shortly after. Reason: you need definitions and KPIs before you can build systems that measure them. Without a RevOps foundation, GTM Engineering builds blindly. With a RevOps foundation, GTM Engineering builds purposefully.
But the gap in practice is often only a few months. And if you can hire an interim or external partner mastering both disciplines, you do them in parallel. That's the fastest route to a mature revenue machine.
In the next post I cover how GTM Engineering changes in the AI era, and how the collaboration with RevOps changes specifically.