De vraag «moet ik RevOps of GTM Engineering aannemen?» krijg ik bijna wékelijks van founders. Het antwoord is bijna altijd: allebei. En in dit artikel laat ik zien waarom, en hoe je die twee disciplines onder één dak kunt laten samenwerken. Spoiler: in onze praktijk doen we beide.
De afgelopen twee jaar zijn er ongelukkig veel blogs geschreven die GTM Engineering en RevOps tegen elkaar uitspelen. «RevOps is dood, lang leve GTM Engineering.» «GTM Engineers zijn alleen relevant voor enterprise.» Allemaal onzin. De waarheid is genuanceerder en pragmatischer: het zijn twee complementaire disciplines die elk een ander deel van de revenue-machine bedienen. Wie beide goed inzet, wint. Wie kiest, mist de helft.
Dit is deel 6 in een serie over GTM Engineering. Voor de basis lees Wat is GTM Engineering? en mijn artikel RevOps: waarom marketing, sales en service één team moeten zijn.
Eerst de definities scherp
Voordat we de samenwerking bespreken, moet de scheidslijn helder zijn. Apollo, Factors.ai en Tabula hebben dit alle drie goed verwoord. Mijn synthese:
RevOps is de discipline die zorgt voor governance, voorspelbaarheid en alignment over marketing, sales en customer success heen. RevOps bezit de funnel-definities, de KPI-hiërarchie, de SLA's tussen teams, de forecast, de comp plans, de territory logic en de single source of truth in het CRM. Het is, in essentie, het bestuursorgaan van je omzetmachine.
GTM Engineering is de discipline die nieuwe systemen bouwt: enrichment pipelines, signal-detectie, AI-agents, custom CRM-extensies, automatiseringen die de productiviteit van revenue teams vermenigvuldigen. Het is, in essentie, het productteam van je omzetmachine.
RevOps onderhoudt. GTM Engineering bouwt. RevOps werkt met regels en definiëringen. GTM Engineering werkt met code en flows. Beide zijn essentieel. Geen van beide kan zonder de ander.
Het Build vs Run model
De cleanste manier om de samenwerking te conceptualiseren is «Build vs Run», een model dat in 2025-2026 opkwam onder GTM-leiders. Apollo beschrijft het concept als de meest succesvolle organisaties die een duidelijk operating model implementeren waarbij GTM Engineering verantwoordelijk is voor het architecten van nieuwe systemen, experimenten draaien en prototyping, terwijl RevOps governanceert, onderhoudt en optimaliseert.
Concreet:
- GTM Engineering (Build): ontwerpt en bouwt nieuwe systemen, runt experimenten, prototypeert workflows, integreert tools, schrijft custom code en API-integraties.
- RevOps (Run): onderhoudt bestaande systemen, beheert dataformaten, voert release-processen uit, bewaakt SLA's, draait forecasts en governanceert KPI-definiëringen.
De analogie die ik vaak gebruik: als je revenue-machine een softwareproduct was, dan is RevOps je site reliability engineering team, en GTM Engineering je product engineering team. Het ene zorgt dat de bestaande infrastructuur draait. Het andere bouwt nieuwe features die de bestaande infrastructuur uitbreiden.
Vijf manieren waarop ze elkaar versterken
Hoe ziet die samenwerking er in de praktijk uit? Vijf concrete voorbeelden.
1. Lead-scoring: RevOps definieert, GTM Engineering bouwt
RevOps definieert wat een gekwalificeerde lead is: welke firmographics, welke fit-criteria, welke gedragssignalen. Dat is geen technische beslissing, dat is een go-to-market beslissing waar sales- en marketing-leiders het eens over moeten zijn.
GTM Engineering bouwt vervolgens het systeem dat die definitie operationaliseert: integratie met enrichment-providers, een scoring-model dat real-time draait, automatische routing op basis van score, sync met sales engagement tools. De definitie is RevOps. De bouw is GTM Engineering. De handoff is een specificatie die beide partijen begrijpen.
2. Forecasting: RevOps voert, GTM Engineering versterkt
RevOps draait wekelijks de forecast: pipeline coverage, weighted forecast per stage, win rate trends. Dat blijft het werk van RevOps. Maar GTM Engineering bouwt de tooling die forecasting nauwkeuriger maakt: machine learning modellen die de waarschijnlijkheid van win per deal voorspellen, dashboards die signalen uit productgebruik en email-engagement integreren, AI-agents die deals automatisch herclassificeren bij specifieke signalen.
RevOps blijft de baas van de forecast. GTM Engineering levert de hulpmiddelen die RevOps slimmer maken.
3. CRM-architectuur: gezamenlijk eigenaarschap
Dit is het gebied waar de scheidslijn het lastigst is. Wie bezit het CRM? Mijn ervaring: het object-model en lifecycle-definiëringen zijn RevOps. De technische implementatie, custom objects, complexe automations en third-party integraties zijn GTM Engineering. De grens loopt door «wat is de definitie» (RevOps) versus «hoe wordt het uitgevoerd» (GTM Engineering).
In een gezonde organisatie zit RevOps in de planning van de CRM-architectuur, en GTM Engineering doet de daadwerkelijke configuratie. Beide reviewen de wijzigingen vóór ze live gaan.
4. Outbound: GTM Engineering bouwt, RevOps meet
Een nieuwe signal-based outbound flow? GTM Engineering ontwerpt het: welke signalen, welke databronnen, welke triggers, welke templates, welke routing. Vervolgens meet RevOps het: bounce rates, reply rates, gekwalificeerde gesprekken, gegenereerde pipeline, win rate van pipeline uit dit kanaal versus andere.
De ene rol bouwt het instrument. De andere meet of het werkt. Samen besluiten ze wat te schalen, wat te stoppen en wat te itereren.
5. Tooling-beslissingen: gezamenlijke beoordeling
Een nieuwe tool aanschaffen? Hier raakt elke kruising. RevOps stelt de criteria: past het in onze data-architectuur, voldoet het aan onze SLA's, integreert het met onze single source of truth? GTM Engineering evalueert technisch: API-kwaliteit, automation-mogelijkheden, totale onderhoudslast, of het de nieuwe build-projecten ondersteunt.
De beslissing wordt samen gemaakt. Als één van beide rollen veto uitspreekt, herstart je het proces. Dat klinkt traag, maar het voorkomt het «shiny tool»-syndroom dat veel B2B-bedrijven plagen.
Drie organisatorische modellen die werken
Hoe organiseer je dit praktisch? Ik zie in mijn praktijk drie modellen die werken, elk passend bij een andere bedrijfsfase.
Model 1: Een persoon, twee petten (early-stage, <€3M ARR)
In de seed/Series A fase heb je één persoon die beide doet. Een «Head of GTM Operations» of vergelijkbare titel die zowel definieert (RevOps) als bouwt (GTM Engineering). Voorwaarde: deze persoon moet beide vaardigheden combineren, en dat is een zeldzaam profiel.
In deze fase ondersteunen we als interim GTM-lead vaak zelf het werk - want het is duur en moeilijk om dit profiel intern te vinden. De interim bouwt het fundament, daarna kan een junior het overnemen.
Model 2: Twee aparte rollen, één manager (scale-up, €3M-€15M ARR)
Tussen €3M en €15M ARR scheid je de rollen vaak organiek. Één RevOps-medewerker (definieert, governanceert, meet) en één GTM Engineer (bouwt, automatiseert, integreert). Beide rapporteren aan een Head of RevOps of VP Operations.
In dit model is wekelijks overleg cruciaal. Wekelijkse sync over wat er gebouwd wordt en wat gemeten wordt. Kwartaalsgewijze planning over welke build-projecten prioriteit krijgen. Zonder die regelmaat ontstaat de klassieke valkuil: GTM Engineering bouwt dingen die niet aansluiten bij wat RevOps nodig heeft.
Model 3: Twee teams (enterprise/late-stage, €15M+ ARR)
Boven de €15M ARR splits je in twee subteams. Het RevOps team (vaak 3-6 mensen, geleid door een Head of RevOps) en het GTM Engineering team (vaak 2-5 mensen, geleid door een Lead GTM Engineer). Beide teams rapporteren aan een CRO of VP RevOps.
Hier ontstaat de risico dat beide teams hun eigen agenda's krijgen. De oplossing: gezamenlijke OKR's. Beide teams worden afgerekend op dezelfde top-level revenue metrics, niet op aparte team-metrics. Dat dwingt samenwerking.
De drie meest voorkomende valkuilen
Wat gaat er mis als deze samenwerking niet goed werkt? Drie patronen die ik regelmatig zie.
Valkuil 1: De «build cowboy». GTM Engineering bouwt zonder RevOps-input. Resultaat: technisch indrukwekkende systemen die niet aansluiten op de definiëringen, processen en KPI's van de organisatie. Sales gebruikt het niet. Marketing snapt het niet. De build wordt na zes maanden weer afgebroken.
Oplossing: elke build-project begint met een RevOps-brief die definieert wat er gebouwd moet worden en waarom. GTM Engineering bepaalt hoe.
Valkuil 2: De «RevOps blokkade». RevOps wil alles vooraf goedkeuren, bureaucratiseert het bouwproces en maakt experimenteren onmogelijk. Resultaat: GTM Engineering stopt met initiatief nemen, de innovatie valt stil.
Oplossing: spreek vooraf af welke beslissingen RevOps-goedkeuring vereisen (productie systemen, klant-facing automations) en welke vrije experimenten zijn (interne tooling, prototypes, sandbox-omgevingen).
Valkuil 3: De dubbele tool-stack. Beide rollen hebben hun eigen tools en data-bronnen die niet syncen. RevOps werkt vanuit Salesforce reporting, GTM Engineering vanuit een aparte data warehouse. Beide hebben gelijk over verschillende cijfers.
Oplossing: één single source of truth, vastgelegd in een data dictionary die beide teams onderhouden. Als de cijfers niet kloppen, wordt het probleem opgelost, niet weggewuifd door «ja, daarom kijken wij naar onze versie».
Waarom «wij doen beide» in onze praktijk werkt
In mijn werk — en in dat van Pack of Nodes — combineren we expliciet beide disciplines. Niet omdat het «modieus» is, maar omdat de meeste Nederlandse scale-ups een interim partner nodig hebben die het hele speelveld kan bedienen.
Concreet: voor een scale-up van €5M ARR met 8 sales/marketing mensen en geen RevOps of GTM Engineer in dienst, kunnen wij in 3-6 maanden:
- De RevOps-fundering leggen: lifecycle definiëringen, KPI-hiërarchie, SLA's, forecast-proces, comp plans;
- De GTM Engineering layer bouwen: enrichment-flows, signal-detectie, AI-agents, custom integraties;
- Het team trainen om het over te nemen: documentatie, onboarding, knowledge transfer aan een eerste interne hire.
Dit hybride model werkt omdat een externe partner in early-scale-up fase vaak meer waarde levert dan twee fulltime hires, mits de partner beide disciplines beheerst. Een puur-RevOps consultant kan de techniek niet bouwen. Een puur-GTM-Engineer kan de governance niet leggen. Wie beide kan, levert in één engagement het complete fundament op.
De relatie verandert met je bedrijfsfase
Een waarschuwing: de samenwerking tussen GTM Engineering en RevOps is geen statisch model. Het verandert mee met je groei.
Early-stage (tot €3M ARR): beide rollen vermengd in één persoon of externe partner. Snelheid en flexibiliteit overheersen. Governance is minimaal.
Scale-up (€3M-€15M ARR): beide rollen splitsen, met één hiërarchische lijn. Hier ontstaan de eerste echte processen en SLA's.
Late-stage (€15M+ ARR): beide rollen worden teams. Governance wordt formeler, build-cycles worden langer. Hier ontstaat het risico op silo's; je moet daar bewust tegenwerken.
Enterprise (€50M+ ARR): beide teams worden onderdeel van een groter RevOps-organisatieblok, vaak onder een VP RevOps of CRO. GTM Engineering kan zelfs verder opsplitsen in build-, integratie- en innovatie-cellen.
De foutmaak die ik vaak zie: founders die in early-stage al de scale-up-structuur willen invoeren. Resultaat: traagheid, bureaucratie, en zijwaartse politiek waar geen ruimte voor is in een bedrijf van 15 mensen.
De vraag «welke eerst?» beantwoord
Terug naar de oorspronkelijke vraag: als je móét kiezen, RevOps of GTM Engineering eerst?
Voor de meeste B2B SaaS bedrijven is het antwoord: RevOps eerst, GTM Engineering vlak daarna. Reden: je hebt eerst definiëringen en KPI's nodig voordat je systemen kunt bouwen die ze meten. Zonder RevOps-fundering bouwt GTM Engineering in het wilde weg. Met RevOps-fundering bouwt GTM Engineering gericht.
Maar het verschil is in de praktijk vaak slechts enkele maanden. En als je een interim of externe partner kunt inhuren die beide disciplines beheerst, doe je ze parallel. Dat is de snelste route naar een volwassen omzetmachine.
In de volgende post ga ik in op hoe GTM Engineering verandert in het tijdperk van AI, en hoe de samenwerking met RevOps daar precies onder verandert.