Building a revenue operations group from the ground up is exciting. Creating a revenue operations organization in a previously siloed organization is also exciting, but it presents some challenges.
Typically, department growth is shaped by an organization’s current need, immediate strategy, and budget constraints. We also need to acknowledge that an organization’s culture heavily influences the shape revenue operations will take.
Who does revenue operations report to? Are they reporting to a silo, the CFO, a COO, or CRO? (For recommendations on where revenue operations should report, check out this article.) How aligned are sales, marketing, and customer success?
This article will discuss practical limitations that influence revenue operations department structure and the ideal Rev Ops org structure barring external influences.
There are still articles being produced to justify marketing operations, sales operations, and customer success operations. As someone who has been in operations for over fifteen years, I’m saddened but not surprised. There are nearly as many articles featuring professionals lamenting the fact that operations is often an afterthought.
These two facts are very related. If someone needs a justification to hire an operations professional, they don’t yet see much value in the role.
When I look at how many of my colleagues are overworked and burned out, this lack of understanding manifests as:
I suspect the traditional reporting structure for operations functions reflects the “operations is an afterthought” mentality, although I will say that there are benefits to being embedded in an organization. You’ll acquire a depth of business knowledge, empathy for the people you’re supporting, and context when trying to solve for unusual reporting results.
The obvious drawback to this structure is the department head’s lack of knowledge about what it takes to be a systems architect or analyst or applications manager, which puts them in a poor position to properly manage and support these roles. This issue is often compounded by a VP’s obligation to meet a quota, satisfaction score, or lead acquisition goal, putting operations on the lower half of their list of priorities.
When an organization is first moving from siloed operations functions to a revenue operations department, the temptation is to keep the people siloed by the departments they support under a single manager.
If the department head holds regular “cross-functional” meetings (and they usually do), the siloes are reduced. The siloes diminish further after teams begin to quarrel. We’ve all seen it happen, but I’ll give a few examples of things that kicked off some severe infighting:
I’ve rarely seen intentional sabotage take place (but I have seen it). Usually, people have the best of intentions when they set out to perform a task. In response, operations leaders do what they do best and put communication procedures in place. They begin requiring people in similar functions across siloes to meet regularly to share what they are working on.
Resolving communication issues is more straightforward if people are managed by function. It’s also easier to find managers who understand the fundamentals of every role on their team, even if they have not been in a specific position.
It’s hard to find a data analyst who also understands system architecture and vice versa. Hiring a manager who has been a systems architect to manage the people who oversee the systems just makes sense. It also makes sense to have a person with a strong background in reporting and KPI management to lead a team of analysts.
Hiring a manager with a background in the functional area means they understand the core competencies needed to be good at the positions reporting to them and know the investments that should be made to support those positions (technology, headcount, continued education, etc.).
However, there is a drawback to this structure that must be mitigated. Suppose people aren’t brought together by a project manager and operations analyst who understand how systems and people intersect. In that case, you run the risk of specialists developing systems and reports in a new kind of silo. This silo lacks business context and insight into what people need versus what they’re asking for. The tendency can also be to develop the most efficient system instead of what is right for the end-user.
Make sure you balance your team out by having cross-functional positions oversee the work being done or, at the very least, a feedback mechanism for the departments you support.
In my experience, one of the later functions to move into the revenue operations purview as a company matures is revenue enablement.
Revenue enablement strays from the process and systems-oriented mindset that is typically seen in ops. Enablement is equal parts content creation, adult learning methods, and technology translator.
Enablement can bring a great deal of value to revenue operations. They often come to the table later in the game because it’s often one of the functions that department leaders are reluctant to give up. They know the job, see what works, and believe they know how things should always be done.
True enablement professionals have a background in adult learning methodology. They know how quickly they need to capture their audience’s attention and how best to hold it. They agonize over content delivery and onboarding plans.
They also see things from the perspective of people in the departments revenue operations supports, and they’re often trusted confidants. They are a tremendous resource if you want to know which parts of the systems people hate to use, what takes people too long to do, and what isn’t intuitive for end-users to grasp.
Enablement is also a great gateway to introducing department heads to reports. If your enablement guru uses a report method to identify people who need coaching and this aligns with the manager’s insights, they’ll want to start using the reports too.
If I didn’t have to worry about budget constraints, the organization I would build for a B2B company would look something like this:
People would be managed by functional area. Multiple personnel are dedicated to managing projects and cross-functional analysts to ensure team members aren’t disrupting one another’s work (or making life more challenging for a department they aren’t directly supporting).
In my dream scenario, systems and insights groups would use agile development methodologies and use an appropriate project management tool. They would meet as groups regularly, give the team updates on what they’re working on and what they have scheduled. This allows team members to raise a flag if their system may be impacted.
If I'm getting aspirational (and you know that's happening)... Once a week, there would be a required brown bag lunch where one team talks through their past month's major findings. This is also a cross-functional project manager leading major implementations, report design, process overhauls, and curriculum rollout.
And because I'm a dreamer, team members are required to do one "ride-along" per quarter with the organization they're currently supporting. For example, a CRM admin silently observes an SDR do their job for two hours to better appreciate the difficulty of the SDR's position and the number of steps they must go through in systems to do their job.
Do you have feedback? Opinions? We’d love to hear if you’ve had success with a different department structure or any pitfalls we may have missed of the department hierarchies we’ve listed above.
