Where GTM engineering should sit in the org, and how that changes as it matures
Most companies start GTM engineering inside RevOps. That is the right call. Where it goes from there depends on what the function is being asked to do.
The dominant pattern for structuring GTM engineering is to embed it inside RevOps first. The logic is sound: RevOps already owns data pipelines and data quality. Sitting GTM engineering there draws a straight line from “we identified a friction point” to “we shipped the fix” without a handoff. Companies like Intercom, Notion, and Anthropic all started this way.
The second pattern is embedding GTM engineering inside Growth. This works when the primary mandate is demand generation. Programmatic landing pages, intent-based outreach, real-time visitor campaigns. Ramp, Verkada, and Rippling operate this way. The advantage is proximity to the ideas that benefit most from technical execution: targeting a specific cohort based on a signal combination, running a personalised direct mail campaign at scale, building lookalike models from won customer data.
The pattern that emerges at scale, regardless of where the function starts, is a split between prototypers and implementers. Generalists close to the commercial team build proofs of concept fast: a Clay table, a workflow, a signal-based sequence. When a play proves it works, engineers harden it to run at production scale without breaking.
Starting in ops and federating outward is the most common maturity path. The data foundation gets built under RevOps. Once it’s solid, GTM engineers move outward into growth and customer success functions, carrying the foundation with them. Companies that try to federate before the data foundation is stable end up with multiple teams running plays on inconsistent data.
The org chart question matters less than the mandate question. A GTM engineer embedded in RevOps with a mandate to proactively build revenue plays will outperform a GTM engineer embedded in Growth with a mandate to manage the marketing tech stack. The function is defined by what it’s chartered to do, not by the org chart line above it.
The practical question when hiring the first GTM engineer: who does this person report to, and what is the first problem they’re expected to solve? The answer to both shapes everything about how the role gets built.