When a B2B company decides it needs "someone for HubSpot," there's usually a gap between what they ask for and what they actually need.
The job post goes up. The brief says something like: HubSpot experience required. Will manage workflows, maintain contact database, support marketing campaigns. A few candidates apply. Someone gets hired. Six months later, the problem that prompted the hire still hasn't been solved — it's just been better-documented.
This isn't a people problem. It's a scoping problem. And it comes from conflating two very different functions: CRM administration and RevOps architecture.
A CRM admin is an operator. They work within a system that's already been designed — maintaining it, troubleshooting it, training users on it, and executing tasks that require platform knowledge.
Good CRM admins are genuinely valuable. A well-maintained HubSpot portal doesn't happen by accident. Properties need updating. Lists need pruning. Workflows drift out of spec. Someone needs to handle support tickets when a workflow breaks at 11pm before a product launch.
But admins are executing within a defined system. They're not designing the system.
A RevOps architect is working at a different altitude.
They're asking: How should revenue flow through this organisation? What does the lifecycle look like from first touch to renewal? Where is the handoff between marketing and sales, and how do we enforce it? What does attribution need to look like for the CFO to trust the marketing spend report?
Then they're building the infrastructure to answer those questions: data models, scoring logic, lifecycle automation, integration architecture, pipeline design, and the reporting layer that sits on top.
The practical difference shows up fast. When a CRM admin encounters a problem — say, MQL numbers that don't match between HubSpot and the board deck — they'll investigate the workflows and the data. When a RevOps architect encounters the same problem, they're asking whether the lifecycle stage definition is even correct, whether the attribution model is the right one for the business, and whether the reporting being pulled is measuring the right thing.
One is debugging. The other is redesigning.
At 10 salespeople and a single product, the line between admin and architect is blurry. The system is simple enough that a competent admin can keep it working while making the occasional structural decision.
At 50 salespeople, multiple product lines, a separate SDR function, a customer success team sharing the CRM, and a CFO asking for revenue attribution by channel — the system can no longer be held together by someone who's good at HubSpot. You need someone who's good at revenue operations design, who also knows HubSpot.
That's a narrower pool, and it's a different job.
If you're trying to figure out what your organisation actually needs, start here:
1. Do you have a defined lifecycle architecture? Not just lifecycle stages in HubSpot — an actual documented model that specifies what triggers movement between stages, who owns each stage, and what the SLA is for follow-up. If the answer is no, you need an architect.
2. Can your current reporting answer: "Where in the funnel are we losing revenue, and why?" If the answer is "sort of" or "we pull it manually," you need someone to redesign the reporting infrastructure, not just maintain it.
3. Are your GTM tools talking to each other? If data from your ABM platform, your enrichment tool, and your CRM isn't reconciling cleanly — and someone's manually copying fields between systems — you need an integration builder, not a form manager.
4. Is your CRM being used as a system of record or a system of action? Systems of record store data. Systems of action drive behaviour — surfacing the right playbook at the right deal stage, automating the right follow-up, alerting the right person when a deal goes cold. If your HubSpot is only doing the former, you're underutilising it significantly.
Not every company needs (or can afford) a full-time VP of RevOps. But they do need the thinking — particularly during periods of rapid growth, post-Series A fundraising, or before a critical go-to-market pivot.
This is where fractional RevOps architecture makes commercial sense. Bringing in senior-level GTM engineering expertise for a defined period — to design the system, build the infrastructure, and hand it over with documentation — is often a better use of budget than hiring someone full-time who will spend most of their time maintaining a system that was never properly built.
The question isn't just "who can manage our HubSpot." It's "who can design the revenue infrastructure this business is going to need for the next 18 months."
Those are different questions. Make sure you're asking the right one.