Every RevOps team I’ve seen that works well was designed. Every one that doesn’t was accumulated.

The difference matters more than people think. A team that was built deliberately, with clear role boundaries, appropriate seniority at each stage, and intentional reporting lines, operates as a strategic function. A team that was assembled through a sequence of urgent hires, each one patching the gap the previous hire didn’t cover, operates as a service desk with a strategy title.

Most RevOps teams are the second type. Not because the people are wrong, but because nobody treated the team structure as a design problem.

I’ve built and restructured RevOps functions at every stage, from solo operator to full centre of excellence. The patterns of what works and what creates expensive dysfunction are remarkably consistent.

The Solo Operator Stage

Every RevOps function starts with one person. The question isn’t whether that person will be stretched. They will. The question is what they should own versus what they should deliberately defer.

I’ve written about when to make this hire and the most common mistakes companies make with it. But once the hire is made, the scoping question becomes critical.

The solo operator should own the operating model, not the tool stack. Their job is to design the revenue architecture: pipeline governance, stage definitions, forecast methodology, data model design, process mapping across the full customer lifecycle. They should be the person who decides what the system should enforce and why.

What they should defer, aggressively, is system administration. Report building, flow configuration, user permission management, data imports. This work matters, but it’s implementation, not architecture. If your solo RevOps person is spending 70% of their time configuring Salesforce, you don’t have a RevOps function. You have a CRM administrator with a strategic title.

The practical solution at this stage is to pair the solo operator with either a part-time admin resource or a fractional engagement that handles the build work while the operator focuses on design. The worst outcome is hiring a senior person and burying them in tickets. The second worst is hiring a junior person who can execute but can’t architect.

One person can design a revenue operating model. One person cannot design it and build it simultaneously. The companies that understand this get two years of compounding advantage over the ones that don’t.

The Two-to-Three Person Team

The first expansion is the most structurally consequential. Get this wrong and you’ll spend the next eighteen months untangling role confusion.

The instinct most companies have is to hire a second RevOps person who does “more of the same.” This is a mistake. The point of the second hire is to create a structural split between strategy and execution, not to double the capacity of an undifferentiated function.

The split should be architecture versus implementation. One person owns the operating model, process design, measurement framework, and cross-functional alignment. The other owns the system layer: CRM configuration, automation, integrations, data quality, and reporting.

At three people, you introduce the first specialisation. The most common, and usually the most valuable, third addition is an analytics-focused role. Not a dashboard builder. Someone who can construct the analytical models that connect leading indicators to revenue outcomes, build the forecast methodology, and own the data architecture that makes everything else trustable.

Here’s the structure I’ve seen work most consistently at this stage:

The RevOps lead owns process design, cross-functional governance, strategic planning support, and the relationship with sales, marketing, and CS leadership. The systems operator owns CRM administration, tech stack management, integrations, and automation. The analytics operator owns the data model, reporting framework, forecast methodology, and metric definitions.

Three roles. Three clearly distinct domains. No overlap in ownership.

The failure mode here is splitting by department instead of by function. One person for “Sales Ops,” one for “Marketing Ops,” one for “CS Ops.” This recreates the silos that RevOps was supposed to eliminate. You end up with three people who each optimise their segment and nobody who governs the whole system. The entire point of revenue operations is cross-functional architecture. Department-aligned roles destroy that by design.

The Full Function: Five or More

At five-plus people, RevOps becomes a true function with enough capacity to cover the full scope of revenue architecture. This is where you start building distinct capability areas rather than relying on generalists who stretch across everything.

A mature RevOps function needs five capabilities, whether they map to five people or fifteen. The capabilities are systems, analytics, enablement, strategy, and deal desk.

Systems covers the entire tech stack: CRM, marketing automation, sales engagement, CS platform, integration layer, and data infrastructure. This team builds and maintains what the operating model requires. At scale, this might be two or three people with tool-specific depth.

Analytics owns the measurement layer. Forecast modelling, pipeline analysis, segment-level unit economics, board-level reporting, and the data governance that makes all of it trustworthy. This is where most RevOps teams are chronically underinvested. Companies will hire three system admins before hiring one serious analyst.

Enablement, in this context, is not training. It’s the bridge between process design and process adoption. When the operating model changes, enablement ensures the change actually lands in how people work. This includes documentation, change management, communication cadence, and the feedback loops that tell you whether a new process is being followed or ignored. I’ve written about why change management is an architecture problem, and this role is where that architecture gets executed.

Strategy is the senior function. Operating model design, capacity planning, territory architecture, compensation structure, pricing governance, and the cross-functional alignment work that keeps marketing, sales, and CS operating as a single revenue system rather than three separate departments with a shared CRM.

Deal desk is often overlooked in RevOps team design, but it’s where commercial governance lives. Pricing approvals, discount authority, non-standard term management, and the exception handling that, left ungoverned, creates the hidden cost of revenue exceptions. At companies with complex deal structures, this function prevents more revenue leakage than almost anything else.

The key principle at this stage: every capability should have clear ownership, and the team should be structured by function, not by department or by tool. A “Salesforce team” and a “HubSpot team” is the wrong structure. A systems team that manages all platforms as a unified architecture is the right one.

The Enterprise Centre of Excellence Model

At enterprise scale, the structural question shifts from “how big should the team be” to “where should the team sit.” This is where the centralised-versus-embedded debate begins, and where most large companies create their most expensive RevOps dysfunction.

