Every scaling SaaS company eventually reaches the same inflection point.

The CRM is a mess. Pipeline numbers don’t match between reports. The forecast is a confidence exercise, not an analytical one. Marketing is generating leads that sales ignores. Sales is closing deals that CS can’t retain. Someone in the leadership team says: “We need a RevOps person.”

They’re usually right. But the question isn’t whether you need RevOps. It’s when to hire, what to hire them for, and at what level of seniority. Most companies get at least two of those three wrong.

I’ve seen this play out dozens of times. The consequences of getting it right or wrong compound for years.

The Too-Early Trap

Here’s a pattern I see constantly.

A company raises a Series A. They’re at 15 reps, maybe 20. The CRM is messy because it was set up during founder-led sales and nobody had time to think about data architecture. A board member mentions RevOps. The CEO posts a job listing.

They hire someone at the “RevOps Manager” level. This person is competent. They know Salesforce or HubSpot. They start cleaning up the CRM, building reports, and fixing broken automations.

Six months later, the CRM is tidier. But the revenue operations are no more strategic than before. Pipeline definitions are still whatever each rep decides they mean. The forecast is still based on gut feel with a dashboard veneer. The handoff between marketing and sales is still a Slack message. Territory design doesn’t exist.

What happened? They hired a CRM administrator and called them RevOps.

This isn’t the hire’s fault. They’re doing exactly what they were hired to do: make the tools work. But the company needed someone to design how the revenue engine works. The gap between those two jobs is enormous. I’ve written about this distinction in detail because it’s the single most common mistake I see in RevOps hiring.

The too-early trap isn’t really about timing. It’s about scope. The company hires for system configuration when they need operating model design. They hire a builder before they have an architect.

The Too-Late Trap

The opposite failure is worse.

Some companies wait until they’re at 50 or 80 reps before making a RevOps hire. By that point, three to four years of operational decisions have been made without any architectural intent. Every sales manager has their own process. The CRM has 400 custom fields, half of which nobody uses and nobody is sure which half. Pipeline stages mean different things in different segments. Attribution is a fantasy. Comp plans have been designed in spreadsheets and enforced through trust.

The first RevOps hire walks into years of accumulated data debt, and their entire tenure becomes a cleanup exercise.

This is how RevOps becomes reactive. Not because the person lacks ambition or capability, but because the backlog of structural problems is so deep that strategic work never reaches the top of the list. Every week brings another fire: a broken integration, a report that doesn’t tie out, a comp dispute that needs data to resolve, a board deck that needs numbers nobody trusts.

I’ve seen senior RevOps leaders spend their entire first year doing nothing but data remediation and process archaeology. By the time they’re ready to build forward, the organisation has already categorised them as “the person who fixes things,” not “the person who designs things.”

The too-late trap is a compounding problem. Every quarter you operate without revenue architecture, you’re generating more debt that the eventual hire will have to service.

The Signals That You Actually Need the Hire

So when is the right time?

Forget headcount thresholds. The signals are behavioural, not numerical. You need a RevOps hire when any three of these are true:

You can’t trust your pipeline. Not because the CRM is broken, but because you don’t have shared definitions of what pipeline stages mean, what qualifies an opportunity, or what exits look like. Sales leadership has a number. The CRM has a different number. Marketing has a third. Nobody knows which is real.

Your forecast is guesswork dressed as analysis. You have dashboards, but the forecast call is still a negotiation. Managers commit based on relationship knowledge, not data. The gap between forecast and close is consistently wide, and you can’t explain why.

Your tech stack is growing organically. Marketing bought a tool. Sales bought a tool. CS bought a tool. Nobody mapped the data flow between them. You’re paying for six tools that overlap and three gaps that none of them cover. Integration is held together with Zapier and manual exports.

Handoffs are breaking. Leads go dark between marketing and sales. Deals close and CS is surprised by what was sold. Renewals are managed in spreadsheets. Every transition between teams loses context, momentum, or both.

You’re about to raise or have just raised a growth round. Investors will start asking about unit economics, CAC payback, net revenue retention, and segment-level profitability. If you can’t produce those numbers reliably, you have a RevOps problem, not a finance problem.

If three or more of those resonate, the timing is right. The question becomes what you hire for.

What to Actually Hire Them For

This is where most job descriptions go sideways.

I’ve reviewed hundreds of RevOps job postings. The majority read like a tools inventory. “Experience with Salesforce, HubSpot, Outreach, Gong, Clari, LeanData, Marketo.” They list every tool in the stack and ask the candidate to be proficient in all of them.

