How to Build and Scale a RevOps Team

I began in sales, progressed into sales management and then moved into product management. Product teams knew their customers and cared about their products, yet they did not always understand sales and marketing needs. I became a bridge between those functions, which led to sales enablement and an opportunity to establish a team.

My interest in technology drew me into sales technology, CRM and their operational uses. That mix of commercial experience, cross-functional communication, enablement and technical curiosity led me to apply for a RevOps role. Over two years, I went from working alone to building a small team. This gave me direct experience recruiting talent and assessing the required mix of capabilities.

I see four connected pillars. Technology covers Salesforce administration, integrations and maintaining the stack. Analytics includes insight, Tableau, sound data structures and preparation for future needs. Enablement turns new processes, reports and Salesforce flows into adopted working practices. It also includes traditional sales and product training.

The fourth pillar is strategy, which sits with me and covers territories, quotas, direction and operational improvements. It connects the team’s work with company objectives. The pillars are enablement, analytics, tools and strategy, but they cannot operate as isolated specialties. Enablement helps technical and analytical work change behaviour across the commercial organisation.

Teams should acknowledge the tension between reactive and proactive work instead of treating it as failure. I use the idea of build and run, or a relay race that depends on a strong handover. Some people can focus on immediate operational issues while others plan ahead, but their work must connect. When everyone tackles an urgent technical problem, they risk overlooking the downstream effects of their changes.

A reactive group can have its own lead, while a longer-term group focuses on strategy and improvement. Their handover matters: incidents should inform future design, while strategic changes must become reliable daily operations. This model avoids constant firefighting, though the right structure depends on team size and business maturity.

Assigning one person to each region builds local relationships but creates risks. Coverage becomes fragile during absences, perceived capability gaps cause friction, and people can become isolated consultants. An outcome-based model gives people ownership of defined work, but it can create different silos.

Early-career team members can gain experience across marketing, sales and customer success operations before specialising. A rotation broadens their perspective, supported by experienced colleagues handling shorter- and longer-term needs. Resourcing remains a constraint because many teams are too small for the ideal structure. Leaders must balance specialisation with resilience and avoid confining junior employees before they build broad RevOps foundations.

Technical experience helps, but leaders can overvalue it. Extensive Salesforce knowledge cannot compensate for weak problem-solving, planning, organisation or communication. RevOps professionals often influence at VP level, so they must explain their position and secure stakeholder support. I avoid calling these soft skills because that suggests they matter less than technical capabilities.

For early-career hires, I prioritise evidence of problem-solving, communication and organisation. People can learn product skills through courses and practical use because modern platforms offer extensive guidance. Pragmatism also matters. RevOps must support innovation while protecting what works. That requires saying no, explaining why and respectfully challenging senior stakeholders when proposed changes introduce unnecessary risk.

Future RevOps professionals can work in roles they have never linked with the discipline. Marketing offers a different commercial perspective, while teachers often bring strong enablement skills. Travel agents also interpret customer signals, narrow complex choices, communicate well and coordinate interdependent bookings in demanding settings. Those capabilities transfer well.

Leaders should not recruit from one profession. Instead, they should seek evidence of problem-solving, communication and work ethic beyond established talent pools. Candidates without sales operations or RevOps experience can still have the capabilities to succeed. Openness to previous careers also expands the pipeline when organisations cannot rely on universities or established pathways to produce prepared RevOps specialists.

I use a break-even point: when a new employee gives the organisation as much value as they consume. New starters require support while learning systems, processes and context. The First 90 Days presents around 90 days as typical, but timing varies by company, industry, role and person. First-time RevOps employees can need longer, so rigid deadlines risk discarding the potential identified during recruitment.

Create quick, meaningful wins to accelerate progress. I gave one new starter a small task matching two data sets for a VP. He did not know how to complete it, but he sought help, learned and delivered within weeks. The task did not make him a developed RevOps professional, but it built confidence and demonstrated his contribution.

Agency support helps when a project creates a temporary demand spike. A CPQ rollout, for example, can consume substantial time across several internal roles. Focused support preserves capacity for daily work while giving the implementation dedicated attention. External specialists usually pursue a defined objective, bring experience from other businesses and question assumptions that established internal teams overlook.

For development, I use four elements: knowledge, skill, will and environment. Gain knowledge in suitable formats, then create opportunities to apply it. Public tools and self-directed projects can help when workplaces lack those opportunities; I used Tableau Public when publishing at work was unavailable. Communities offer motivation, focused questions and lessons from people who solved similar problems. No element works alone.