Cleaning up tech debt on MT SAAS: A conversation with Salto’s Gil Hoffer
One unintended consequence from the remarkable rise in SaaS is the amount of tech stack debris.
During the pandemic, climbers removed 2.2 tons of trash from Everest base camp and its surrounding environs. It’s a reminder that our own Himalayan range—some of MT. SAAS and the thousands of core business applications out there—also needs cleaning.
There’s so much great SaaS empowering businesses, but they pose the added challenge of monitoring, controlling, and connecting them. Many tech stacks are littered with the accumulated detritus of years of inherited configurations, stairs-to-nowhere integrations, papered-over-problems, on-premise thinking, and of course, tech debt. This is more than an issue of aesthetics. These problems clog mission-critical systems, impeding the core internal business processes and revenue operations that must be more responsive and streamlined in order to keep pace with modern business pace.
But what if things were different? To get these answers, I sat down with Gil Hoffer, Co-Founder and CTO of Salto, a Bessemer portfolio company. In this conversation, Gil shares the five best practices for business application management, and how to clean up these systems—large and small.
Top takeaways on business application management
- Recognize cross-app clutter as one unified problem (and your business applications as one product)
- Clean continuously and treat it as an engineering profession
- Build for consistent cross-application configuration and measurement
- Use your tech debt as a tool
- Recognize the career trajectory and the critical role business application management plays in a SaaS organization—no matter the size.
SaaS has won, but now we need to manage business application sprawl
The biggest change I see in how companies manage their SaaS is that the “best-of-breed” approach, where each line of business selects its own systems, has won. IT is no longer the sole gatekeeper of who buys new software and companies today have, on average, 800 SaaS applications.
“This is a good thing. It allows each of those lines of business to be their most efficient. And it’s made possible because each system has its own UI where people who can’t code nevertheless act as developers,” Gil explains to me. “Those business system managers and administrators customize their business applications so heavily they’re essentially building products within them, and between them. For instance, a quote-to-cash pipeline that spans the CRM and ERP. Or a hire-to-retire pathway through all HR systems.”
What’s really remarkable here is what used to take dozens or hundreds of developers can now be done by one person. But it also introduced a new kind of complexity, says Gil.
“If you have hundreds of business applications each operated by different groups, you have a highly distributed system, and today, there isn’t a lot of central awareness or control. If you want them to all function and keep the data accurate, you’d need new tools and methods for managing distributed systems. And that isn’t really happening for most companies.”
Below MT SAAS there’s a whole range of summits that need management
When we talk about “MT SAAS,” we’re of course referring to the leading cloud companies such as Salesforce, Shopify, and Adobe. All these companies have transformed the industry. But when you actually look at the face of the business applications industry today, these are the summits, but “there’s also an entire range of hundreds or thousands of other SaaS companies that are also mission-critical,” says Gil.
The real challenge is every one of those summits is different. Each has its own interface, data models, schema, and terminology, and that makes it very difficult to attempt a cleanup. Teams need the right tooling to climb that mountain and implement a business process. You need to strategize what your entire organization needs, and then you need to apply it to each application and you need to do it continuously.
What’s more, each of those mountains are constantly changing. “Just like real geography, everything in business applications is in motion. Slow motion, but in motion,” Gil tells me. “Each software is updating and improving. And the question is, given that we’re likely only going to have more SaaS to manage, how do you do all that? That’s what modern business applications teams are wrestling with.”
Business applications teams can learn from DevOps
I think it’s helpful to be very clear about what the “trash” is in our mountain analogy, when talking about litter atop MT SAAS—it’s the technical debt in the form of half-finished decisions, unplanned configuration changes, new custom objects, missing metadata, settings nobody else knows about, or just a lack of documentation. It’s the reason that when a sales leader asks their CRM administrator why a report is down, or why a field isn’t showing, it can take weeks or months to figure out the answer.
Gil believes business applications teams can learn a lot from how software developers operate. They have been working on philosophies, methodologies, frameworks, and systems to deal with these sorts of issues for 60 years, in some cases. The first version control software was launched in 1962. “Today there are services like GitHub, GitLab, and BitBucket that allow many developers to coordinate work on one piece of code, branching off, editing, merging, and submitting pull requests. Or to maintain multiple versions of a system to debut and test before things reach production.”
But most business systems administrators don’t have that. “Today, business applications teams working out of the UI of all these systems don’t have all that stuff, but they really need it. Without it,” in Gil’s words, “the ‘trash’ just accumulates.”
The cost of chaos in business apps is that the entire organization functions less efficiently
With this in mind, Gil shares a few stories with me that are emblematic of the accumulating tech debris: “It’s Thursday night at the end of the quarter and a team realizes their ERP simply stopped working, and they’re stuck. So the entire team works the entire weekend just to figure out that someone made a change somewhere that they weren’t supposed to, but because the ERP doesn’t log changes like that, there was no way of knowing.”
He shares another example: Someone gets a call from their boss, who got a call from their boss, because the CEO called about a broken dashboard. What they soon learned was that because somebody somewhere changed a field without knowing certain dependencies there was a chain reaction that had to be undone.
Or here’s a devastating one: A company realized its demo requests for the past few months weren’t being assigned to the sales team and lost out on millions of dollars of pipeline.
“In truth, the costs of errors in business applications are larger than they are in the product, or software development, because there aren’t as many safeguards,” Gil shares. “The product has all sorts of tools to test and rollback; it’s much more resilient.”
To be more like software teams, business applications teams have to start thinking of all those applications as one united product, and themselves, product managers.
Ultimately, this is everybody’s responsibility, but it really falls on those business applications teams. If you think about climbing Mt. Everest, it’s up to every person who climbs to pick up their trash, and if they find trash, take it with them. This is all the administrators, developers, and architects who work on those applications.
Business application management is complex and there is no one right approach
There are just so many facets to the challenge of maintaining and scaling business applications. For example, with many business applications, how do you keep your data in sync? How do you build a process which works across those different business applications?
As we often explore at Bessemer, and as Gil explains, CTOs and CIOs are seeing some great companies right now that deal with that. There’s integrators like Zapier, there’s Workato which helps you build cross-business application processes and automations, and then there’s Slack or Teams, and Jira or ServiceNow, which create a central hub for these conversations.
"Managing business applications is where managing infrastructure was 10-15 years ago."
And then you’ve got your companies like BetterCloud and Torii that help with managing the cost of these business applications, which can get out of hand quickly, just because of the multiplication of thousands of users in hundreds of applications.
“Managing business applications is where managing infrastructure was 10-15 years ago, and where HashiCorp and Terraform help today,” Gil says. “I think that’s a highly relevant domain for the team here at Salto to be learning from as we work on making business applications more manageable.”
Technical debt is a tool: Use it to your advantage
In my conversations with Gil since 2019, when we made our first investment in Salto, I’ve reframed my perspective and realize there’s something missing from the “tech debt” conversation—the idea that debt is sometimes desirable and exists for a reason.
“Just like financial debt, it’s a tool,” says Gil. “You knowingly create debt when things are urgent and you have to move faster in one area, and you know you’ll have to return to pay it off.”
That’s the nature of growing a business. You’re going to pay interest on those decisions, but sometimes it’s essential to make them to achieve your goals and scale. “The challenge is managing your debt and keeping it down to a manageable level,” Gil continues. “And that’s why it has to be a continuous practice, and something you get your arms around early.”
From mindset to methodology: careers in business application management are on the rise
“The way I see it, you need to treat a career in business apps as an engineering profession,” Gil tells me. “Just as an engineer takes pride in building the product, so too can those who manage business applications, all from a first-principles approach. Business applications, after all, help the entire business run and require systems-minded people.”
This mindset, and all the software management practices that come with it, is the key to any model company’s success. Business application management is starting to become a practice people talk about and prepare for. It requires the right team, the right talent, the right skill sets, the right motivation, and of course, the right technology, much of it borrowed from what’s already happened in DevOps. We saw the rise of developer boot camps in the 2010s, and soon, we expect to see boot camps dedicated for people pursuing careers in business application management.
As organizations of all sizes—from emerging startups to the members of MT. SAAS—begin to address how to clean up their business application environment, they’ll begin to realize there’s no single approach. The work requires more sophisticated understanding and sometimes, finesse. Each organization is going to need different things at each stage and have different requirements.
“The best thing a leader can do is empower the business applications team to treat it like a product,” Gil says. “This is how the most successful companies treat application management, as they strive to scale to their next summit.”