RevOps Teams

What’s the Right Work for a RevOps Team?

Read More:

As operators, we struggle to find time to do innovative RevOps work while also keeping the business running smoothly. How do we determine what the right work is for a RevOps team?

The most common pain I hear from both day to day operators and leaders of RevOps teams is the constant feeling of being underwater. It’s not sustainable to run a team on urgent firefighting. Not only because our teams will burn out (no pun intended) but also because this team can’t get the important non-urgent work done (shout out to Eisenhower). 

So, how can we do innovative, revenue-impacting work while we are busy running the machine?

Why it’s hard

Often, operators fail to track our machine work. We don’t estimate or realize the amount of work that goes into maintaining our existing processes each quarter, and it only increases as we add more complexity. This can mean we get bogged down, spending so much time doing maintenance work, we end up with little to no bandwidth for anything else. 

Operators also have a tendency to treat every bug and issue as urgent. Yes, our GTM operating system will have bugs, but it’s important to accept that we likely won’t prioritize solving all of them. Otherwise, we’re spending our time enhancing workflows that are already ‘good enough’ when we could be doing more innovate work to move the business forward. 

The Work Categories


Machine Work:
This is the day-to-day work that exists for all businesses. Much of this ends up being maintenance of existing systems and processes, as well as the reactive work to address fires when they pop up. Some examples of machine work:

  • Consistent reporting (i.e. monthly or quarterly on lifecycle/activity/revenue/pipeline etc.)
  • Roadmap utility (e.g. keeping it updated and communicating it out)
  • Triaging incoming tickets from the GTM team
  • Managing/optimizing existing processes and tech (i.e. code refactoring, data cleanup)
  • Updating lead assignment logic as the business/personnel changes


Innovation Work:
We define this as work that’s net new to the org. This could mean new technology being implemented, or a new strategy or process being put in place. The major difference between innovation work and machine work is that innovation work is about creating a new workflow rather than updating an existing one. It also tends to be larger projects with a bigger emphasis on strategy and enablement for the org. Some examples of innovation work:

  • Automating renewal opportunity creation
  • Redefining our MQL/Scoring and handoff processes
  • Integrating Product with Salesforce
  • Designing a new intake process for initiatives and tickets


Things to consider 


Define your machine. Think about all the processes you go through on a daily, weekly, monthly, and quarterly basis (you can add annual, but I’d start with these first and then overlay annual on the quarters where it happens). Think about:

  • Key meetings (i.e. daily standup, weekly pipe review, monthly insights, and quarterly planning) 
  • Key reporting frequencies
  • Monitoring tasks (e.g. are there any checks your teams do to validate existing workflows or data health?) 
  • Incoming requests/tickets (e.g. do some historical reporting and see how many inbound requests we get from the field. Back of the napkin math is your friend
  • Operational optimization. These are changes we do to existing processes that will need administration throughout a time period. For example, updates to lead assignment for rep changes, rep onboarding tasks, deal desk management
  • Roadmap Utility

Plan your innovation work for the next few quarters.
These are typically your big rocks. Some questions to answer:

  • Any department growth with lots of new hires?
  • Will there be any new products rolling out?
  • What GTM strategies are we going to be testing out? Self-serve? PLG? ABM? Other hot topics?
  • Are there any new products you’ll be adopting?
  • Any new sales methodologies?

Design your team shape
The fact is, the people who can successfully manage the fires and maintenance of the business are going to have very different skillsets than those who want and are able to design and manage large strategic initiatives. Depending on the type of work your team is doing and your roadmap, you should design a very different team (seniority, kinds of meetings, communication, collaboration etc.)

You cannot hire junior salesforce admins if your work is primarily complex or if your more senior team members are not strong at delegating. You cannot run a team with senior resources who want to do innovative work if your work does not offer progression and it’s primarily fires. 

Why do all this work?

Besides this allowing you to build the right kind of team, this is your business case. As you advocate for more hires, you can show what it takes to run your team and innovate and create revenue impact. 

You can channel your inner Chris Voss and ask calibrating questions when negotiating for headcount. How am I supposed to innovate and create revenue impact when I have a team who is already tapped out running the machine?