Podcast
July 8, 2026
Episode 98: Building a World-Class RevOps Team Without a World-Class Budget
Marisol Jordan on hiring GTM engineers, avoiding common RevOps team-building mistakes, and why AI changes everything except the fundamentals.
Most RevOps leaders are working with constrained resources and unlimited demands. The question isn't whether to make trade-offs — it's whether you're making the right ones. That tension is exactly where this conversation lives.
In this episode of RevOpsAF, Marisol Jordan, Senior Director of Revenue Operations at Cobalt, joins co-host Matthew Volm to talk through the hiring decisions, structural trade-offs, and forward-looking questions that define what it means to build a RevOps team today. Marisol brings more than 20 years of experience spanning sales operations, finance, marketing, and customer success — a journey that mirrors the way RevOps itself was assembled from the parts that already existed. Her perspective is grounded in the practical reality of running a lean team while the expectations on that team keep growing.
The conventional hiring logic in operations — put the marketing ops person in marketing, the CS ops person in customer success, and so on — made sense for a while. The problem is that it optimized for proximity to stakeholders at the expense of coherence across the revenue engine. When RevOps consolidated those functions under one roof, it created a new challenge: a single person can't simultaneously be strong analytically, operationally, and technically across every go-to-market motion.
Marisol is direct that this is where most leaders go wrong. Bringing in someone with deep customer success familiarity and expecting them to handle analytics, process design, and systems work across the full GTM motion is a setup for a lopsided team. Something always gives. Usually it's either the data quality or the cross-functional visibility that suffers — two things that RevOps specifically exists to protect.
"You need that strong analyst that's gonna be across all motions to be able to inform leaders and create that alignment — and the same thing with the technical piece, and the same thing with your growth ops person."
— Marisol Jordan
The implication here is direct: when headcount is limited, hire for cross-functional capability first and functional familiarity second. A strong analyst who understands the full GTM motion — MQLs and conversion rates on the marketing side, pipeline coverage in sales, net dollar retention (NDR) and gross dollar retention (GDR) in customer success — is worth more than a specialist who can go deep in one area but can't connect the dots across all three. This connects to a broader structural challenge the community has grappled with for years; how RevOps organizations get built and what they actually own shapes every downstream decision about who to hire and how to deploy them.
The one-hire thought experiment is a clarifying exercise for any RevOps leader, and it surfaces something worth sitting with. Marisol's answer: a GTM engineer with a strong technical backbone and genuine curiosity about the business.
Matthew offered a complementary lens from his own experience — complementing your own strengths and weaknesses rather than defaulting to functional fit. His background in finance and analytics meant his first hire needed to be a systems person, not another analyst. And critically, he wasn't looking for certifications — he was looking for someone who could demonstrate they had gone out and learned a new tool to solve a real problem.
"You need to bring someone in that's able to do all sorts of things — which right now I think that position's being put out there as a GTM engineer. Before it was that Salesforce admin or that HubSpot admin. No longer are we just saying, 'Hey, let's get a Salesforce admin.' Now we're saying, 'We need a Salesforce admin that understands GTM.'"
— Marisol Jordan
The certification conversation is worth unpacking. For years, Salesforce admin credentials were a reliable proxy for technical capability. That proxy has broken down — not because certifications don't matter, but because the technical surface area has expanded far beyond any single platform. A GTM engineer needs to work across the full stack: CRM, marketing automation, enrichment tools, AI automation layers, and whatever gets added next. Curiosity and demonstrated learning velocity matter more than any particular credential. The same dynamics appear in how RevOps teams are thinking about rebuilding their tech stacks for a more integrated, less bloated future.
The GTM engineer title is everywhere right now, and with any new title comes the risk of rebranding old thinking rather than genuinely changing what the role demands. Marisol takes this concern seriously.
The evolution she describes isn't just cosmetic. The Salesforce admin of ten years ago was fundamentally an order-taker: here are the business requirements, go build the thing. The GTM engineer that's emerging from that lineage is expected to understand why the build matters — what the business objective is, what the strategic trade-offs are, and what technical debt is being created along the way.
"The difference is with our Salesforce admins in the past — I think we've evolved. Because now you are looking at that GTM engineer, and they do have their Salesforce admin experience or the HubSpot experience. Now we're expecting them to also understand business requirements and understand what our strategy is, and not just the technical build, but the impact of certain decisions that we're making in our tools to be able to support the business objectives."
— Marisol Jordan
Matthew put the risk plainly: he doesn't want history to repeat itself where the industry invents a new title and applies the same order-taker framing to a new set of tools — in this case, AI platforms instead of CRMs. The concern is legitimate. If GTM engineers are just AI admins who build whatever they're told without connection to outcomes, the pattern that produced so much Salesforce technical debt simply replicates itself with an AI layer on top.
The antidote Marisol points to is accountability to outcomes. When she's interviewing candidates today, the question isn't "what did you build?" It's "what impact did it have on revenue, and how did it change the sales motion?" That shift — from technical deliverable to business result — is the structural change that separates the GTM engineer role from what came before. This is squarely in the territory that Episode 82: The Next GTM Hero: Revenue Engineer explored from a slightly different angle, and it's worth reading those two conversations alongside each other.
One of the more honest moments in this conversation is the acknowledgment that everyone is behind on AI — candidates and hiring managers alike. When Marisol says she's been "flooded with talented people" for her current GTM engineer opening, she's also acknowledging that the talent pool is sorting itself out in real time.
The parallel to the early RevOps era is apt. When revenue operations first emerged as a function, companies were posting roles that required ten years of RevOps experience — for a discipline that was maybe three years old. Expecting candidates to have extensive production AI experience for a role category that barely has a name yet creates the same mismatch.
"I'd say that, I'm surprised to see a lot of engineers or software developers or that type of role involved more into GTM, and them naturally doing that throughout the years. We're thinking this is a new role, this is a new title. But to my surprise, I think it's been evolving behind the scenes and naturally people with that strong technical skill set — developers, engineers — have moved into the GTM space to be more involved."
— Marisol Jordan
What this means practically for candidates: the story matters more than the resume line. Matthew's framing is useful here — problem, solution, outcome. If you haven't had the opportunity to deploy AI in a business context, a personal project with that structure still demonstrates the capability that matters: you saw a problem, you chose a tool, you built something, and you can describe what changed. Marisol confirmed this directly — a candidate who came in with personal-project AI examples, was honest about not having had the opportunity at work, and articulated the outcome clearly left a stronger impression than candidates who had vague enterprise AI exposure but couldn't connect it to results.
For anyone navigating the job market in RevOps right now, Run Your Job Search Like a Revenue Engine covers the mechanics of this in depth, and the principle of leading with outcomes rather than activities applies here just as much as it does in any sales process.
The provocative question Matthew raises — does RevOps still exist in five years? — is the kind of question that generates a lot of heat and not always much light. Marisol's answer is grounded and worth taking seriously.
Her argument: the nature of the requests that come to RevOps is changing, but the need for RevOps isn't going away — it's deepening. As AI agents handle the routine reporting and analysis that used to require someone to build a dashboard or pull a query, stakeholders will arrive at those answers faster and will immediately push for more. The questions that reach RevOps will be harder, not easier. That means the team needs to be more connected to the business, not less.
"Previously you would go to RevOps and say, 'Hey, what happened historically? What's going on with these conversion rates?' Now we're building agents and teaching them and training them and we're releasing these to our stakeholders so they're not having to come to us to ask those very simple questions. What's gonna happen is they're going to want even more detail, and they want us to be more connected to the business."
— Marisol Jordan
The Excel analogy she reaches for is instructive. When spreadsheets arrived, the people who learned to use them didn't become redundant — they became indispensable. The people who didn't learn became bottlenecks. AI is the same dynamic, compressed into a shorter timeline. Episode 86: Adapt or Die? RevOps in the Age of AI covers this transition in more depth and arrives at a similar conclusion from a different angle.
Marisol adds one more thing that often gets lost in the AI conversation: agents make mistakes, and catching those mistakes requires genuine business knowledge. If you don't understand the underlying motion well enough to recognize when an agent is producing a wrong or misleading output, you're not a governor of the AI layer — you're just a relay for it. The fundamentals don't change. Pipeline coverage, conversion rates, NDR, GDR, the financial statements that sit underneath all of it — those are the common language of business, and no amount of automation changes what they mean.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
Our average member has more than 5 years of RevOps experience. That means you’ll have real-time access to seasoned professionals. All we ask is that you’re generous with your knowledge in return.
