In 2018, Salesforce made its $6.5 billion purchase of integration software company MuleSoft. Four years later, “we're still called the most successful acquisition in Salesforce history,” according to CEO Brent Hayward. The proof is in the numbers: Revenue from MuleSoft’s products and services is up five times since the acquisition, and head count has ballooned from 1,600 to over 4,200.
MuleSoft’s value lies in its integration software, which helps customers connect data, applications and systems across the cloud and on-premises. As vendors and applications proliferate in enterprises, the need for all those applications to work together is more crucial than ever. “The average enterprise has over 900 systems, but only 27% of them are actually integrated,” Hayward told Protocol in a recent interview.
Even MuleSoft, which is a leader in the integration space, had its own challenges integrating with the rest of the Salesforce ecosystem. MuleSoft’s product is complicated and requires deep technical understanding, which made the sales process a bit more tricky than Salesforce was used to and required some reorganization across the company. Then there was the difficulty of stitching together the slew of acquisitions Salesforce has made over the years, including Tableau and Slack, with MuleSoft’s own operations.
In a conversation with Protocol, Hayward discussed why Salesforce bought MuleSoft, how Salesforce is using MuleSoft to integrate its own systems and the advice he has for Tableau and Slack.
The following interview has been edited and condensed for clarity.
Why did Salesforce want MuleSoft? What did MuleSoft bring to Salesforce that it didn't already have?
If you were to look at Salesforce as it was getting more and more into multicloud deployments of CRM, there were sort of two principal reasons. I think, for a while, CRM could exist as a patch on top of the body, but not necessarily part of the central nervous system. When it was sales, we were engaging and interacting with other systems, but those systems were supporting and not core to what you had to go do. [But] when you start to get into service, where you're now getting into the back end and needing to understand [supply and inventory] or when you get into ecommerce, integrating into ERP and into the back end, you really can't do ecommerce effectively as a veneer on top of the customer, it gets all the way into the central nervous system of customer data.
Then as you start to integrate all those experiences, integration becomes a pretty critical success factor of delivering what a customer would now expect to be a fully seamless and fully connected [360-degree view]. I think that was really the primary reason. As we expanded in the market to CRM, this was becoming both a requirement, but without the capability internally, a bit of a threat, because we had to to leave it to the customer at the end of the day and not participate in one of these critical success factors.
Also, if you look across the customer landscape — we were acquired just over four years ago — this was probably the single greatest customer request, because getting data out of back-end systems and integrating these systems to have this very moderate engagement layer in Salesforce, it was difficult, and it was often the reason why these initiatives either would be delayed or in some cases fail.
Salesforce always listens to its customers, [and] its customer said, “Look, we need this capability, it’s one of the single greatest success factors for our program.” So that was really the background for the acquisition, and it's been very successful. I think we do more of what we call connected Customer 360 deals than we did pre-acquisition, where a customer like AT&T is buying an entire outcome and asking us to come in and not just provide the application layer, but all of the underlying connectivity unlocking that data as well.
How much does Salesforce use MuleSoft internally within Salesforce for integrations?
Quite a bit. One, we are adopted within Salesforce, so we call that initiative Salesforce on Salesforce. We went from an employee onboarding experience taking weeks to now literally taking a couple hours to provision an employee, give them all the assets they need and so on. So we actually use it internally, as our customers do externally, to connect our own capabilities across people, partners [and] customers.
CEO Brent HaywardPhoto: MuleSoft
But certainly one of our biggest initiatives since the acquisition … is connecting Customer 360. Quite a bit of work has gone into continuing to productize that connectivity. It was already strong when we were acquired, but because we can now do joint product management and joint engineering, we're able to come out with things we call accelerators: things that would take commerce cloud and allow you to connect to most back-end systems that are common, whether that's SAP or NetSuite or others. It can do about 80% of that work right out of the box, and then still leave it flexible enough that a customer can modify it for their specific process. We have over 17 accelerators that we've launched just in the last two years, and those are across almost every cloud. So we do them horizontally, but more and more we do them vertically. So our accelerator for health care and life sciences means that patient care, hospital systems and insurance providers can all connect to some pretty hairy back-end systems like Cerner and Epic, and do that using common out-of-the-box components, which then saves them thousands and thousands of development hours.
One thing talked about a lot in the industry is hyperautomation. MuleSoft has some new automation and integration features that it just released. What is hyperautomation to MuleSoft and Salesforce, and why is it important to where enterprise companies are going?
It's a new term for sure, or at least in the last 18 months to two years. But I think it's actually a very logical aggregation of a lot of capabilities that we've been seeing over the last few years.
IT has been using the word integration for years. We think of integration as both that core connectivity that I talked about but also modern-day integration as full life cycle API management. Our customers use the word automation because that most applies to how they think about the outcome. IT thinks about integrating data and integrating systems and processes, that's their version of automation. Business users largely think about automating work or the work tasks, the process flows that are required in order to take repetitive steps out of their job.
I think there's a convergence happening right now, which is why we see this uber category of hyperautomation coming up, and a lot of that is driven by the industry. It's hard to find an RPA company that isn't also expanding into things like iPaaS or expanding into low-code/no-code integration tooling. And that's because there [are] just logical limits to solving automation problems with only RPA, just like there [are] logical limitations of solving automation problems with only heavy high-code development products.
When you look at the underlying drivers of hyperautomation, you really need to be able to integrate to be able to automate: That's a real strength of ours. You need to be able to use full life cycle API management to be able to automate, that's another strength of ours. We were No. 1 in both of those markets.
What our customers were saying were two things: One, we really want to extend these capabilities to our business audience. That comes from a place of, “I don't think we're going to develop our way out of the automation challenge, it's going to require more than just the 20 million available developers in the world, it's going to require us to tap into the 22 million Trailblazers across Salesforce, maybe a billion-plus knowledge workers and actually give them the tools that they would need with no code to be able to do some of this lightweight automation and some of this lightweight integration.”
A lot of this is about people, and then a lot of this is about the final mile of connectivity. The purists in technology want everything to be a beautifully formed API or microservice that can be reusable and callable. We want that too, and part of what we do for our customers is make them more composable, reusable, speed up development [and] reduce the amount of maintenance. But the reality is there's so many different systems — the average enterprise has over 900 systems — but only 27% of them are actually integrated. So it means that there's a lot of systems downstream that IT will never get to. So can we provide the tools to also extract some of the data and make that reusable and make that a building block for more composable processes?
What was the process for MuleSoft becoming a part of Salesforce, because integrations are really challenging with acquisitions?
It’s my third one. I would say this one has been the most successful. I think there's three keys: The first one is culture. Fortunately, [at] Salesforce we have a policy that says if it's not a cultural fit, maybe we don't share similar values, we just don't move forward. We tend to buy the whole company: We want the people, we have the technology, we want to scale. So we were incredibly aligned Day One in terms of our values and what we were trying to build. We were trying to build a sustainable business that would be here long after many of us were gone. What was neat was when you have the same values, you start to appreciate that they were achieving things at a level of scale that we were hoping to achieve, and so it gave us a bit of a guidepost. So culture is No. 1.
I think the second one is, we worked really hard to have a very narrow but specific scope in the first couple of years. Our scope was really twofold; we had a clear plan. One was, how do we get this into the hands of almost 10,000 additional sellers, because from a distribution perspective, it was just an incredible opportunity to get that out there. And then you couple that with … if we see massive distribution, we better nail the scale part of our proposition. So we poured a lot of time and energy into scaling distribution, and then scaling the service to make sure it can hold up to the same level of trust and scale that we were known for pre-acquisition.
And then typically in our go-to-market there's been more of an alignment. In the last year — and it's not without bumps along the way as you're scaling 30 and 40% a year, and I talked about employee growth — it's probably one of the biggest challenges to continue to keep turning on, enabling and getting those new folks productive.
But we also aligned by industry. And I think that was really important. I think the language of the Salesforce customer is now by industry. And we went from largely geographic-based, north south, east, west of the U.S. [and] country-level in Europe, to much more of an industry focus. I'm glad we did it, even though it's painful to go through those kinds of large reorganizations in a 1,500 to 2,000 person distribution organization. But it's really done two things. One, it's allowed us to speak the language of the customer. We provided a horizontal capability; now we can provide that capability very specifically to financial services or manufacturing or downstream oil processing or travel transport. Second, that's the same language our Salesforce counterparts speak. So it's letting us serve the customer, whether that's from helping them understand our products all the way through the long tail of success and delivery and best practice. It's helping us all align our expertise around that industry proposition.
The short of it is, I think we had a really good game plan, and they don't always go perfectly, but you take good potential, good cultural leadership and a really good game plan and I think we've so far had a pretty good outcome. We're still called the most successful acquisition in Salesforce history. And we've learned a lot. I talk a lot with Tableau and I talk a lot with Slack about how to also take advantage of what we learned just coming 12 months and 24 [months before them], respectively.
You mentioned passing on some lessons to Tableau and Slack. What are some of the things you've learned that you shared with them?
The biggest one for me was whatever you’re thinking in terms of scale, double [it] — double your wildest idea in terms of scale. I didn't have to do that much with [Slack CEO Stewart Butterfield] because Stewart was already selling, with Slack, almost consumer-grade technology. They were exploding in terms of users. Tableau had a large user base too, but just the sheer volume of adoption and consumption, it was just sort of like, plan for scale, it will happen. That was probably the biggest one.
Then on the second side, planning for employee scale. Even though all three of us were reasonably large companies — we were a quarter-million dollars in revenue at the time, well over 1,000 employees and I think both Tableau and Slack were over those marks as well — it’s a 75,000 person, $25 billion organization. And so you have to be able to make sure that we're not just scaling our processes and our technology, but we're also able to provide the coverage and the capability, and it takes a lot of hiring. Any best hiring plan you've ever had: Tear it up. I mean, the last six quarters we have averaged a greater quarterly hiring than in years combined.
