Great RevOps is boring RevOps

I recently watched a TED Talk by Professor Martin Gutmann (https://youtu.be/DU06c7f9fzc?si=OhhCklp6o5vUgsLl) about why we celebrate incompetent leaders. One of the areas of study he cited is how the best management is usually boring management. No drama; the business just performs day-in and day-out in a predictable manner. When fires come up, they are handled matter-of-factly and there are rarely self-inflicted fires. The leaders of these high-performing companies are rarely on TV, in the news, or on social media.

However, these great managers are usually not the ones set forth as examples of great leaders, because they are, well, boring. When you’re boring, there is no exciting story to tell. So instead, we celebrate leaders with exciting stories, even though often the excitement is a result of bad management.?

Professor Gutmann gave a great example contrasting two polar explorers, Ernest Shackleton and Roald Amundsen. Amundsen had an unparalleled list of polar exploration achievements, and he always did it on budget, on time, and with nearly no loss of life. On the other hand, Shackleton’s expeditions were one dumpster fire after another. While there are 4 books written about Amundsen, there are 26 books written about Shackleton, often celebrating Shackleton’s leadership and perseverance through challenges, even though most of his challenges were a result of his inability to plan and take feedback.

I think the same can be said about RevOps. The best RevOps teams are boring. This doesn’t mean their work is boring or the team members are boring. The best RevOps teams are boring in the eyes of their colleagues and management because they produce consistent and predictable results with no drama. I think these are the five essential practices of a boring RevOps team.

They plan and anticipate risk

One hallmark of boring is the absence of a steady diet of fire drills and all-hands-on-deck situations. We celebrate the leaders that can rally the troops, but we often don’t ask why there are so many fires to fight. For example, at this big software company I used to work at, there were a few product leaders that were praised consistently by senior management for their ability to “rise to the occasion” and manage customer escalations, but the executives never noticed that those teams had the most escalations because they consistently delivered poor quality products due to the dysfunction within their teams.

A boring RevOps team plans well and anticipates risk. They do a great job of minimizing fire drills and surprises by being detail-oriented and thoughtful. They manage stakeholder expectations and communicate changes promptly. Boring RevOps leaders do not fall into the trap of the action fallacy, where action is mistaken for productivity.

They build the foundation

It’s hard to have scalable RevOps without a solid foundation of technology and data. A bad foundation is the root of persistent fire drills and perennial overpromising and under-delivering. It is not trivial to ruthlessly prioritize and allocate the necessary resources to build out a solid foundation. Foundational work such as data quality is not glamorous and trendy, so it takes great discipline from the boring RevOps leader to make time to pay down the technical debt and data debt most companies inevitably accumulate along the way. This foundation-building work can take years to complete and needs to be kept up, so it takes strategic thinking, methodical planning, and dogged persistence to accomplish. Boring RevOps leaders know how to sell the value of doing foundational work and build support by delivering incremental milestones to demonstrate value creation in phases.

This is very similar to what a great product team does. Every software product builds up technical debt over time. Great product leaders make resources available to pay off this technical debt continuously so they never have to declare technical bankruptcy. This is why boring RevOps leaders often have much in common with boring product leaders.

They focus on enablement, not control

RevOps’ scope of responsibility continues to grow and the emergence of AI technology will further accelerate this growth. Much of the technical work that used to require engineering resources from IT would be doable by the RevOps team with the help of AI. Tasks that used to be economically infeasible can now be affordable with technologies like AI agents. As RevOps responsibilities grow, the boring RevOps team must continue to remove bottlenecks and friction points in revenue processes because those are the embers from which fires start. An overly centralized command-and-control operating model is a primary source of bottlenecks and friction.

RevOps teams have a tendency to become overreliant on a centralized model so they can have control over the processes and “do it right.” By doing the work for the stakeholders and turning the RevOps team into a helpdesk, the RevOps team becomes the bottleneck, introducing unnecessary interactions into revenue processes and fragility into the system. Boring RevOps teams invest time and technology to delegate tasks as close to the stakeholders as possible so they can self-service, minimizing unnecessary involvement by the RevOps team.

A common example is list loading. In most companies, marketing teams have to submit lists to the RevOps team for loading into the CRM or marketing automation platform. While this may be the easiest way for RevOps to ensure the quality of the list data, avoid the pain of retraining teams on manual processes, and prevent stakeholders from burning the house down using list loading tools designed for administrators, it also adds complexity and bottlenecks to the list loading process.

Instead of centralizing, boring RevOps teams build easy-to-use self-service apps using a data automation platform so the marketing teams can load their own lists anytime without constant hand-holding. For example, using Openprise, the ops team at Rimini Street was able to eliminate over 40 list loading and list building tickets a week by deploying self-service apps, which removed not just the repetitive tasks for the ops team, but also all the “excitement” that came with a single-point-of-failure, centralized support model.

They don’t take sides; they let the data speak

Sales and marketing leaders are rarely boring individuals. They have the stress of showing results every quarter building pipeline and closing business. In a tough business environment like SaaS has faced since 2022, this often leads to defensive behaviors or even finger-pointing among GTM teams. Figuring out what works and what doesn’t and attributing credit to the different teams that are responsible for building pipeline from inbound, outbound, channel, and product efforts can result in the RevOps team being caught up in the middle of a catfight.

RevOps plays a central role in removing the source of this drama and making GTM performance measurement and attribution boring. RevOps needs to own the data and the metrics as a nonpartisan trusted stakeholder, so all GTM functions can align on a single source of? shared truth and not waste effort creating their own data narrative while questioning the validity of the data from other teams. In order to establish RevOps as the trusted reporter of data and metrics, the boring RevOps team has to firmly establish itself as independent and nonpartisan, much like the Congressional Budget Office.

They avoid Shiny Toy Syndrome

RevOps can often be its own worst enemy when it comes to making RevOps boring. RevOps is often afflicted with Shiny Toy Syndrome, where they get distracted by the latest technologies and their lofty promises. Always buying the latest and greatest shiny toys means diverting resources away from the necessary foundational work, and further exacerbates tech debt and data debt by adding even more point solutions and point-to-point integrations. Justification for buying the shiny toy often involves making questionable promises to stakeholders that create further drama when the new toy under-delivers on the overpromised value.

A corollary to Shiny Toy Syndrome is My Toy Syndrome. This is when a new RevOps leader replaces the tech stack with what he is familiar with, sometimes not even bothering to learn about the existing tech stack, assuming that switching to familiar technologies can magically solve the broken issues with people, process, and data. This type of indiscriminate rip-and-replace inevitably makes the situation worse.

Both of these syndromes are examples of the action fallacy. The boring RevOps team does not confuse actions with results. They’re honest with themselves about how they can realistically leverage technologies, making sure they maximize the technologies they have, and disciplined about adding unproven technologies or making unnecessary changes.

Strive to build a Lexus, not a McLaren

RevOps is an exciting profession right now, with all the new technologies available and GTM leaders recognizing the importance of RevOps. RevOps is increasingly getting a seat at the table and beginning to influence GTM strategy and execution. To be a reliable and strategic partner to other GTM leaders, the RevOps team should strive to deliver value in as boring a way as possible. In other words, RevOps leaders should strive to build a RevOps machine that’s like a Lexus, not a McLaren. ??