That’s not a job description. That’s a wish list for a system administrator.

The first RevOps hire should be accountable for designing the revenue operating model. That means:

Defining the end-to-end revenue process, from lead creation through to renewal and expansion. Establishing pipeline governance: stage definitions, qualification criteria, entry and exit rules, inspection cadence. Architecting the data model so that every metric the business cares about can be derived from clean, governed source data. Designing the measurement framework that connects leading indicators to lagging outcomes. Mapping the tech stack to business requirements, not the other way around.

This is architectural work. It’s the difference between someone who can build walls and someone who can design the building. You need the architect first. The builders come later.

If the job description leads with tools, you’ll attract tool operators. If it leads with outcomes, designing a forecasting methodology that lands within 10% of close, building a pipeline governance model that reduces late-stage fallout by 30%, architecting data infrastructure that supports board-level reporting without manual intervention, you’ll attract the kind of person who can actually move the function forward.

The Seniority Question

Should you hire junior or senior?

This is the question I get asked most often, and the answer is almost always the same: your first RevOps hire should be more senior than you think you need.

Here’s why. A junior ops person can maintain a system. They can build reports, manage workflows, handle data hygiene. That’s valuable once you have a system to maintain. But if you’re making your first RevOps hire, you don’t have a system yet. You have a collection of tools and processes that evolved organically. What you need is someone who can look at the whole picture and design the architecture.

A junior hire in this situation will default to what they know: tool configuration. They’ll start fixing the CRM because that’s the tangible problem in front of them. They won’t challenge your pipeline definitions because they don’t have the experience or the organisational authority to do so. They won’t push back on your forecasting methodology because they’ve never designed one.

A senior hire, someone who has built RevOps functions before, will start with the operating model. They’ll ask uncomfortable questions about process, data, and accountability before they touch a single tool. They’ll tell you what you need to hear, not what you want to hear. They’ll design the architecture first and configure the systems second.

The counterargument is cost. A senior RevOps leader costs more than a junior ops analyst. That’s true. But the cost of getting the architecture wrong, of building on a weak foundation for two years before realising you need to rearchitect, is significantly higher than the salary delta.

The Fractional Alternative

There’s a third option that most companies don’t consider, and it’s often the right one.

Instead of hiring a full-time RevOps person, bring in a senior operator on a fractional basis to do the architectural work first. Design the operating model. Define the data architecture. Build the pipeline governance framework. Map the tech stack. Create the measurement model. Document the playbook.

Then hire a mid-level operator to maintain and iterate on what was built.

This approach gives you senior-level architecture without the full-time cost, and it means your eventual full-time hire walks into a designed system rather than a blank canvas. They can focus on execution and iteration instead of spending their first year figuring out what the job even is.

I’ve seen this model work repeatedly. The fractional engagement typically lasts three to six months, covers the foundational design work, and creates a clear brief for the permanent hire. The company gets better architecture at a lower total cost, and the permanent hire gets a better job. It also avoids the seniority trap: you get a senior architect for the design phase and a mid-level operator for the maintenance phase, instead of compromising on one person who’s supposed to do both.

If you’re evaluating this path, a RevOps consulting engagement scoped to operating model design can serve the same purpose. The key is separating the architectural work from the operational work and staffing each appropriately.

The Job Description Mistake

Let me close with the most tactical point.

If you’ve decided the timing is right and you know what you’re hiring for, don’t sabotage the process with a bad job description.

The single biggest mistake in RevOps job descriptions is listing tools instead of outcomes. You end up filtering for people who have used specific software, rather than people who can design revenue systems. The best RevOps hire I ever made had never used our CRM before joining. She’d designed operating models at three previous companies and could learn any tool in a week. If the job description had required five years of Salesforce experience, we’d have missed her.

Lead with what the role is accountable for. Pipeline accuracy. Forecast reliability. Data integrity. Process governance. Cross-functional alignment. Tech stack rationalisation. These are outcomes. The tools are implementation details.

List the problems, not the platforms. Describe what success looks like in twelve months, not what certifications the candidate should hold. Attract architects, not administrators.

Your first RevOps hire sets the trajectory for the entire function. Every subsequent hire, every process decision, every system choice will be influenced by the foundation this person builds or fails to build. Get the timing right, scope the role correctly, hire at the right level of seniority, and lead with outcomes.

The alternative is spending two years building on a foundation that wasn’t designed, then spending two more years rebuilding it. I’ve watched that cycle play out more times than I can count. It’s always expensive. It’s always avoidable.