The answer, in almost every case I’ve seen work, is a federated model. A central RevOps centre of excellence owns standards, governance, data architecture, and the core operating model. Embedded operators sit within business units or regional teams and execute against that architecture within their local context.

The central team defines the pipeline stage definitions, the data model, the forecast methodology, the metric framework, and the technology standards. The embedded operators adapt execution to their segment while maintaining compliance with the central architecture.

The failure modes at this level are predictable. Fully centralised RevOps becomes disconnected from the business. It produces beautiful frameworks that nobody uses because they don’t account for how the field actually works. Fully embedded RevOps recreates silos. Each business unit builds its own processes, its own reports, its own definitions, and the company loses its ability to see revenue as a single system.

Federated governance, where the centre sets standards and the edges execute them, is the structural pattern that scales. It requires a senior leader who can hold the line on architectural standards while giving embedded teams enough flexibility to operate effectively.

Reporting Lines: Where RevOps Should Sit

This is the question I get asked most often, and the one with the most consequential trade-offs. Who should RevOps report to?

There are three common models, and each comes with structural advantages and risks.

Reporting to the CRO or VP Sales. This is the most common model and the one I’d recommend least in most cases. RevOps gets proximity to revenue execution, which is valuable. But it also gets captured by sales priorities. Pipeline reporting, forecast calls, and quota management consume all available capacity. Marketing operations and CS operations become afterthoughts. The function stops being “revenue operations” and becomes “sales operations with a broader title.” The conflict of interest is structural: the person RevOps reports to is the same person whose forecast RevOps is supposed to validate independently.

Reporting to the CEO or COO. This gives RevOps the independence and cross-functional authority it needs. The function can genuinely serve the entire revenue system without being captured by one department’s priorities. The risk is distance from execution. RevOps needs deep context on what’s happening in the pipeline, in deals, and in customer relationships. Reporting to the CEO can create a gap between strategy and operational reality if the RevOps leader doesn’t actively maintain those relationships.

Reporting to the CFO or Finance. This model is gaining traction, and for good reason. Finance and RevOps share the same core interest: accurate data, reliable forecasting, and economic discipline. The risk is that RevOps becomes a reporting function rather than an operational one. Finance-aligned RevOps is excellent at measurement and terrible at process design if the mandate isn’t explicitly broad enough.

My default recommendation: RevOps reports to the CEO or COO until the function is mature enough to hold its own authority, then transitions to a CRO reporting line only if the CRO’s mandate genuinely covers the full customer lifecycle. If your CRO is really a VP of Sales with a bigger title, RevOps under them will become sales ops within six months.

The Most Common Structural Mistakes

I’ve seen the same mistakes create dysfunction at dozens of companies. They’re predictable, and they’re avoidable.

Hiring administrators before architects. The first RevOps hires are system-focused rather than strategy-focused. The team builds capability in CRM configuration but never develops the operating model design capability that makes the configuration meaningful. By the time a senior leader joins, the team’s identity is already “the people who fix Salesforce,” and shifting that perception takes years.

Splitting by tool instead of function. One person owns Salesforce. Another owns HubSpot. A third owns Outreach. Nobody owns the end-to-end revenue process. The tech stack gets well-maintained and the operating model stays fragmented. Tools are infrastructure. Functions are what the business actually needs RevOps to govern.

No clear authority over process. RevOps designs a pipeline governance framework. Sales leadership ignores it. Nothing happens. If RevOps doesn’t have the organisational authority to enforce process standards, it’s an advisory function, not an operational one. Authority has to come from reporting lines and executive sponsorship. It doesn’t materialise from good intentions.

Growing the team without growing the mandate. The team goes from two to five people, but they’re all still doing the same work: report requests, system fixes, and data cleanup. Headcount increased but the function’s scope didn’t. The team is bigger but not more strategic. This is what happens when you let RevOps become reactive and then try to solve it with more people instead of a clearer mandate.

Treating enablement as someone else’s problem. RevOps designs a new process. Nobody tells the reps. Or someone sends a Slack message and calls it enablement. Six months later, adoption is at 30% and leadership concludes the process doesn’t work. The process was fine. The change management was nonexistent.

When to Bring in Fractional Leadership First

Here’s the contrarian take: most companies shouldn’t build a RevOps team before they have a RevOps architecture. And most companies can’t build that architecture with a full-time junior hire.

The highest-leverage move, especially between Series A and Series C, is to bring in a fractional RevOps leader to design the function before you staff it. A fractional operator can define the operating model, design the team structure, write the role descriptions, establish the reporting cadence, and build the architectural foundation that the full-time team will execute against.

This takes three to six months. The cost is a fraction of a mis-hire. And the output, a clear operational design, is what makes every subsequent hire productive from day one instead of spending their first quarter figuring out what they’re supposed to do.

I’ve seen companies hire three RevOps people in eighteen months and still not have a functioning operating model because nobody designed one before the hiring started. The team was assembled before the architecture existed, and each person defined their own scope based on what seemed urgent. The result was overlap, gaps, and no strategic coherence.

The alternative is straightforward. Design the architecture first. Define what the function needs to own. Specify the roles and the sequence in which you’ll hire them. Then hire against that design. The difference between these two approaches is the difference between a RevOps engagement model that compounds value and one that compounds cost.

A RevOps team without an operating model is just headcount. An operating model without a team is a blueprint waiting to be built. Always start with the blueprint.