Everything Not Directly Related to Revenue Generation Must Go

Assessing and mitigating the impact of tech debt on the modern RevOps tech stack

Tech debt is something that has been around forever, or at least as long as there has been tech, but up until recently, it was mostly an IT or engineering problem. The issue usually was some custom code or feature affecting system functionality or speed, and it was up to IT or the “developer” to root cause and fix it. Fast forward a few years, and now tech debt is everywhere and every business user’s problem, especially if they’re involved with revenue operations.

How this came to be and what users in sales, marketing, and revenue operations can do about it was the subject of a new and fascinating webinar hosted by Openprise featuring two industry leaders with years of experience dealing with tech debt and its fallout for revenue operations.

The origins of the modern tech debt problem

For one of the speakers, Charlotte LaViolette, now Customer Success Director at Openprise, the issues and concerns around managing tech debt were brought into focus around the time Salesforce first introduced its new Lightning platform. For 20 years, her clients happily developed custom features using Salesforce’s proprietary Apex programming language, but then Lightning, with all of its out-of-the-box capabilities, was introduced, and everything changed. Her clients struggled with the new paradigm, and some spent years trying to migrate their Classic instances and code to the new platform and missed out on all the fantastic and productive features in the interim.

Co-presenter Tony Tarantino, now Chief Architect at Hyperscayle, an Openprise partner, experienced something similar in his practice as a long-time CRM and Salesforce consultant. For him, the broader issues his clients encountered mirror those facing many today. These go beyond the practical problems that the tech debt is causing at the moment and are actually limiting what they can plan for and accomplish tomorrow and the next day.

Apex and its corollary in the proliferation of MarTech tools

The proliferation of custom Apex code didn’t just come out of nowhere. Its power and usefulness were immediately self-evident, and businesses took advantage of it to solve real problems. No one intended for the code they wrote to break, become incompatible, conflict with other programs and systems, or prevent them or their successors from innovating or solving new problems. They didn’t plan for it. It just happened over time, which brings us to today.

The rise and arc of Apex have a strong corollary in the biggest contributor to tech debt today: the growth of the MarTech stack. As Charlotte and Tony note in the program, in roughly ten years, the number of MarTech tools on the market has gone from a few hundred to 10,000. For years, point solutions were touted as the panacea for any and everything vexing marketing and sales operations, from data enrichment to lead scoring and routing.

As charted by Scott Brinker on the Chiefmartech blog, over the last 10+ years, the number of MarTech tools has increased exponentially.

As both speakers couldn’t stress enough, the problem is that in most cases, these solutions were purchased and implemented to solve an immediate need without much thought or planning of how they would affect their systems or ability to operate in the future. As a result, the typical RevOps stack today has multiple upon multiple point solutions, many with similar capabilities, competing with the CRM and one another for the same compute and processing resources.

The symptoms of tech debt are everywhere

Basically, in the rush to knock over today’s molehills, we built the foundation for tomorrow’s mountain, and the telltale signs aren’t pretty. These include myriad issues that divert time and resources from the really important work, which is generating MORE leads and revenue. Some of the most common are:

• Sync delays between your CRM and marketing automation system that can turn hot leads into cold frustration
• Contact or account records with 10 to15 different field names for essentially the same property, such as country
• Race conditions that cause fields to update unexpectedly and erroneously

Putting process ahead of technology

How we got here is important, but only if we learn something from the journey. There’s a reason the famous quote attributed to Einstein, “…insanity is doing the same thing over and over again and expecting a different result,” resonates. The days of bottomless marketing and sales ops budgets are over, but even if they weren’t, the practice of indiscriminately adding point solution on top of point solution should have ended long before now.

Both Charlotte and Tony are realists and have been around long enough to know that tech debt isn’t going anywhere. As long as there is tech, there will be tech debt, so the practical objective is not eliminating it but mitigating and reducing it down to a manageable level. This brings us to the critical insight of the talk: that business users in RevOps need to be much more intentional and strategic about the technology they buy and add to their systems.

We live in a new world of data and tech democracy, where no-code solutions give business users endless, easy options, but often the best option is not to choose any of them. One of the biggest mistakes both Tony and Charlotte see RevOps teams make is thinking that a new tech tool will magically solve a process or people problem that has nothing to do with technology. Tony calls this the “shiny object syndrome” and counsels clients to avoid it at all costs. If there’s a chorus for Tony’s and Charlotte’s talk, it’s that the process has to precede the tool.

Solving tech debt one tool at a time

This refrain extends to the solution as well. Today’s RevOps stack may look like a tangled mess of disconnected apps and point solutions, but behind every one of those tools was a job, process, or problem that needed to be solved. The first step to untangling it all is inventorying and understanding what each of those is, prioritizing the most important, and making a plan to remove or disable everything that isn’t essential. You can’t flick a switch and wishfully mitigate and effectively manage tech debt overnight. It’s a project for the long haul, which, to be successful, has to be done collaboratively with all the teams involved and with full end-to-end alignment.

Getting started

For those interested in learning more about tech debt and how RevOps leaders can start to assess and address it in their systems, Charlotte and Tony’s talk is now available on demand.

Recommended resources