Don't bury the builder under RevOps

Pre-pipeline build and in-pipeline governance are peer seats. Nest them and the builder becomes a ticket queue.

Oren Greenberg's org write-up puts the failure in one line most CROs still ignore. Apollo.io's 2026 number in that piece: about 28% of sales reps hit quota. The companies closing the gap faster run better systems. Then they bury GTM Engineering inside RevOps by default. Not by design. GTM Engineers in the same framing command roughly $131K-$180K+. RevOps managers average about $97,749. At $10M-$50M ARR, the correct structure is two peer functions under the CRO: RevOps on in-pipeline governance, GTM Engineering on pre-pipeline infrastructure.

Put the builder under the admin and you get reports, not pipeline.

What is the nesting failure?

A new CRO inherits RevOps, hears "GTM Engineering," and does one of three things.

They hire a GTM Engineer and drop them under the RevOps manager. They rename RevOps to GTM Engineering without changing the mandate. Or they ignore the split and wonder why pipeline stays thin while the CRM looks tidy.

Greenberg's first failure mode is the common Series B mistake: bury the builder under a manager who came up through Salesforce administration. The GTM Engineer gets CRM data projects, Zapier maintenance, report building. The actual capability (enrichment pipelines, Clay workflows, signal-to-sequence rails) never ships. They leave inside a year. The CRO decides GTM Engineering was hype.

That is not a talent problem. That is a seat problem. The seat is the mandate.

How do build and run actually split?

RevOps is governance in the pipeline. CRM hygiene. Forecasting. Territory. Deal desk. Attribution. Keep the trains on time.

GTM Engineering is build before the pipeline. Signal capture. Enrichment infrastructure. Outbound automation. Intent-to-sequence workflows. Tooling that creates pipeline from nothing.

RevOps vs GTM engineering is the definition post. This post is the org chart consequence. Same words. Different question: who reports to whom?

Greenberg pushes the framing further for design purposes: RevOps as governance, GTM Engineering as a product function. Different management model. Different success metrics. Different reporting line. Collaborate on data standards. Do not report to each other.

An SDR who goes from 4 SQLs a month to 6 is a productivity jump. In that piece's Everstage citation, that delta is almost always a GTM Engineering output, not a RevOps output. RevOps helps the AE close what exists. GTM Engineering helps create the conditions for the deal to exist.

When do you put them side by side?

Sequence by stage. Wrong order is expensive.

Sub-$10M ARR: GTM Engineering is often the first ops-engineer hire, reporting to a Head of Growth or COO. Pipeline creation is the constraint. Do not hire a RevOps manager first if you still cannot create pipeline.

$10M-$50M ARR: enough pipeline that forecasting and deal desk matter, and enough GTM complexity that pre-pipeline needs a named owner. Two peers under the CRO. Separate OKRs. Direct lines up.

$50M+: GTM Engineering may earn a VP-level seat when signal-based outreach and multi-channel automation are the motion. Ratios start to look like how enterprise teams staff Sales Engineers against AEs, adjusted for motion complexity.

The consistent rule across stages in that framing: GTM Engineering should never report into RevOps. Alongside. Tight collaboration. Not subordinated.

What should a CRO do this week if the builder is already buried?

Not a theatrical reorg. A mandate clarification.

1. Write what GTM Engineering owns: pre-pipeline infrastructure, signal capture, outbound automation, enrichment tooling.
2. Write what RevOps owns: in-pipeline governance, forecasting, CRM administration, attribution.
3. Give each function a direct line to you with separate OKRs.
4. Protect the builder from the service desk. Sprint cycles. Defined outputs. Outcome metrics tied to meetings and pipeline, not ticket count.
5. If your RevOps lead is strong on process and light on build, do not "temporarily" nest the builder there. Temporary nesting is how Convert capacity dies quietly.

Would you rather a clean forecast on a thin top of funnel, or a slightly messier CRM with a builder shipping signal-to-meeting systems every sprint?

Meetings, not theater is still the scoreboard. What is GTM engineering? is the work. The org chart is the statement of what you believe creates pipeline.

Salesforce still puts about 27% of reps at quota. Apollo's ~28% in Greenberg's piece is the same ugly neighborhood. Nesting the only seat that builds pre-pipeline systems under the seat that administers the CRM is how you stay in that neighborhood with prettier dashboards.

Adapt or fail. Peer seats. Separate OKRs. Builder free to build.

Start Signals, Convert, Grow

FAQ

Is this the same as RevOps vs GTM engineering on the site?

No. That post defines the work. This post is org design: do not nest the builder under RevOps. Link both. Do not collapse them.

Should GTM Engineering ever sit inside RevOps?

Not as the steady state in Greenberg's framing. Collaborate yes. Report into RevOps no. Subordinating build to run is how build stops building.

What if I only have budget for one hire?

Hire for the constraint. No pipeline creation: builder first, often under Growth/COO early. Pipeline exists but forecast and close are chaos: RevOps first. Do not hire a nested hybrid and hope the org chart sorts itself.

How do comp bands support the peer-seat argument?

Greenberg's write-up puts GTM Engineers around $131K-$180K+ and RevOps managers averaging about $97,749. Different people. Different management. Different seats.

Where does this sit in Signals → Convert → Grow?

Signals and Convert need the builder's pre-pipeline systems. Grow needs RevOps governance so scale does not melt the CRM. Peer functions under the CRO keep both mandates alive.