How to Structure a RevOps Team

The reporting line decides everything else

Before headcount, org chart, or hiring order, settle where the function reports. It determines what the team optimises for, and no amount of good hiring corrects a bad answer.

The failure in the last two rows is structural rather than personal. A function reporting into one department will, entirely rationally, prioritise that department's requests — which recreates the fragmentation RevOps exists to fix, and turns the role back into sales ops or marketing ops with a broader title.

Hiring order

1. 01
   Hire 1 — the architect

   A senior generalist who can design the data model, not an analyst who can build reports. This hire sets the architecture every later hire inherits, and getting it wrong costs about a year. Scope and pay it at manager or senior manager level.

2. 02
   Hire 2 — technical

   A RevOps engineer or a strongly technical analyst. The first bottleneck after the architecture exists is always integration and data work, not reporting. Companies that hire a second generalist here end up with two people arguing about design and nobody building.

3. 03
   Hire 3 — analytics

   Someone who owns the reporting layer, forecast mechanics, and the metrics cadence. By now there is enough clean data for this role to produce something trustworthy.

4. 04
   Hire 4 — enablement and adoption

   Often overlooked and frequently the highest-return fourth hire. Systems that nobody adopts have no value, and adoption is a job rather than a launch event.

5. 05
   Hire 5+ — specialise by function

   Only now split into marketing ops, sales ops, and CS ops specialists, keeping architecture ownership central.

The three structural models

Centralised

One team owning all systems, all definitions, and all reporting, serving the three revenue functions as internal customers. Fastest to consistency and the right default below roughly $20M ARR.

Breaks when the request queue becomes the bottleneck and functions start building shadow processes in spreadsheets to route around it. The warning sign is a business-critical spreadsheet that RevOps did not know existed.

Embedded

Ops people sitting inside marketing, sales, and CS, reporting into those functions. Highly responsive and well-liked by the teams they serve.

Breaks almost immediately on the thing that matters: three embedded operators produce three data models and three definitions of a qualified lead. This is the structure RevOps was invented to replace, and it reappears constantly because it feels good quarter to quarter.

Hub and spoke

A central team owns architecture, definitions, governance, and the data model. Spokes sit with each function and handle execution and requests within the standard. The right answer above roughly $20M ARR.

Breaks when the hub loses authority — the moment a spoke can ship a data model change without central sign-off, you have an embedded model with extra meetings. Protect that single control and the structure holds.

Headcount by stage

The ratio is a sanity check rather than a target. Materially leaner than one per twenty and the team is firefighting; materially richer than one per ten and you are usually staffing around a process problem that a definition would fix more cheaply.

When to use an agency instead

Two situations where hiring is the wrong instrument. First, the build phase — architecture, migration, and process design need several specialisms simultaneously and end, which is project-shaped work. Second, before $1M ARR, where a fractional operator gives you senior judgement at a fraction of a hire — see RevOps for early-stage startups for what to build in the meantime.

The sequence that works for most companies is agency for the build, in-house for the run, with the first internal hire brought in near the end of the build so they inherit a system they helped finish rather than one they have to reverse-engineer.

The failure modes to watch

• A request queue with no prioritisation. The team becomes reactive and architecture never gets built. Fix with a standing roadmap allocation — typically 30% of capacity ring-fenced.
• No named owner per system. Everything is everyone's, so nothing is maintained. One name per system, written down.
• Analysts hired before architects. Produces excellent reports on a broken data model, which is worse than no reports because people trust them.
• RevOps in the approval path for everything. The team becomes a bottleneck and gets routed around. Govern the data model; delegate the rest.