Good morning,
One of the recurring questions over the years that I have written Stratechery is why I don’t write more about startups (a related question on Twitter is where is the Stratechery of startups). The answer is pretty straightforward: I am an analyst, not a reporter, and there is a lot more information publicly available about public companies; information about startups is much harder to come by, and often unverifiable when you get it.
At the same time, I do regularly come across companies that are very intriguing to me, particularly in the context of the themes that I write about, and I want to learn more — and share those learnings with you. That is the context for a new type of interview I am launching on Stratechery: startup founders.
The idea is this: I sit down with a founder with the goal of learning more about their business and the opportunity that they are pursuing. Instead of objective analysis this is as subjective as it gets — of course founders are optimistic about their future possibilities — but that feels like the right approach to expanding coverage to companies that I feel constrained in writing about. I’ve had a couple of these conversations already, and have found them tremendously interesting; I hope you feel the same.
An Interview With Rippling Founder Parker Conrad
Here is how Rippling describes itself on its LinkedIn profile:
Rippling is the first way for businesses to manage all of their HR & IT — payroll, benefits, computers, apps, and more — in one unified workforce platform.
By connecting every workforce system to a single source of truth for employee data, businesses can automate all of the manual work they normally need to do to make employee changes. Take onboarding, for example. With Rippling, you can just click a button and set up a new employees’ payroll, health insurance, work computer, and third-party apps — like Slack, Zoom, and Office 365 — all within 90 seconds.
Based in San Francisco, CA, Rippling has raised $450M from the world’s top investors—including Kleiner Perkins, Founders Fund, and Sequoia—and was named one of America’s best startup employers by Forbes (#12 out of 500) and the fastest-growing private company in the Bay Area by the San Francisco Business Times.
For years I have wondered what company in Silicon Valley would have the vision to challenge Microsoft in the enterprise space, given that Redmond was consistently beating would-be challengers with not only its superior distribution, but also a wholistic view of a company’s IT needs that was more appealing than best-of-breed-but-silo’ed SaaS apps that worked well on their own, but not so well with every other enterprise app. Founder Parker Conrad paints a vision that starts with being the source-of-truth for everything employee-related in a company, and extends that to a future where Rippling is a one-stop shop for employers that is impressive in its breadth, not just it depth.
As a reminder, the Daily Update Podcast is particularly useful for interviews, even if you are generally a reader.
On to the interview.
This interview has been lightly edited for clarity.
Parker, welcome to the first edition of a series of podcasts that I want to do about out some startups, and I have to give full disclosure to our audience that this is not the first time we have talked. In fact, our conversation was the inspiration to do this series.
Parker Conrad: Oh, wow!
Well, one of the challenges I have with Stratechery is because I’m not a reporter, I’m an analyst, I end up with focusing a lot on public companies because there is publicly available information. People ask, “Well, where is the Stratechery of startups?” and one of my answers always is, “Well, that information isn’t out there. There isn’t the public disclosures that there are for other companies.” But I’d like to do more, and I was talking to you a few weeks ago and I find Rippling so interesting. This is a company I want to talk about, but I don’t have the usual information I do for a public company, so I decided to go straight to the source.
So this isn’t analysis, you’re going to get a chance to pitch me and sell your idea. It might be right, it might be wrong, but I just felt like this is a great format, I can dig in directly into what you’re doing. You can tell me what you think, there’s not going to be numbers per se, but I just think it’s really interesting to me what you’re doing and for me, I think an interesting model for what I can do going forward. That was a long preamble, but thank you for our conversation a few weeks ago and thanks for joining today.
PC: Yeah, of course. Thanks for having me.
It’s interesting, when I first heard about Rippling, my natural thought was to think of Zenefits, your previous startup, which was focused on employer health plans, Rippling is focused on employees. It’s like, “Wow, Parker really loves the health plan space.” Is that the wrong framing? Because I’d imagine I’m not the only person to think of Rippling like this. What’s your pitch on Rippling and why is it actually something new and different?
PC: Rippling is fundamentally about employee data and the importance that employee data plays in the basic operations of almost every business. The central insight behind the company is that employee data is a lot more distributed across the organization than most people realize. Most people when you think of employee data, you immediately think HR department and HR business systems and I think that is wrong. I think that almost every business system that companies use is full of information about employees and that creates problem that we can solve and then a separate secondary opportunity.
The problem that it creates is that all of these systems, the employee data in all of these different business systems needs to be maintained and updated by hand. The way companies see this is, every time they hire someone, they need to add them to a bunch of different business systems and when things change about an employee, a subset or maybe even all of those different systems are implicated. You need to update someone’s manager, sometimes their compensation, their department. There are a series of policies that might apply or that might not apply to them based on changes in role, and at some point of course, if they leave, you have to remove them everywhere all at once. I think that that fundamental problem of employee data is the root of most of the irreducible administrative work involved in running a company. Rippling solves that because it gives you one place where your company and your employees can go to make changes that then handles the propagation out to everything else.
So it creates this secondary opportunity, which is that most business software vendors are aware of this dynamic and they know that the more information they ask for about your employees and about your company, the harder it is to use their system. The more upfront work it requires to implement it, the more ongoing administrative hassle it is to run it, and so most of them tend to be pretty reticent to ask you for a lot of that stuff.
That in turn leads to this situation that most business software out there knows a lot less about your employees and your organization than it ought to know. You see this in a lot of different places because any business system with a concept of approvals or alerts or workflow, which is just very common primitives that you would see in business software, any system with an alert or an approval in a workflow involves some concept of routing. That routing almost always needs to be based on relationships between employees that you have. You need approval from your manager or from the VP of your department or your HR VP, and who that person is depends on who you are and where you sit within the organization. The rules and the guidelines for how these approvals work would be a lot less brittle if they could be written or explained in terms of these relationships rather than hard coded between discrete individuals.
It’s the same thing with any business system with a concept of a policy or permissions; those things are almost always ultimately about your role within a company and what your job and function is. That’s what determines whether you get certain types of access, a certain type of configuration within a system, and again, if that could be based on your actual role in the company rather than based on heuristics and hard coded lists of individuals, it would make all of this a lot better.
A lot of data analytics that you do across different business systems would be a lot more powerful if that data was joined back to the employee record so that you could analyze things based on someone’s department, manager, work location, team, and in fact, I think the first step for a lot of data analysts when they’re pulling business systems data is to join it back with a lot of employee information and organizational data so that they can do those kinds of analysis.
Is the most important piece of data here the organizational structure then? Who’s your manager, who’s on your team? That’s the bit you keep coming back to, or are there other pieces of data that matter as well?
PC: It’s all of the employee attributes. It’s not just the org chart, so it’s not just the reporting hierarchy. It’ll be things like, what teams are you on? We have a reporting hierarchy within Rippling, your department might be Engineering, you report up through Engineering, but you’re on our Payroll team for our payroll product. There are engineers on our Payroll team, there are support people on our Payroll team, there are product managers on our Payroll team all in different departments and with different reporting hierarchies, but the fact that they’re on that team is really important. It matters whether you’re full-time or part-time, whether you’re a contractor or a W2 employee. All of these things end up being really important for a lot of different choices around systems access and configuration and permissions and approvals and all of those things.
When you talk about all this, it sounds like a directory, which makes me think of Active Directory, which has always been a fundamental piece of the Microsoft enterprise offering. I think it’s one of the most interesting pieces of software because it was free, yet it was the linchpin for this entire system that Microsoft had. Is that a good analogy to what you’re trying to do? Or is this something different from that?
PC: Yeah, I think that’s exactly right. I think there are some critical differences and one is, we like to think of this information in terms of a graph rather than a directory, and I’ll talk a little bit more about what I mean by that in a second. The other big difference is that in practice, Active Directory and a lot of these identity systems more broadly tend to be actually — they call themselves identity, but what they actually are is authentication, it’s for the most part usernames and passwords. But if you went to the original meaning of that word identity, what is an employee’s identity? What you would think of are the HR attributes, the role attributes. What is this person’s job and role and function? What’s their employment type? Who’s their manager? What’s their work location? What country are they in? Those are the things that actually drive when you federate these other business systems back to Active Directory. Those are the attributes that actually really matter for all of this downstream functionality in these different systems. Not just systems access, but also policies and permissions and configuration within those systems. It matters for, like we were discussing workflow and approvals and alerts within those systems, for reporting and analytics for the data within those systems. That’s important information that really changes what’s available to you in all of these different downstream products.
How does Rippling actually manage to interact with all these systems? Is this going to be a massive thing where you have to build partnerships with all these different companies? How do you actually achieve this level of integration that you’re hoping to achieve? If the problem is there’s all these disparate systems, is it just a brute force thing? I think a company you might think of when you talk about identity or authentication is Okta and I think one of the brilliant things Okta did was they just literally by hand built integrations with basically everything, it was a brute force effort. Is that more along the lines of what you’re doing, or what’s the distinction there?
PC: So we do two things. One is that we build integrations with a lot of different third parties and those integrations are basically to do user management: to provision and deprovision users, to manage configuration and policies and groups within that system based on the role data inside of Rippling, and then lastly, to pull in the data from that service. We pull in all kinds of data from these third party systems that’s then available in this employee graph inside of Rippling. You can pull in your Zendesk tickets, your GitHub pull requests, and then you can build reports or workflows or even policies and rules engines based on employees outstanding Zendesk tickets or their most recent GitHub pull request or something like that.
I guess the question here is, this is a very interesting vision, and one of the reasons why I’m so intrigued by Rippling is I’ve been writing literally since the beginning of Stratechery and it’s hard to believe, but it’s been nine years now, about the need for tying together all these SaaS products, and I’m just searching who’s going to be the center of gravity in an organization? My contention is that the reason why Microsoft ends up winning again and again, is you have these SaaS startups that are in their silos, they’re going to make the best possible user experience, and then Microsoft comes along and their alternative isn’t as good and the start up says, “Oh, I feel good. No problem. Ours works way better.” But they’re looking just at their functionality, they’re not thinking about the company as a whole. And Microsoft’s like, “Look, it doesn’t work as good, but it works with everything else that you have because you’re already using a bunch of Microsoft stuff.” So the question for Rippling is, there’s this vision, there’s a mountain, how do you actually get to the mountain without going through the valley of, “I have to actually convince people to use my product”?
PC: We have two things that we do. One are the integrations that I described, but the other is that we build a lot of our own products. One of the things that we do that I think is somewhat different than other startups, is that there is some conventional wisdom in Silicon Valley that I think is wrong, that companies should be extremely focused and do one extremely narrow thing, but go very deep. It might have been advice that worked ten years ago when you could build a billion dollar SaaS company by just peeling off one small feature from one of these monolithic business systems, these on-prem business systems, and turning it into a standalone SaaS service. Now that that opportunity has been picked over and there are a million different point solution SaaS companies.
I think that now in order to really make a dent in a lot of these markets, you need to build something more like what you’re describing, which is a coordinated set of interrelated services that interoperates seamlessly, and that’s a lot of our philosophy of building products. Rippling builds a bunch of things that historically would not have been thought of as belonging to the same system. Payroll, HRIS, a bunch of related systems around HRIS but then also identity, single sign-on user management, security services, device management, and the unifying theme is that each of these systems are reservoirs of employee data in their own right.
One of the ways that we’re able to do this is that we have built a series of what we think are the underlying fundamentals for a lot of business software, we call this middleware. We have middleware for role-based permissions, for reports and analytics, for policies, for workflow, for a whole bunch of other things, and you take this set of middleware capabilities and you assemble the Legos in one particular way and get the data model and the UX right, and you have a time tracking system. If you do it in a completely different way, maybe you get an expense management system. And if you do it in a completely different way, maybe you get a different piece of software entirely, but always built on this set of deep platform capabilities that are all built with this embedded understanding of your employees and your organization that creates some enormous product advantages across all the different software that we build.
What’s your market? I think you’ve compared yourself to Salesforce, for example, where Salesforce is centered on the customer and it’s much more than a CRM, it’s using the customer as a linchpin for all bunch of data and they’ve acquired a bunch of companies and they tie them together, and I can see that vision for Rippling. But one of the advantages Salesforce has is that customers are a profit center, customers actually are the ones that make you money. You’re talking about employees, and employees are a cost center, they cost you money. What level of company do you need to be at where this investment is worth it? A lot of Silicon Valley startups start by selling to other startups and then they try to go upmarket. Does Rippling need to start further upmarket where companies are already feeling this pain? How do you think about that?
PC: Not really. Weirdly we end up selling to two-person companies and thousand-person companies with the same system. I think to do that effectively, you need to have a system that both handles all of the feature checkbox complexity that much larger organizations need, but does it in a way where you reveal the complexity gradually so that for a smaller company it’s not overwhelming, but when they eventually need a particular feature, they can find it.
You mentioned smaller companies having less complex needs here, and the thing is I don’t really agree with that for two reasons. One is that even if the total administrative burden that a ten-person company has around the spurts of issues that we solve — systems proliferation, fragmented employee data. Even if that’s a lot smaller, they also have many fewer resources and so it’s probably just like one founder or CEO or something like that and they might only spend two hours a month dealing with these headaches, but it’s time that they deeply resent and they really don’t like doing it.
It’s sometimes actually a lot easier to get the smaller company that has an admittedly smaller burden but no resources to deal with it to adopt a system like this that makes it go away, than a large company that has many resources to deal with these issues and a much larger problem but there’s a zillion coordinator roles. HR coordinators, IT coordinators, finance coordinators that are doing administrative work across all these different systems.
So I’m a startup CEO. I’m like, “Man, I hate dealing with this stuff.” What is the pitch that Rippling right out of the box is going to give me?
PC: The pitch is basically: no one comes to Rippling looking for Rippling. Everyone comes to us looking for a very particular problem. They might say, “It’s a pain in the butt every time I hire someone, I’ve now got twenty-five different places I need to add them. We got to set them up in G Suite, in Slack, with Dropbox, GitHub, Salesforce, a whole bunch of other places.”
I’m more sophisticated. I have everyone using G Suite or Workplace or whatever it’s called now and I’m using federated sign-in, so I think I’ve got it figured out.
PC: Yeah, so then you have probably a series of other problems. I always talk about hiring someone because that’s when you see these problems in stark relief all at once.
Right.
PC: Because all the things happen when you hire someone. When you hire someone, you need to ship them their laptop, and, crap, you’ve got to somehow make sure that the right software’s installed to make sure that the drive is encrypted and your password policy is enforced so that you can pass your SOC 2 audit. You’ve probably got a series of issues around time tracking and connecting right with payroll and a whole bunch of other things. Whatever your problem is, we can go through a list and say, “Look, you came to us for one specific problem” and that problem is actually really only a symptom of this deeper underlying disease.”
You’re like a doctor that saying, “You’re actually far sicker than you realize.”
PC: That’s right. Yeah, we can make the “getting people set up on all these different apps” thing go away for you, but that’s one of twenty-seven different issues that you probably have. The real problem is that you have this fragmented employee data that is causing a lot of administrative pain for you across all of these different business systems, and we can come in and solve this one problem but also all of these other problems as well, and make them all go away.
Has COVID been a situation where the increase in remote work has made what you are building actually far more compelling? In part because a lot of coordination problems are papered over when you’re there in-person and when people are remote, it’s very clear if you have processes or not.
PC: We haven’t been a company that’s been a super COVID high flyer where suddenly everyone needed to buy this service, but I think what it has done is we used to get objections — some people are more traditional than others — and they would say, “Well, I like sitting down with an employee and filling out their I-9 form in person on paper. I don’t want to do it through a computer.” That attitude, that’s gone.
Right.
PC: No one thinks that way anymore because you can’t do it that way anymore, and so you have to adopt systems to do this electronically. I think there’s a greater willingness to adopt technology for a lot of businesses that you don’t think of as early adopters for software products.
What’s the response of other companies in the ecosystem? This idea that you’re going to build a core set of software gives you a reason to get into Rippling. But the long run benefit from my perspective is all these integrations and the fact that Rippling can sit at the center of these and be something around which this orbits. Is this something that you find from other potential integrations where they look at you and said, “Oh, thank goodness someone is doing this.” Is there people really looking to tie into this or does Rippling need to get more critical mass in the market before you start to see that effect?
PC: Sorry. See what effect?
Well, just from other SaaS companies, to go back to the Okta example. They had to go in and build all these integrations by hand, get critical mass, and then it tips over and other companies say, “Oh, I’ll work on this integration. Actually your integration is crap. We’re going to do a better job.” How does Rippling get to that tipping point where other companies want to advertise, “Our product works with Rippling.” As opposed to Rippling saying, “Hey, we have an integration with them”?
PC: We have a lot of companies today that seem to want to do that, I don’t know if I would say we’re past a tipping point, but it feels now that it did two years ago. But quite honestly, I prefer building integrations to third parties than the other way around, because we can build them correctly. And the way that we look at it, there’s only so many ways to do the things that we do with third party software, we’ve encountered all of them before. So spinning up a new integration, it’s usually just as simple as figuring out, “Okay, this is subtype 2B3 and here’s the format of the API responses.” and then it works and is well tested, and everything is well understood from that point forward.
So who are your biggest competitors in this space? Is it like a Workday where they’re taking in a lot of this employee information, I think they frame themself in this regard and has been very successful. Is it a Microsoft? Is it an Okta? Is it Google? If someone signs up for Rippling, who are they not signing up with?
PC: We compete weirdly because our product does so many different things with a bunch of different companies in traditionally not very closely related verticals.
Right, because one of the challenges if you’re a very focused, niche SaaS startup, you’re usually, “Look, I just want to peel off this one function. I’m not asking you to do deep surgery in your organization.” Whereas Rippling is like, “Look, we need to rip the skeleton out. You need a new skeleton. It’s going to make you the Bionic Man. You’re going to be much more powerful.”
PC: Or another way of looking at it though, is that we have multiple entry points into the organization. We’ve had companies all the time that come to us and they say, “Oh, we’re not interested in switching payroll, but we’re definitely interested in…” or “Man, we have no way to figure out how to get computers to new hires and when people leave the company, our founders closet in his or her apartment is piled up with used computers or something like that. And we want to solve that problem.” And we’ll talk to them. But then we’ll show them the capabilities and suddenly they’re actually like this conversation that started with their IT closet, ends up with them switching payroll and moving everything over to Rippling.
Does this mean that you have a very long sales process? There was a lot of rhetoric around bottoms up sales and organizations, and start with the small team, and I think eventually the challenge with those is they hit the limit — at some point you need to get approval higher up, and ideally they have a large base, companies have hit the wall in this regard like a Dropbox or Slack or some things like that. Whereas this feels very top down where you’re not going to implement this on a team level, it’s going to be from the top.
PC: You can’t run a team-based trial. There are dynamics in payroll that just make that physically impossible to do. Companies might use us for one of our products or one subset of our products and not the others.
Can they use a subset of products when they have another identity provider?
PC: Absolutely.
So if you’re using Active Directory, how do you plug into that?
PC: For example, you can use Rippling alongside Okta and have us push data to Okta, but the vast majority of our clients don’t do that. One of the secrets here is, look, Okta is a great product, but you have to have some in-house IT to do this. Someone’s got to be familiar with public/private key, you’ve got to understand this stuff. For Rippling, you can set up single sign-on with these apps. If you can install Candy Crush on your phone, you can set up federated identity across all of your different business applications in Rippling, it’s much simpler to set up. For a lot of companies, keep in mind most businesses now don’t hire in-house IT until they’re two hundred or three hundred employees, and so there are a lot of companies that start with Rippling and just don’t outgrow it on that front. The most vicious competition is always with other systems that are trying to be the system of record for employee data, and that usually means payroll and HRIS systems. When we come in, we compete both on the basis that we think we’re just a much better payroll and HRIS system, but also on this idea that we say, “Look, you don’t actually want merely a payroll and HRIS system. What you want is this deeper employee system that is managing employee data broadly across your company, across a whole bunch of business services and systems that are well outside of the HR department.”
In the same way that when you’re buying Salesforce, you don’t want something that’s just doing pipeline reports for your sales team, you want something that’s managing customer data across a lot of other functions in the company on top of that and that’s what’s really unique about Rippling. You’re going to click this button to hire someone and we’re going to get their agreement signed and their paperwork finished, and we’re going to set them up in payroll and do all the things that need to be done on the HR side, get them enrolled in benefits, but we’re also going to set up their access in all of these different business services, and we’re going to get them the right access, which is tricky, right? You can set up access in Rippling for example, and say, “Look, I want the people that get access to AWS — I want engineers that are either above level eight or that have tenure at the company and have been here for more than six months and in any event, only ones that have an active hardware security key live on their Rippling account and if they don’t have those things, then don’t give them access.” You can describe these access rules based on role, on work location and compensation if you like. Whatever theoretical employee attribute you want, those are all inputs into these different systems that are, again, very hard to do in a system like Okta or Active Directory that doesn’t understand all of the information in the employee graph that surrounds the employee. We can do all of these things for you much more broadly than just the HR stuff to solve this employee data problem that you have across your company.
I’m such a nerd that I woke up today and I was reading some more stuff on Rippling. I’m like, “Oh, yeah, I’m excited about this company. It’s fun to talk about” and it’s a HR and business SaaS problem. But what’s so intriguing to me is this idea that if you think about — I come back to Microsoft again and again, and I think they’re so underrated in the Valley even today, but particularly when I started Stratechery eight or nine years ago and everyone didn’t even think about them and ignored them. You mentioned that people don’t hire their first IT person until they have a few hundred people or whatever it is. And that’s always been, I think, the underrated aspect to what Microsoft sells you. It’s like, “Look, it’s not going to all be great, but it’s all going to mostly work together.”
What I think is very interesting and compelling and exciting about Rippling’s upside, again, this is down the road or in the future, is someone needs to be Office for Silicon Valley, right? The natural candidate was always G Suite or, again, Workplace or whatever it’s called, but Google just made this online Docs editor and had Gmail and then never did anything more. I’ve been banging my drum on this like, “Why don’t they actually build something where everyone plugs in and interacts, and you’re actually the center of an ecosystem?” What’s intriguing about this is to your point, everyone just wants to build their product and no one has an ecosystem vision. The possibility or potential of incorporating not just their products, but a whole bunch of other products.
PC: Yeah, so maybe one way of thinking about this is that, if you want to challenge Microsoft, it’s not enough to build Slack, obviously Slack came before Teams, but if you have Slack and you’re competing with Teams, it’s not enough. The real thing to do is you need to compete with Active Directory.
Yes. Absolutely.
PC: If you think about what would a better version of Active Directory look like, I think that my view of this is it would be maybe not a directory but a graph. It would be a graph of employees and their associated data across a lot of different business systems.
**And this is why I wanted to have you on. I’ve gone through a bunch of candidates over the years for who is going to be the new center of gravity that’s going to tie together all these disparate SaaS companies. I went through it, is it going to be Box or Dropbox, because you have all your documents. Is it going to be Slack? Because that’s where conversation happens. And the funny thing is, and the reason why Rippling clicked for me, is I have written that the key to Microsoft’s enterprise dominance is Active Directory, and that’s why it’s so brilliant. They gave it away for free because it was what tied everything together. Of course, the alternative is going to be the same thing, and I get your point about it being a graph and a better representation of data.
PC: It has all the employee data in it, it’s not just usernames and passwords.
Yeah, and every single thing that you do needs that bit. This is why I’ve always been bullish and excited about Okta. I think I did an interview with them a while ago and I’m like, “Why don’t you do more on identity? It feels like you have a touch point with every employee, there’s something more here.” See, I’m such a nerd. This one gets me excited, but it’s exciting to have this view of it.
PC: One way of thinking about it is like, okay, where would you go if you needed to sign up for a new 401(k)? Where would you go to get a list of who all the employees are that need to be set up there? And the answer is you’d go to your payroll and HR system, and that’s where you’d get that report. If you needed the information to really be right for some important thing where you’re trying to understand — maybe you don’t need contractors, you want W2 employees. Maybe you need to make sure that you’re just getting people in California or just people in this department or on this team. That type of information is always in these payroll and HR systems. It’s just, I think, a weird anachronism that the identity system that was used by the IT department has always been this completely separate thing that’s not part of this HR system, that’s the core system for employee data. I think the different thing about Rippling is this belief that those are really the same thing and that if you put them together, there’s a lot that you can do that’s much more powerful both sides and across the entire organization.
So how does this vision end up failing? What goes wrong? I think maybe something that comes to my mind is I think your point about focused SaaS startups had is agility. Rippling sounds like the ultimate fat startup, right? You’re building tons of functionality, multiple bits, I know you’re hiring former founders to run all these different divisions because you’re like a hierarchical DuPont style organizational company from the get go instead of being this focused organization. But one of the benefits of being focused is it’s easier to execute and you can actually get the product out the door. So the first thing I worry about is do you just get bogged down with your own complexity going forward? Is that a concern, and how do you overcome that?
PC: What you’re pointing out is that there are some advantages that a focused company has over what I call a compound company to distinguish it from a focused company. The advantages of focused companies are pretty well understood and well covered and so maybe what I can point out are four specific advantages that I think a compound company has over a focused company. And the first one is deep integration. In Rippling’s case, deep integration, not just with Rippling but with employee data and that on its own unlocks enormous product capability.
Yeah, this is the underrated thing about Microsoft for sure. With Microsoft, if you build it yourself, you get to integrate it and it just works better. This came so clear to me — I have one employee, and the struggle to get Dropbox and Slack and Google all to just work together, that’s why I switched to Office. And guess what? OneDrive and Teams and all this stuff, it just works. Is it the best user experience? No. But everything is where it’s supposed to be and if you actually do need to share stuff and interact with stuff, it just works better.
PC: Yeah. The second thing is that there are a set of shared capabilities that you have across all these different products. And for those areas, for that shared functionality, Rippling can go ten times deeper than any point SaaS competitor can and be a hundred times better. Things like analytics, most SaaS companies at some point they have to build reports, but they build reports because their client makes them build reports.
Yeah, begrudgingly.
PC: It’s cludged on as an afterthought. When we build reports, we’re trying to build an analytics suite that starts to rival different BI tools that is then suddenly available to you in every Rippling application that you use. The same thing with workflow, that you build a set of workflow capabilities, a system for role-based permissions for policies and approvals. Those things in those areas, which happen to be quite frankly for most enterprise buyers the most important things that they’re looking for across each of these different verticals. Rippling always wins on that stuff.
The third thing is that you get for your user base a common UX across all these different systems. If you have a user that takes the time to figure out how to set up workflows in Rippling, if they learn the scripting language that we’ve built into our product called RQL, they’re going to have superpowers that exist in every product that they use or buy through Rippling that don’t exist for them when they buy other third party software.
Your business model I presume is a major land and expand. So you’re going to look for people buying one of your modules, buying additional ones, and down the road they won’t even think about anyone else because they have these capabilities. Again, the Microsoft playbook from decades past.
PC: Our goal is to launch one new product a quarter going forward, and one thing that we’ve seen is that the time for these new products to get to a million dollars in ARR keeps shrinking. We have the latest product that we launched that’s inventory management that I think will get there within five months. So basically this product is, when you terminate an employee, we’ll send them a box, they put their computer in it, it ships back to our warehouse or actually our partner’s warehouse where they wipe it, rate the condition, and store it for you so that the next time that you hire an employee, you can just use it from a list of computers when you hire someone and it ships out directly from them. That product is growing like gangbusters, but every new product that we launch is growing faster and getting there more quickly than all the others.
That brings me to the fourth advantage that I think compound companies have is pricing and contracting. You certainly see this with Microsoft, which is that, if you’re a compound company, you can maximize price over the portfolio of SKUs that you offer rather than having to maximize price on any one SKU. Which means that for clients, it is actually often less expensive to buy a suite of products from one vendor than to source point solutions from a bunch of individually focused point SaaS companies, because every point SaaS company can only amortize their R&D and their sales and marketing across one SKU, which means that you’re paying a premium. If instead you have a compound company that has a portfolio of things that they can offer you, in addition to all of the product benefits that we described, there’s often just a pricing and contracting advantage that allows you to run circles around competitors from a pricing perspective.
I started off by focusing a lot on this integration angle. What’s interesting about this conversation is we’re coming back again and again to a Rippling bundle or a Rippling suite as it were. Is there a situation where in the long run, of course, you need integrations, you’re not going to do everything, but your idealized customer is more and more of their operations are just being absorbed by Rippling because they’re getting these benefits — it just works together. It might not be the best solution, but it works with everything else that’s out there, or that I already have my company with Rippling and “Hey, Rippling tossed in for free!” — the whole classic Microsoft strategy. Is Rippling going for more integration over time as opposed to being ultimately this great integrator of all these modularized individual solutions?
PC: My view is I think it’s both and it’s both for two reasons. One is that there’s always a bleeding edge of products or functionality that you aren’t building yourself or don’t want to build yourself, or it’s just farther out and there are many other priorities, where you can really create real distribution for partners. And there are a lot of companies that I would like to think that Rippling creates a lot of real distribution for them within our customer base.
And the second thing is that even for products that we do natively, there are always edge cases that we don’t cover. Our goal is to cover 100% of the use case for 70-80% of the customers. You take something like time tracking, we have our own native time tracking product inside of Rippling, but we also have really strong partnerships with other companies that do time tracking independently of Rippling and integrations that we care very deeply about maintaining with those companies. If you’re a retail store, you want to use a product like Deputy that’s built for retail stores. There are other time tracking products that focus on security guards, where there are all kinds of special considerations if you’re selling time tracking for security, because if they don’t show up, it’s much bigger problem than other kinds of cases. For example, Salesforce has a service cloud, but the integration with Zendesk is extremely important to both companies and so I think you do both.
Is Rippling in the long run a major acquirer like Salesforce is? Because you just realize this should be part of Rippling, it’s already built, it’s going to be faster for us just to acquire it and put it into our channel. Ideally, if you already have this distribution advantage.
PC: We’ve done some acqui-hires.
Right. More in the long run when you’re not relying on venture capital.
PC: One of my thoughts on this is like, “Man, I don’t know what I’m doing buying companies and even the people who know what they’re doing seem to screw it up a lot.” so I’m personally just gun shy on that. But the other thing that I think about is when I go back to those four reasons that compound companies in my view work, three of them don’t apply when you buy a company.
Right.
PC: It’s not actually more integrated, at least not without an enormous amount of work. It’s not built on the same set of middleware components, so you don’t get the benefit of having much better analytics, much better workflow, much better role based permissions. There’s no common UX for clients, so you don’t get the benefit of that. The only one that you get is the common sales and marketing and contracting motion.
I have to be honest, I read all these articles and you always compare yourself to Salesforce. But again, this is very Microsoft like, right? That’s why Microsoft wanted to build Teams instead of replace Slack is 1) they’ve always built their own stuff but 2) if their advantage in this marketplace is the point of integration, that if you build it from the top — I mean, Teams is just a layer on top of SharePoint, that’s really what it is. But SharePoint was engineered from the ground up to work with Office, to work with all the different pieces and so they get this integration that is attractive to companies because they built it themselves. It’s funny because when the people hear integration, they always go back to Apple versus Windows back in the day, but integration work in all these different levels and Microsoft is such an integrated company, and that’s the same takeaway I’m getting from so many of your comments.
PC: I agree with that. I think there are huge benefits if you can set up the company to build a lot of these things in-house, there are enormous product benefits from doing that versus acquiring other companies.
One question on this. There’s this really great piece by a former head of Office [Terry Crowley] talking about how complexity increases over time, and one of the challenges with building a heavily integrated software suite is you start out with this vision of having all these primitives and all these different pieces and “We’re going to use these Legos and building blocks to go into each one”. But as the complexity and size of these applications increases, those functions become absorbed into the application, and you reach a level where it becomes so costly to make a change or an adjustment across all these different things that the velocity really slows down, your ability to respond is very challenging. It’s interesting because this was in the context of Google Docs versus the Office suite and at that time, how Microsoft was thinking about how to put it online.
He predicted, I think accurately, that the speed of change in Google Docs would just slam into a wall, which is exactly what happened.
I wonder if that’s something that you’re thinking about in the long run. Where right now, pretty early days, “I’m going to build all these different primitives, we can put in Lego blocks to build these different applications”. But the more applications you build and the bigger you get and the more customers you have on them, is there a worry that you’re going to run into a product development wall because of all this integration?
PC: Gosh, it’s an interesting thought and not something I’ve spent a lot of time thinking about. I think what you’re saying is that there’s this tension between forcing your product teams to build on the off the shelf opponents versus allowing them to customize them deeply for their own bespoke needs.
There’s a real tension between integration and velocity I think, particularly when it comes to software.
PC: I can tell you what we’ve seen so far is, I would like to think that for a lot of the products we’re building, this really speeds our time to market because so much of what you need to build for that product to work is something that you can take that’s relatively off the shelf.
The individual pieces are really just not that complex so it’s easier to do.
PC: If you think about building expense management systems, well, what do you have? You have policies which are a pretty well formed construct in Rippling, and you want them to be applied based on role, because different people within the organization, different policies apply for that stuff. You want approvals, that’s really critical, right? That’s a really well formed concept inside of Rippling. You want reporting and analytics and alerts so that managers and other people who care about spending in the organization understand where the money’s going, who’s spending it, what they’re spending on, and you need things like receipt scanning and a few other things that are very specific to that vertical. A lot of the core concepts are ultimately about business process, decision making and workflow related to the specific vertical, and so you got to get the data model right, you got a few things that are very specific to that vertical that you need to build in. What you actually have to build from an engineering perspective, maybe it’s only 20%, than what you would need to build if you were building it completely from scratch. The output is a product that’s not an inferior product, it’s a superior product because of how sophisticated those underlying components already are in the system.
You’re starting with modular from the beginning and I think that’s a really key thing, you’re not taking some applications and then making them integrated, that makes sense. We’ve spent a lot of time in digging into Rippling. Just to go back to Zenefits for a moment. How, if anything, has that influenced and impacted your approach to Rippling? I’ll let you take this wherever you want, whether it’s the end of Zenefits or the lessons you learned from the consumer markets, how has that changed you and shaped you as you’ve taken on what is an even more ambitious company?
PC: First, I would say there are a bunch of positives that I think I really took away from Zenefits. One was this conviction that really came from Zenefits, that what I saw with Zenefits is what made that company work, when it was working really well, was that there was a button that you could click to hire someone, and they would show up automagically in all these previously disconnected HR systems.
So Slack was like a chat system for making a game, Zenefits was like an employee management system for selling health plans and it turned out that was new market.
PC: That’s right. But what became clear towards the end of my time there is that people just wanted that button to work for everything in the company. The fact that, well, G Suite was not part of HR, didn’t matter, they wanted new hires to get set up with their email accounts, and that was a hugely popular concept, so I think I took that away from Zenefits. And I think the other thing is this idea of a compound company. Zenefits was — there were a lot of things that broke about our software, one of the points of view that came out of that is there are people that said, “Well, Zenefits is doing too much.” and I actually walked away with the opposite perspective. I was like, “That’s exactly you want to do, the number and the scope of things that we were trying to do there.” It’s just that we failed to do it well and you need to not screw it up. I’m talking purely about the product quality and not about anything beyond that. So at Rippling, I spent a lot of time thinking about when that compound approach worked well at Zenefits and there were a few cases where it worked extremely well, and could we replicate that and double down on that idea and try and make headway on a lot of different parallel fronts at the same time.
And then lastly, one of the things I think really did the company in, was that very early on I made a mistake. We thought that the biggest problem we had at Zenefits was that it was too easy for us to close business and this entire market we were going after for insurance brokers was going to turn over in five years, insurance brokers were going the way of the dodo. We needed to find a way to take all of the oxygen out of the room and grow so quickly to soak up all the demand because if we didn’t do it, someone else was going to, and then they might win this market instead of us. Things ended up not turning over, I think that concern was a little bit misplaced.
I made this very conscious decision that we would say, “Look, businesses have all of this administrative work related to these disconnected HR systems and so what we’re going to do is we’re just going to take on all of the administrative work, do it ourselves internally, and we’ll work to automate it over time.” The problem was is that when you scale up something like that without a lot of automation, it’s a lot harder to automate it after the fact, and the automation ended up taking longer, it was constantly delayed.
There’s a line from what you just said to the question I asked before about the software bit. I think the fact that you’re being super disciplined about being extremely modular in your software from the get go because if you try to integrate after the fact, that’s where all the complexity becomes overwhelming.
PC: If you start with automation, you can scale the automation out over time if you start small. So the analogy I think you’re saying is, “If you start with this modular approach to building software, you can scale that up over time.”
Right.
PC: But it’s hard to jam in at scale after the fact.
You start out thinking, “Oh, he’s doing Zenefits again” when you just hear it’s about HR and stuff like that, and it sounds like in every respect it’s the exact opposite. You have a top down sales process, you’re going to build all this software, it’s the opposite of, “We have to take over the market within three years”
PC: Yeah, we spent a lot longer building the product, but we built it, we had just constitutionally early on no tolerance for any in-house operations, the company was just me and software engineers basically for a long time. And that meant that everything was in software and everything was automated. We didn’t hire our first support reps until we were at a couple million in ARR because we were so paranoid about having anyone in the company that might be willing to do administrative work to bridge any gaps.
Fascinating. Yeah, that’s really interesting. I thought we’d go thirty minutes, we have gotten an hour. I’m probably the only person in the world that gets excited it about office enterprise SaaS integrations, but it’s super interesting. Like I said, you inspired me to do these interviews, is there any final words before we go on?
PC: No, I’m really excited to see the other ones! I’m glad that you’ll be talking to some other private companies.
This is literally just a kickoff. So I think part of this interview I think is I’m a little bit dreading the inbound email that’s probably going to come, but it’s a good way to dive into what you’re doing. I look forward to seeing what happens in the future.
PC: Thanks a bunch, Ben. I appreciate it.
All right. Sounds good.
This Update will be available as a podcast later today. To receive it in your podcast player, visit Stratechery.
The Stratechery Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly.
Thanks for being a subscriber, and have a great day!