Three possible positions
An integrative function in a GTM organisation can structurally occupy three positions. Inside a function (e.g., a RevOps team embedded in sales): the team has operational depth but no cross-functional authority. Above the functions (e.g., a cross-functional executive committee): the team has authority but lacks the operational depth where the relevant knowledge lives. Beneath the functions (the operational layer): the team has both — depth and cross-functional reach.
Most underperforming RevOps implementations sit in one of the first two positions. The third — beneath the functions — is the structurally correct one but requires deliberate governance design to establish.
What 'beneath' actually means
The operational layer is the substrate the functions all share — the data infrastructure, the system integrations, the cadences and processes, the enablement and tooling. It is not a hierarchical position; it is a structural one. A RevOps function can sit at any reporting level and operate at the operational layer, as long as it has authority over the shared substrate.
What 'beneath' rules out is operating only inside one function (losing cross-functional reach) or only at the executive layer (losing operational depth). The strongest implementations report to a senior leader (CRO, COO, or CEO) but operate at the operational layer across the functions.
Implications for design
The operational-layer position implies three design choices. First, the function must have explicit authority over the shared substrate — data definitions, system integrations, cross-functional cadences, enablement programmes. Without this authority, the function reduces to one-off support work. Second, the function must have a reporting line senior enough to defend its authority against functional pushback. Third, the function's decision rights must be specified explicitly — what it owns versus advises versus escalates — because ambiguity at the operational layer produces friction with every function.