What are the biggest surprises when going from a company where revenue operations was established to one where you have to establish revenue operations?

I think the biggest surprise is what you take for granted when rev ops is already an established function. The problems and decisions you make affect many more people at an established org - but they are very different in scope (instead of deciding accelerator percentage buckets on a comp plan, you’re thinking about how to pay people commissions in general or if accelerators should even exist). The decisions you make when establishing a rev ops function set a precedent that people will look back on months and years down the road (once you make a decision to add accelerators, it’s very hard to pull that back, for example). 

Also those decisions can be made relatively quickly and unilaterally when you are establishing the rev ops function (defining sales stages and exit criteria is much faster when it’s just you and a sales leader working on the spec, but that groundwork is extremely important and overhauling the process to just change a stage name for something different down the road is a lot of effort with little payback). So invest time in thinking about the future even when you can (and need to) move quickly. At the beginning, the scope of your role will be much wider but more shallow - you’ll be doing admin work in SFDC, helping marketing with a campaign list and a sales leader with territory planning - but then as the team and company grows, you’ll have specific people doing each of those functions going deeper than any one person could have when you were a team of one. 

The biggest surprises for me fall into two buckets, Ownership of RevOps Responsibilities and how Salesforce has been implemented.

1. Ownership of "RevOps" Responsibilities: One of the biggest surprises is discovering who currently owns the responsibilities that are typically managed by RevOps. In companies with an established RevOps function, these responsibilities are well-defined and centralized. However, in organizations without RevOps, various teams may take on these tasks based on their maturity and priorities. For instance:

   • In companies lacking strong enablement functions, you might find product marketing heavily involved in creating collateral and transferring information to go-to-market teams.

   • Without a centralized contracting team and deal desk, finance teams may handle these roles.

   Investigating and learning where these responsibilities have landed across the organization is crucial. While you may have some initial assumptions, there are often unexpected areas where different teams have taken on revops-related tasks.

2. Salesforce Implementation and Creativity: Another significant surprise can be the creative ways each organization implements and uses Salesforce. No two Salesforce instances are identical, and you'll encounter variations in:

   • Opportunity architecture and layouts.

   • User provisioning.

   • Integrations with adjacent systems.

   • Configuration of products and price books.

   • Reports and dashboards design and usage.

   Each organization adapts Salesforce to its specific needs and processes, which can be quite different from your previous experiences. Strike a balance between the existing practices and the best practices you aim to implement as the company grows.

Navigating these surprises requires a deep understanding of the organization's current state, which takes time and healthy dose of curiosity, a flexible approach to accommodate variations, and a clear vision for establishing revenue operations that align with the company's objectives and growth trajectory.

A few things come to mind for me when reading this, I've worked both at small and large companies. This is what I've noticed:

1. Scope: The scope of responsibilities is often narrower due to limited resources in a small company. Ex. could be you have enablement individual/team, process optimization focussed individual/team. At a large company may involve multiple teams, complex processes, and a broader range of functions, including various enablements teams, role specific operations (ie. marketing ops, sales ops, etc), go-to-market ops, etc.

2. Resources: Small companies typically have limited resources (ie. budget, personnel, tools, etc). Revenue ops in a small company will require individuals to wear multiple hats. You have less spots to delegate too also. So ruthless prioritization is always important regardless of company size...but extremely critical at a smaller company for this reason. In larger companies, there are more resources available to invest in specialized roles so these individuals can go deep in their craft and truly become a high level SME of their area. (ex. CS Ops individual can be aligned to a specific customer segment to focus on and therefore they can know the ins and outs of that space)

3. Cross-Functional Collaboration: In a small company, you should have close collaboration and coordination between different departments due to the smaller organizational structure. Communication and alignment between teams can be easier. In larger companies, you're dealing with more stakeholders and cross-functional teams...you're going to have to get in place more structured collaboration methods due to the volume/complexity at play.

4. Adaptability: With a small company you usually can be more agile. You can quickly respond to market changes, experiment with new strategies, and make adjustments based on feedback. With a large company on the other hand, you're going to have more established processes and structures, which can make it challenging to implement changes or adapt quickly...the ripple effects or dependencies on a change can span much wider.

5. Data: A large company typically has access to more extensive data sets and advanced analytics capabilities. You can leverage data-driven insights to make informed decisions and optimize revenue operations. In small companies, data may be limited, and analytics capabilities may be more basic. Establish what you can at a small one and just look at continuing to improve it. "Data is king".