Invest Like the Best with Patrick O'Shaughnessy - Parker Conrad - Building a Compound Company - [Invest Like the Best, EP.303]

Starting point is 00:00:00 This episode of Invest Like the Best is sponsored by Canalyst. Canalyst is the leading destination for public company data and analysis. Founded by a former byside analyst who encountered friction sourcing, building, and updating models, Canalyst is now used by over 400 institutions, including the largest money managers globally and by a number of guests on the show. With detailed company-specific models and data on virtually every public company, panelists clients are able to ramp up faster, update models instantly, and incorporate the highest quality fundamental data into any workflow. If you're a professional equity investor and haven't talked

Starting point is 00:00:32 to Canalyst recently, you should give them a shout. Learn more and try Canalyst for yourself at canalist.com slash Patrick. That's C-A-N-A-L-Y-S-T dot com slash Patrick. Today's episode is sponsored by Brex, the integrated financial platform trusted by the world's most innovative entrepreneurs and fastest growing companies. With Brex, you can move money fast for instant impact with high-limit corporate cards, payments, venture debt, and spend management software all in one place. Ready to accelerate your business, learn more at brex.com slash best. That's bREX.com slash best. Hello and welcome, everyone. I'm Patrick O'Shaughnessy and this is Invest Like the Best. This show is an open-ended exploration of markets, ideas, stories, and strategies that will help

Starting point is 00:01:19 you better invest both your time and your money. Invest like the Best is part of the Colossus family of podcasts. And you can access all our podcast. podcasts, including edited transcripts, show notes, and other resources to keep learning at join colossus.com. Patrick O'Shaughnessy is the CEO and founding partner of Positive Sum and the CEO of O'Shaunacy Asset Management. All opinions expressed by Patrick and podcast guests are solely their own opinions and do not reflect the opinion of positive sum or O'Shaunice asset management. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions. Clients of positive sum or Oshonancy asset management may maintain positions

Starting point is 00:02:02 in the securities discussed in this podcast. My guest today is Parker Conrad, co-founder and CEO of Ripling. I wanted to speak to Parker because he is building Ripling in a way that we don't come across often. Rather than focus narrowly on one product, he is building a suite of interrelated products simultaneously to carry out functions of HR, finance, and IT for companies. He calls it a compound company. And we discussed the idea as well as some of his other non-traditional theories in detail. Please enjoy this conversation with Parker Conrad. So Parker, one of the, I guess, sacred cows, or if there's a 10 commandments of startups and business, this one would be on there, is that you're supposed to begin a business for a customer by focusing on one thing and get really, really good at

Starting point is 00:02:49 that one thing and serve them well. And then you earn the right to transfer from product to platform. And this has become gospel in the world of building young technology companies especially. And I think you have a very, very different take on what might be possible in terms of how to build early on. And I'd love you to lay the groundwork with your concept of a compound startup or a compound company right at the beginning because I think it will inform just about all the other topics that we talk about. I generally agree with people who talk about the advantages of being focused as a company. I think that it's limiting and it misses something because I think that there are a few underlying reasons. One is that a lot of really focused companies or the really focused company ideas have been picked over at this point. You wanted to do a really narrow point SAS vertical company.

Starting point is 00:03:43 The odds are at this point there are five other people who are already doing it. It's not that I think it can't work. It's that there are these undiscovered islands of product market fit just beyond the horizon. that do this thing that people have largely been unwilling to do to date, which is to take on a constellation of interrelated products or features and build them in this way where they're seamlessly interoperable and build a company around that. There are a lot of opportunities there. And I actually think that what I call a compound startup is not really something new. It's maybe something old come again, which is that if you look at the history of business software

Starting point is 00:04:21 and you look at the really big outcomes from 20 or 30 years ago, most of them are what we would call compound companies. You look at businesses like SAP and Oracle and Microsoft. That's what they're all doing. They all have very broad product portfolios. And I actually think there's a misconception that the way to build product quality is to focus very narrowly. And that's the thing that I disagree with the most. I think that there are a whole. whole host of ways where when you build in this compound way, you actually build much better products. And we can talk about what those are in a second. But I think the natural state of the world, because it produces the easiest and the best products for customers, is actually to build in this

Starting point is 00:05:09 compound way and to have these Megapoli business software vendors that cover a broad swath of territory. And what's happened is for the last 20 years or so, we've had. these external market forces that are ripping these services apart, because the underlying distribution for software has been shifting from on-prem to cloud. The whole delivery vector for how you get software, your customer changed, for a long time, the only thing that mattered was how quickly you could take some business process or some feature of these Megapoli on-prem vendors and turn it into a standalone cloud service.

Starting point is 00:05:48 The way to do that very quickly was to build. these very narrow point solutions in the cloud. Because the existing vendors, it was really hard for them to rebuild everything in this cloud-native way. But I think now that there's a little more stability in the underlying vectors for how we deliver software, I think the overwhelming product and commercial advantages of deeply integrated software and bundled contracting and pricing are going to start to redominate a new generation. of megopoly business software vendors are going to emerge. And I think that one great example of this is Salesforce.

Starting point is 00:06:29 And I think that Rippling is another. Maybe you could talk a little bit about the customer selection part of this, because maybe one of the insights even so far is there's no customer that has one problem. The customer has all sorts of problems. And the playbook maybe has been to pick one and then bleed into adjacencies. but you're dealing with employee data or the employee as the interesting unit in the data model. Maybe just say a little bit about across all the businesses you've been a part of what you've learned about picking a customer effectively because that seems to then drive

Starting point is 00:07:05 so much of what you can build in the product lineup or the feature lineup for that customer over and over again and the power of those integration. So what have you learned about picking customers well? I would say the one thing that we don't do is unlike a lot of other software companies, we don't try and go like really high up market. Most software companies are focused on going after enterprise, going after companies that are 10,000 employees or more. The reason we don't do that is it's actually a very small slice of the market.

Starting point is 00:07:37 If you look at the United States, about 90% of people in the United States work for businesses with less than about 2,000 employees. And if you look at other countries like Canada and the UK and the EU, it's like 99%. But the reason that other companies are so focused on that pretty narrow sliver of the market is the only place where they can make their unit economics work around customer acquisition. So they just don't make enough money on an individual customer down market to justify the sales and marketing investment that they need to get that customer. And one of the ways that Riplein is very different is,

Starting point is 00:08:11 because we cover such a broad swath of products, we often have very high wallet share within our customer base. And so even though our individual products are often surprisingly affordable for customers individually, the overall effect is that customers end up paying us a decent amount of money because there are so many different problems that we can take on for them. And that allows us to make our support model, our sales and marketing motion, And all of that stuff works at a much smaller size of company than it does for most traditional software businesses. If there was a great book titled How to Build a Compound Startup, what do you think the key couple chapters would be?

Starting point is 00:08:55 I'm especially curious about the earliest days. I've seen you talk about working basically with you and 40 engineers and spending a couple years before really anyone knew that Rippling existed. So lots of building with a fairly large team. Talk about the preconditions that are required. for the eventual potential of this compound startup, and we'll talk about how fast you launch products and things now and how fast they scale.

Starting point is 00:09:17 But talk about the work that's required at the infrastructure or early stage if you have ambitions to build a compound startup. I spent a lot of time thinking about where are the places that these different products compete with each other for resources? Where do things get gumbed up? And that can happen at a lot of different levels. It can happen at some very fundamental level. Things can compete for like DB rights and CPC.

Starting point is 00:09:41 use cycles. You need to break things apart into services at the infrastructure level. And they can compete for executive attention and recruiting capacity and all that different stuff. And wherever you find that, I think you've got to find ways to untangle the knot and break things apart into services or capabilities that can scale much more easily with an number of products. And so that's one of the things that's important. I think the other really critical thing is, you You've got to find a reason that you building in this way is better for customers. Sometimes people come up with ideas really like Rippling, like you guys should become a bank or something like that.

Starting point is 00:10:22 It's never been clear to me. There are a set of products that we would just not go into. I can see a lot of reasons why Rippling becoming a bank would be really good for Rippling. A lot of money. Banks make a lot of money. But it's never been clear to me why the customer wants us to become a bank. What's the sort of unique product advantage that we have in that, market. And all of the markets that we end up going into are areas where we think we have unique

Starting point is 00:10:46 and distinct product advantages that come from the fact that this new product is deeply integrated with the employee data, with the rest of Ripling, and in particular with a set of underlying platform capabilities that we call middleware. And the idea behind this is that there are a set of product components that end up being repeated a lot across a lot of different software verticals. And one of the advantages of building a set of interrelated products is that you can abstract out these capabilities and be much better at those capabilities than any of your point solution competitors are. Workflow automations, role-based permissions, custom policies, approvals and routing. And those are things that a lot of times in other business software,

Starting point is 00:11:33 reports are this afterthought that our competitors were sort of billed grudgingly because customers are making them do it. So they'll say, oh, crap, we got to build some reports. Let's give people some CSV extract that they can go play with. And with Ripley, when we build reports, we're trying to build a full analytics suite that rivals things like Tableau and Looker that then is available across all of our products. When we build a spend management system, We need to have great receipts and great data extraction that gets data out of receipt images so that it makes submitting receipts and getting reimbursed really easy. But generally, our goal is to be best in class on that, but we're not reinventing the wheel on it.

Starting point is 00:12:16 Where we win is that the reporting and analytics for spend in Riplein is 10x better than any of our competitors. And it's 10x better in part because the systems are so powerful, but also because all of the data is just, just natively joined back to the employee. So you can easily look at things by department or by manager or exclude all your interns or zoom in on your India location or whatever it is. We're better because our approvals and routing is so much more powerful than any of our competitors because if you need approval on something, most systems, they don't understand enough about relationships between employees to do that effectively.

Starting point is 00:12:53 So maybe they understand who someone's manager is and you can get approval from them. But a lot of times you need approval within a company from the director above you in New York chart or the VP or your site lead or your HRBP or the finance associate that's aligned with your team. And those are relationships that are just natively understood in Rippling and you can route approvals or workflow to those individuals for any employee however you want. Most systems are just like that's right over their head. Across a lot of these different capabilities, in every product vertical that we go into, we win in the exact same way in every case. And we win because it's more deeply integrated with employee data. It's more deeply integrated with the other products in RIPLIN.

Starting point is 00:13:36 And because it's built on top of this set of capabilities that are just a lot more powerful than afterthought, clutched on capabilities that get built by a lot of our point SaaS competitors. I think the whole middleware thing is really interesting. And it makes me think of Rippling compared to Salesforce, where Salesforce is the customer record. and then all the stuff that's built around the customer, and then Rippling is the employee record, all the stuff built around the employee. If you go down below middleware,

Starting point is 00:14:03 whatever the base level infrastructure layer is around employee data, what does great look like there? What is hardest to do, but worth it, when building the most base level of infrastructure on top of which the middleware and then ultimately the applications sit? The analogy with Salesforce is that it's not a CRM system, and it's definitely not a system for pipeline reports. It's really a system for managing business process and workflow that relates to customers and customer data.

Starting point is 00:14:31 And the thesis of Riplane is that there exists within businesses a whole bunch of business process and workflow that needs a very similar set of tooling to the tool set that you have with Salesforce. It needs workflows and workflow automation, reporting capabilities, role-based permissions, all of these same capabilities. you just need that stuff to be built on top of a different underlying primitive. You needed to be built with this understanding of who your employees are, their job and role and function, and their relationships to one another, rather than this internally facing system as opposed to the externally facing one, which is Salesforce,

Starting point is 00:15:12 that has this understanding of who your customers are and how leads and contacts relate to accounts and who's the relationship manager for that within your own organization. These two things are bizarre a world, other side of the mirror versions of one another. One of the things I really like about Rippling that I think is really interesting is that we're basically building a unified schema across all of business software. If you look at data models across a lot of different business software systems, GitHub has a pull request.

Starting point is 00:15:43 And that pull request will have attributes like the date. It'll have some of the content of the pull request. And it'll have the person that raised the pull request, it'll have an approver. And then you look at Zendesk. Zendesk will have a ticket. And that ticket will have date and content associated with it. And it'll have like an agent. And a Jira ticket will have many of those same things.

Starting point is 00:16:03 And then it'll have an assignee. The assignee, the person that raised the pull request, the approver, the agent, those are all employees within your company. And so as a result of that, the employee ends up being this common joint. condition that allows you to construct this unified schema across all of these different systems. There's one other way of doing this, which is you can use the customer as the joint condition instead. And that's how you get this bizarro world version of the same thing, where you have everything joined through the customer or everything joined through the employee. And at Rippling,

Starting point is 00:16:40 we call this unified meta schema with the employee at its center, the employee graph. And we call it employee graph really to distinguish it from employee directories, which tend to be extremely flat and static and unidimensional. An employee directory will have things like usernames and passwords and maybe some group memberships or something like that. But an employee graph will have, first of all, all of the underlying HR employee data, things like information about compensation and their job and role and function, not just a singular department, but an entire department hierarchy and teams and work locations and employment types and stuff like that. But then it branches off and includes things like what computers are they using because people often use

Starting point is 00:17:26 more than one. And what's the operating system on those devices and how much data has been exfiltrated from those machines in the last 30 days? And how many open pull requests do they have? And what's the oldest open pull request that they have? And how many Jira tickets are assigned to them? And how much equity do they have in Karta? Bring all this stuff together. And one of the things that it does is that when you're opinionated about the way that all these systems are oriented towards one another, which in our cases, like, they're all oriented through the employee. It really simplifies the types of joins that you would do on this data. You can create actually very powerful analytics systems that are as easy to use as installing an app and telling

Starting point is 00:18:08 us what you want to see in a report. That concept of this employee graph where all the data is there and join together right at once. It allows you to either our own engineers who are building new applications or our customers that are trying to understand something about their business, that you can really easy query things. Like, tell me this particular Gira ticket.

Starting point is 00:18:30 Who is the assignee on that? And what is that assignee's most recently used computer that they have accessed? And then tell me questions about that computer. And what it does is it creates a lot of functionality. in our products that we didn't intend to create. In our spend management system, for example, one of the things that we did when we first started using it

Starting point is 00:18:52 is we had a company holiday party and we wanted to issue corporate cards for per diems for everyone that was traveling to visit our company holiday party. I was able to, in, Rippling, go in and just sent out a survey for this RSVP that basically said, look, are you planning on attending this party? The answers were, yes, I'm attending just, me, yes, I'm attending with a guest or no, I'm not coming. And so I could say to universe,

Starting point is 00:19:18 I'm going to give this corporate credit card. I could have said I'm going to give it to the sales department or I could have said I'm going to give it to everyone level nine and above. But instead, I said, I'm going to give it to everyone that responded yes to this specific survey question in this specific survey in Ripley's survey product that also happens to be an employee that lives somewhere that is more than 40 miles away from our office and therefore needs to travel. And therefore, needs to travel to do this. You can do that in five seconds. We never had to build an integration between our corporate card product and our surveys product that would allow you to trigger corporate card issuance off of surveys. But that capability existed anyway because both of these

Starting point is 00:20:00 things integrate down into the employee graph and all of the data stored in the employee graph and therefore all of it's accessible to all of the other applications inside of Ripling. that creates mind-blowing capabilities across all of these different products. So if I understand right so far, I think really the thing that enables a compound startup like this is incredible infrastructure and middleware, which brings us to the applications now that sit on top of those things. I'd love to just hear your philosophy on, I guess, product very writ large, given that you are launching so many products. It implies that there's others that you're not launching, so you're choosing between them. It implies you're deliberate about the pace at which you deploy these things, how you pick them, how you deploy them.

Starting point is 00:20:43 I'm interested in all of it. So I would just love to hear, given that you've got quite a playground that you can build so many different things around this great infrastructure in this compound way. What is your philosophy of product about what rippling should build, how it determines what it should build, how fast it should go, and so on. I think that there are four critical advantages that compound companies have overfocused companies. There are a ton of advantages that focused companies have over compound companies. But there are four ways that we win. The secret is that it's the same four things across every product that we build. And those four things are first that these products are more deeply integrated with employee data and with Ripling overall.

Starting point is 00:21:23 The second is that they're built on top of this set of middleware components. And so that means that the things that we do centrally in Ripling, the middleware capabilities, the products that we build, those capabilities for those products are always going to be one or two orders of magnitude more powerful than any of our standalone competitors. No one's going to beat us on reports. No one's going to beat us on workflows, on approval chains, things like that. The third thing is that for our clients, if you're a Rippling user and you've taken the time to learn how to do things in Rippling with one of our other products, if you know how to

Starting point is 00:22:01 build a report or set up a workflow or Godfurt or Godfrey, forbid you've learned RQL, which is the scripting language that's built into RIPL. You have superpowers that apply to you when you buy your next product from Rippling. Out of the box, you're ready to go. And those superpowers don't exist for you if you buy instead a third-party company product. Because there's this conserve user experience across all these products, that's a really powerful value prop. And then the fourth thing is that there are these pricing and contracting advantages that you have as a compound startup. because you can amortize your sales and marketing and your R&D costs across a whole bunch of

Starting point is 00:22:41 different skews and you're competing against point SaaS companies that have to make it all back on that one skew. You see Microsoft playing this particular game to great effect. Why is teams beating Slack? And it's because like it's free in the Microsoft bottle. You know, like, so generally speaking, the product areas that I like to go into are areas where those four advantages are maximized. So you want to move into products where employee data really matters, where you can build a better product because of the deep understanding of employee data and really of your org that the product has, where the integration with the rest of Rippling matters, where the specific middleware capabilities that we have are important to that product area, where you have at least one buyer in common so that you have someone that already knows how to do this stuff in Rippling, and therefore there are superpowers that they can carry over. to the new product line. And in areas where all else being equal, you have some advantages around the way you do pricing and contracting,

Starting point is 00:23:39 to get clients a much better deal if they go with your product. A single and a singular individual, often a former founder, Rippling has just an enormous number of former founders that work at the company that starts and owns this from zero to one and hopefully from zero to much more than one. But they're in charge of recruiting the early engineering team, building the product themselves. There are some resources that we give them internally. Usually the teams that build these products pre-launch are only about four to five engineers.

Starting point is 00:24:11 And usually you can get to quite good product, building on the rest of the platform that we have, with a small number of people in about 12 to 18 months. And that's generally been the time that it takes. And then usually what you have to do is you actually have to ramp up the hiring on the engineering side a lot right as you get to launch because most of these products tend to have somewhat unnaturally high sales and marketing ramp curves. And so normally when you launch a startup, what happens is you launch and get a bunch of signups when the article in tech crunch or something. And then it's like crickets for two years. And so you have a lot of time to feel your way through all of the rough edges and fix them and

Starting point is 00:24:53 sand down the things that are poking out and all that kind of stuff. And the products that we build internally, that happens much more quickly. And so you actually need a real rapid response effort to really dial things in very quickly because the customer growth is often quite high early on. Sounds like very much your role is part capital allocator already, even though that's more commonly a key role for much later stage business, public companies, et cetera. But it sounds like you're allocating capital and resources to these small teams to start these product building processes. How do you do that? There's not unlimited resources in the world. I know you're well capitalized, but how do you think about your role as capital allocator

Starting point is 00:25:32 and how to apportion out resources to these teams? I think I'm okay at product. I don't think I'm great as a PM. What I do do, and the thing that really helps me is that for Rippling itself, I'm the only full admin for our company. And so we're now a 1,700-person company across roughly 12 to 15 different countries and I run payroll in Ripling for our offices everywhere around the globe. I manage employee benefits, manage and run open enrollments and set a lot of the device and IT policies and manage that across the company. I use the product day to day every single day. Actually, over time, it takes up more and more of my time, but there's this constant effort for me and

Starting point is 00:26:23 for the teams within the company to keep cutting the amount. of work that it requires for me to do this for the business down so that even as we grow, it stays manageable for me. I think that's what gives me the right to have a useful opinion about this stuff. And so a lot of the things that we do come from that and they come from my own pain points around this. Obviously, like one of the things that people say about startups is you want to spend a lot of them talking to customers and understanding customer problems and customer pain. And my view on that is that I've always found it to be a shortcut. If you can short circuit that whole process and just try and be the customer, then a lot of those conversations can happen in your own head.

Starting point is 00:27:06 Feedback loops much tighter. Yeah, the feedback loop is much tighter. To the extent that I feel like I have useful opinions about product and what we should build and how we should build it, that's where it comes from for me. How many products is rippling up to now? We probably have at least two dozen skews. It's a lot of pieces of software. With those in mind, I'd love your opinion on another one of these old tropes of there's three variables.

Starting point is 00:27:33 There's time, there's cost, and there's quality. And you can pick two. If you say that about building houses, maybe some people said it about building software, do you think that's true that you have to make decisions between those three in the way that you build? I don't really believe in those tradeoffs. They can build a product that is on the stuff that is very specific to the vertical that they're in.

Starting point is 00:27:55 If you're building a time tracking system, there's a lot of custom code around a mobile app where people clock in and clock out. And you have some geolocation services that people can use to limit where they can do that. A few other things are very specific to time and attendance. But then there's a lot of the stuff is really about how do you build a policy for calculating overtime? The basic code for that and the basic way you think about that is really fundamentally not so different than how you build a policy. policy for who's allowed to spend money under what circumstances and when is approval required and when should you block the transaction entirely? And you need a lot of reporting capabilities to understand where's waging an hour stuff going? What are people working on? Who's using more

Starting point is 00:28:40 overtime than they're supposed to? What are costs doing by project, by location, by manager? And again, like those concepts are very similar to what you might see with a spend management system. And so a lot of these applications, it's about taking the same fundamental concepts, the Lego building blocks, and remixing them, and you get something very different as an output. And so as a result of that, I think that you can build better products with much less engineering investment. And the products are better because the primitives are better. The capabilities are better. The underlying middleware is all extremely configurable. We know that people are going to want to build custom reports and custom approval workflows and custom policies, whether it's an policy

Starting point is 00:29:24 for overtime or a break policy, or it's a policy for who's allowed to spend what money or what approvals required or cross all of these different product areas and verticals. And those are, by the way, of course, buying process, most buyers, those are the things that they care about. What happens is particularly in these software verticals that are very competitive and start to get highly commoditized. What happens is the competition shifts to a different level. It shifts to what are your reporting capabilities? What types of workflow automations do you have?

Starting point is 00:30:00 How do role-based permissions work? Because in my organization, that's going to be critical. And that's the stuff. Those are the reasons that buyers buy one product over another. Ripling has moved into a lot of areas that people think of as really competitive. You've had on your podcast founders of a few different companies that are basically building corporate credit cards and spend management. That's true for a lot of the other areas that we go into.

Starting point is 00:30:27 Part of the thinking behind this, we love going into competitive and commoditized markets because we think that those are the cases where we win. You go into these competitive markets and there's all, already a very clear product spec. You understand there's something that's working in the market. The competition has forced some kind of convergence around what is it that customers need. And so the stuff that we need to build that's specific to this market or this vertical, we know exactly what we need to nail. There's no question about it. And then in that market, once we launch, Ripling is the only product that's not a commodity because we have these

Starting point is 00:31:10 unique and differentiated advantages in the form of our platform capabilities and the integration with Rippling and with the employee data, the inside of Rippling that creates this highly differentiated and much better product experience in the land of the blind, the one-eyed man is king. And so for us, we think that in these commodity markets, we're the only product that's not a commodity and that's highly differentiated. Are there conditions in which you would turn all of this over to, an open market and effectively build a Rippling app store on top of Rippling in the way that Shopify has, for example, where Shopify still owns a key core product that they build and

Starting point is 00:31:49 control themselves, but there's tons of actually quite big businesses that are just effectively Shopify apps in the same way that Apple had an app store. Is that concept interesting at all to you, given the amount of infrastructure you've built? Yeah. So there's a lot of it that we do today, and there's some stuff that we might build over time. What we don't do yet, which I would like to do over time, is expose a lot of the underlying platform capabilities to partners. There's challenges in that, because for partners, you've got to do it in a way where they don't feel like locked in. But certainly we have an app shop today, and we have partners in that app shop that compete with our specific products. And we just talked about TNA and Spend. We have our own

Starting point is 00:32:30 time tracking product. And we also have really great integrations with T-sheets, with deputy, with When I Work, which are point solution competitors in that space. We have our own spend management product, but we have a very deep integration with Brex as an example. That's a really meaningful partnership for us. One of the things that's interesting is not only do we have an integration with these guys, but we also do things to try and cross-sell their product. and we have rev share arrangements and things like that with Brex so that when people buy Brex, we actually also quota our sales team on selling Brex, just like we quoted them on selling our own spend management product. We do cross-sell in this really interesting way.

Starting point is 00:33:14 Cross-cell motion is one of those areas where we ran into this naughty bottleneck, where all these products were starting to compete for resources. It was hard for people to get attention from the team that was thinking about cross-sell because there were 20, other skews that we're fighting for that same capacity. And so one of the things that we've started to do is just break apart these cross-sell capabilities so that basically teams internally at RIPLAin can create cross-sell campaigns as if there was an internal ads marketplace. Let's say a company has an employee that's on parental leave, and you're responsible for

Starting point is 00:33:52 our integration with TILT, which is a parental leave vendor that is a product that is about to go live. You can say, hey, look, when a company has an employee on leave, you probably want to target something at the payroll in HR admins for that company and say, like, hey, are you managing parental leave? Is it really difficult? You should try out till we do the same thing with Brex. And so Brex is right alongside our own native product in terms of, and the system sort of makes decisions based on a lot of the underlying data and understanding that we have about that company and its employees about expected conversion. We can identify. We think this company, needs this product. And in fact, this specific person within this company needs this product right

Starting point is 00:34:32 now. And sometimes it looks at that and it says, you know what? We think that actually based on our historical data, they need Brex more than they need our own spend management product. When I was young, I played a lot of video games. And one of the fun concepts in video games is this notion of speed running, trying to get through Mario or something as fast as humanly possible. As I've read a lot about rippling, in some senses, it feels like rippling a speed running B2B software and is able to move at a clip and at a pace that seems almost unnatural from the outside, which makes me wonder what it's like working there and what you've learned about the kind of people required to move with this pace because it feels like speed is an enormous advantage

Starting point is 00:35:13 for new businesses that huge incumbent platforms can struggle with at times. I'd like to hear your philosophy of speed and the kind of people that can run at this pace for long periods of time without burning out? First off, I think it's important to say that I'm tremendously impatient and I like moving quickly, but I think at Rippling, that is always paired with a deep commitment to the quality of the products that we're building. I think that speed and quality are not in opposition to each other because a lot of companies move very, very slowly.

Starting point is 00:35:48 And usually companies that move slowly, when they do finally launch something, it usually still sucks. I found that speed and quality are correlated. Quality is often about having a lot of urgency to address underlying product flaws and issues. Being slow moving in addressing the issues with your product is not a virtue. But I did just want to call that out that I think that it's a commitment to speed and quality or maybe even a commitment to quality through speed in the products that we're building. I think we're a pretty fast-moving company. I'm glad it looks that way from the outside. I would like to be moving more quickly than we are, quite frankly. Of course. I'm curious, as you think about what ultimately drives all this for you personally,

Starting point is 00:36:36 I'm always fascinated by motivation of founders and what keeps them doing what they're doing for long periods of time, especially those that can work for decades on a problem. How do you think about that for yourself and managing versus harnessing sources? of motivation for you? And how do you think other entrepreneurs should think about this? I have some sort of unusual motivations for the company. And I think a lot of this stuff gets more complicated and mixed up as time goes on. And there are a set of motivations that I have that I think are ones that are shared by everyone else in the company and there are ones that are very specific to me personally. And part of this, I really borrowed from my COO. And one of the things that he says is he

Starting point is 00:37:14 says, I view this as a sport and this is a sport that I'm playing and it's really fun to play this sport and you want to win and you want to be good at it. I have really bought into that. Working together to sort of win at this stuff is really fun. I really enjoy the people that I'm working with. I really love the product that we're building. I am deeply resentful of the administrative work that is irreducible and inherently built into running the company. And a lot of that ties back to this idea of employee data that's fragmented across the organization and update all these different systems whenever anything changes and the lack of connectivity between all these different business systems. And so I think that Rippling is stomping that out

Starting point is 00:37:57 for everybody else and that I take a lot of pleasure in doing that. Some of the motivation for me is definitely that my last company did not end for me on a high note. And it was just a deeply upsetting, deeply depressing, awful time for me personally. There were a specific set. of individuals. It was, you know, David Sacks, who was my C.O. who took over a CEO. And the first thing that he did is he hired this guy, Lanny Davis, who's this PR hit guy, and spent six months, rather than trying to work on the business, he spent those six months basically just pitching reporters every day on pieces about me. And And Andreessen Horowitz and Lars and Ben Horowitz followed that same path. I was really restricted legally and otherwise on

Starting point is 00:38:47 what I could say or what I could talk about. And David is an incredible polemicist. That's the real strength. But that's not my strength. And so I was never good at the media thing. And I was depressed and hiding in my basement and not really talking to anyone. Watched with growing horror as this media narrative about Zenefits unfolded in front of me and felt really powerless to do much about it. When I left Zenefits, I was forced out of the company, but at the board meeting and what was pitched to me by Ben Horowitz and Lars, everyone was like, hey, look, we want you to stay on the board. We want you to run product. We want you stay involved with the company. We're going to bring David in. He's going to clean up some of these issues in six to 12 months for now. We want to bring

Starting point is 00:39:36 you back as CEO. And I had had this experience of being at a company staying around after I was on the outs. And I said, look, I'm out. We drafted a joint. press release. The idea was there was this friendly press release where I said nice things about them. They said nice things about me. And we had this joint press release ready go. And then what happened is the day the announcement came out, David hit send on a different press release that said Xenefits has all these compliance problems. And it's because of this guy, he doesn't care about compliance, which was just not true. What I realized after a point in time was that David was not actually trying to make Zenefit successful. He was really trying to burn the company to the ground

Starting point is 00:40:15 in order to get this mantle for himself that was him as the sort of white night of compliance. And it worked extremely well. When he left, he's declared mission accomplished. Company's great and all of the compliance issues have been turned around. And of course, that was a lie. The company was a disaster when he left and was headed right into the ground. There was a certain point where I realized that David was not trying to make the company successful. I had this idea for where I wanted the market to go and the product I wanted to build.

Starting point is 00:40:45 And I remember talking to my co-founder, Prasana. And he was like, why do you want to build something that's in a similar space? And there are many differences from a product perspective, from approach to the market, otherwise between rippling and Zenefits. But the fundamental idea of employee data as this primitive for business software writ large, that was a kernel that was definitely there towards the tail end of my time at Zenefits. And I remember telling Prasana, no one else is going to do this if we don't. There's $100 billion sitting right over there on the floor.

Starting point is 00:41:15 And nobody else can see it except for us. And all we have to do, we know exactly what we need to build. We know exactly what the market wants. All we have to do is have the spine and the fortitude to walk over there and pick it up. That's what we need to do. That plus the fact that there was a point where I realized that the only way for me to talk to my former colleagues, to my extended friends and family, to the tech community at large, to the media. The only way for me to do that, because I wasn't going to be the guy that was going to be sophisticated at going to toe to with Sacks and Lanny Davis in the media, the only way for me to do that was to build this specific company and turn it into a $100 billion outcome. And if I did that, that would force some kind of reassessment of all of this stuff. For a long time, like early on, building a startup, it's a real grind for a long time. for years, that was what got me out of bed in the morning. But yeah, over time, that fades into the background. And the stuff that we're building is so much fun. And I love the problems that we're working on.

Starting point is 00:42:24 And I really love the team and the people that I work with. And so that dominates a lot more today than it did back when I got started. I have no experience like that. But when you do a bunch of stuff in public, I have certainly been through examples of people saying very mean things about me that aren't true, that just are objectively wrong and not true. So often you find it the case, what you see on the outside is often the opposite on the inside to what public perception might be. And I always find it interesting how much some of those things hurt, like really, really hurt, despite them clearly not being true. It does not square with reality, but reality is of no comfort.

Starting point is 00:43:03 Somehow, still the negative things are painful. Do you foresee a time when it's not painful for you? Do you think that there's an end to that pain and maybe even on the other side of that some deep form of forgiveness? Oh, man, I don't know. The problem is you can never get that stuff back. You can't get those years of your life back. You can't get that stuff was destructive for me.

Starting point is 00:43:31 But what was hardest about it was how destructive it was for the people around me, that it was destructive for my wife, that she would get asked about this. job interviews. We would go out for coffee and people would be snapping pictures, posting it on Twitter at the height of this stuff. People found out where we lived and we're leaving weird quasi-threatening notes at our house. It's like that kind of stuff, that's really hard to move beyond because the thing is, it's not reality and the problem is that it is. Whether it's true or not, it is reality. That's the difficult thing about that stuff when it gets really bad. and really public.

Starting point is 00:44:12 Given how deeply personal and ingrained you are in this business, one of the things I'm always fascinated by is the intersection of leadership and communication inside of the business. You talked earlier about something unique about Rippling, which is that a lot of this stuff is self-sufficient, meaning there's not a lot of bottlenecks. We've got this incredible infrastructure that lots of different teams can access, they can work together, things move quickly. Just to be clear, there are tons of bottlenecks. Of course, fewer than normal.

Starting point is 00:44:39 But everywhere you find one, we're trying to fix them and unlock them. I always love this idea of in software you end up shipping your org chart. The way that information flows through your company is often reflected in its products and its culture, et cetera. What have you learned about great communication in especially a very fast-growing headcount number? You mentioned 1,700 employees. How do you think you've gotten better at being a good communicator as a key part of your, job as the leader of the business? Some of it is talking about the bigger picture, this idea that the ways that we think about employee data and how it ought to sort of impact all of these

Starting point is 00:45:23 other systems and the way we think about the middleware and how that ought to work and the way that we build and don't build the applications on top of that, if you're a team that's building a new application and there's a capability that doesn't exist in one of our underlying components, everyone's first instinct is go roll your own that has just your specific use case built into it, but we always force people to either build those capabilities down into the underlying systems or get the teams that own that to do it. Talking about that framework and that idea, that's, I think this big picture vision piece of it, but then a lot of it is extremely tactical at the level of product feedback using the product

Starting point is 00:46:04 and why doesn't this work in this way and why can't I do that. we're about to publish internally a set of leadership principles for Ripley. My favorite one is the first one, which we call Go and See. One of our expectations is that leaders go really deep, right to ground, particularly when anything goes wrong. And one example of that is that use and run our product for our company every day, but there are a zillion other examples. Albert Schrasheim, who recently joined to lead engineering at Riplane, he's running an 800-person

Starting point is 00:46:35 engineering team, GitHub pull request data is pulled into the Rippling employee graph. And so for our company, we can build a report that shows GitHub check-ins by engineer, by team, by manager over the last 90 days. What's crazy is when you do that for the engineering org, Albert's right in the middle. And he runs this entire team. That's how deep into the weeds of this stuff he is across this stuff. And when things get screwed up somewhere in sales where something's not working right. The first thing that I talk with Matt Plank, who run sales for us about, is how many

Starting point is 00:47:12 gong videos have you watched of the reps in this segment to see what's going on with their customer interactions? The answer needs to be 10 to 20. You need to go all the way to ground. And the answers to problems when they come up are rarely data or spreadsheets or charts. The anecdotes are so much more powerful when you can go around on this stuff. The story has hasn't ended yet, and it's not clear whether they've been totally successful in the end. It's always weird when those people have management philosophies. I'm not sure if I have the right to have a management philosophy. I'm just going day-to-day and try and make this thing work.

Starting point is 00:47:49 One of the things that I found it works well for me is to really go get super nitty-gritty in the details as opposed to high-level and big picture and to expect everyone in the company to do the same. This is an idea that I'll definitely take away from this, which is this funny paradox that By doing stuff like that, which is fundamentally non-scalable, you might actually be increasing productivity because there's more value in the anecdote than in the dashboard, so to speak. It'll help you get to the problem more quickly. How deliberately do you think about or measure per employee productivity? That seems to be another popular thing in the discussion today.

Starting point is 00:48:26 Today is the day that Elon Musk took over Twitter. There's a large reduction in force that's expected there. There's an emerging meme that technology companies have two to 10 times more employees than maybe they need to deliver their service. So it seems like this per person productivity is going to become a hot button issue. Do you think a lot about that? Is that a metric that gets managed at Rippling or should be? It's really hard to come up with a metric on. The thing that's always worked for me on this is making sure that the people at the top of the org chart are operating at the ground level. day to day. So it doesn't mean obviously, you have to be able to go all the way to ground on a problem when you see it. And then I think when you do that, it's those anecdotes that give you a

Starting point is 00:49:10 lot more insight into what the problem is. And maybe the problem is that you have a team where the output is just not very strong. It's rare that I think you see that in the data. And it's much more common that you see that by getting on the ground floor and looking through their code or going through individual support tickets or individual prospective customer interactions, looking at 20 of them until you start to see a pattern and can diagnose the problem. And the reason that this works is that looking at data, if you're producing exactly the right data that reveals the specific problem, which usually only happens if you already understand what the problem is. And if all you know is that something's not working, you don't have enough context when you're

Starting point is 00:49:51 looking at data across the org to know exactly why it's not working. And you've got to go all the way to the bottom to understand what's wrong about the way that we're interacting with our customers or our prospective customers. Like, why have the closed rates dropped? And then you go and you look at that and then you can start to see, well, you know, is it the reps? Do we make hiring mistakes? Do we need to go back? And then look at videos of the interview panels that we did and understand why did we hire people that we shouldn't have hired? Is it, are people not picking up on the training? Is there a product issue that we haven't seen that we need to address? Is it management, is it discipline around pipeline? And that's how you start to figure out, like,

Starting point is 00:50:32 what's the issue and find your way through the problem. My friend Ravi Gupta, Sequoia, turned me onto this great idea around focus, which was focus isn't focus until you're saying no to stuff that you really want to do that are really good ideas. I think you got it from Steve Jobs or something. I think there's a corollary around the idea of perseverance and grit. In the same way everyone says you need to focus, everyone says, yeah, key to successes, perseverance and grit. But to me, the definition of that is something where you did almost break, but you didn't and you kept going. If you go back to day one, the day you founded Rippling through to today, what do you think the best real on the ground example of something that required true perseverance and grit because

Starting point is 00:51:12 it did almost break you or the team or something like that? Honestly, there's nothing at Rippling because the worst day at Rippling was so much better than all of the bad days that came right after my last company. one thing that I got to do, which I don't recommend to other people, is I got to effectively build in a similar space twice. And I don't recommend it because it's much better if you don't screw it up the first time and it works. And then you don't have to go do it a second time. But for people that do go back and I can't think of a lot of others that have done that. For me, being able to build the same company all over again, to your analogy of speed running through it,

Starting point is 00:51:54 it felt a lot like I had seen this movie before. At Zenefit, it felt just constantly terrifying because we were growing really quickly, and I didn't totally understand what we needed to do or what was going on with. It's hard to keep up with the pace of the company's growth. But the second time around feels a lot easier because you've seen a lot of this before. Rippling's grown quickly, but nowhere's near as quickly as we grew at my last business. In a lot of cases, it's like maybe playing a video game on expert mode and then slowing it down to normal and it makes it feel suddenly a lot easier.

Starting point is 00:52:28 You said something earlier which fascinates me, which is the headcount at Rippling that were former founders themselves. How would you describe the keys to successfully recruiting former founders to come join you? Well, the thing that we offer former founders is that we say, look, you're going to do this again. So you're going to effectively start a business within Rippling. These teams early on, one thing we do is we don't. don't give them any access to our recruiting early on.

Starting point is 00:52:58 So interesting. Right before launch, for the first three to four people, they need to recruit all of those engineers themselves through their personal network. I think it's a real crucible that we expect people to pass through where it's like, look, if you're going to do this, it's time for you to call in every favor, to go after every friend. You need to be able to convince them to come and join you. And like, if you can't do that, you're not going to be able to lead and run this thing.

Starting point is 00:53:25 And so that part of the experience is similar to starting a company. But they obviously, you don't have to worry about fundraising. There's no, like, Democles hanging over their head about running out of cash and not be able to make payroll. There's a lot of infrastructure that they can both company infrastructure, but also software infrastructure that they can build on top of. And most importantly, most startups are really solving for this problem of the field of dreams, problem. If you build it, is anyone going to show up? How am I going to find distribution for this thing? And you can build a great product, but fundamentally, it's not great in a way where there's some inherent distribution advantage that you have, and you're screwed. Everything about starting

Starting point is 00:54:08 the company needs to be oriented around distribution first. With the products that we build in RIPLane, people can focus on building really great products. And they have to build them with the market in mind. That's not out of sight, not a mind, but we can point a fire hose of customer demand at these products if it's a really great product. You know, what we can tell people is that if you come and work at Ripley, that field of dreams thing really is true. Like, if you build it, they will come. We will bring them. I love the idea that you're financing and distribution as a service for founders. There are two pretty big components of building something big. That's right. Yeah, of course. What do you think the role is that investors should play in companies like yours?

Starting point is 00:54:52 Like, you've dealt with a lot of investors. You've had some good. You've had some bad experiences. Some of what you've talked about on the good side of the ledger, what do you think good private equity investors do? What is their job, in your opinion? My views on this, they're evolving. There have been cases where some of our investors have been extremely useful in ways that I did not anticipate. came to Ripley and started a company with deep conviction that none of these guys were worth anything.

Starting point is 00:55:25 What you wanted from investors was money and nothing more. Money and Brandt. Because the signal really matters, and it matters for a lot of constituencies, whether it's customers or prospective employees or whoever. And I still believe this. I think the idea of investor value add is extremely dangerous for companies. almost all of the time, investors that try and add value are going to destroy value within the business. Certainly, now is true with my last investors. I think that there's something very dangerous about an investor that feels like they're supposed to be adding value because they don't understand anything about your business. They spend a few hours three or four times a year thinking about the company and that's really it. But often, the investors are people who believe themselves to be really intelligent and knowledgeable people about the ecosystem.

Starting point is 00:56:19 As far as large started success factors, Ben Horowitz has gotten pretty illustrious career. In retrospect, everything that they told us to do was wrong. If we had just done the opposite of everything that Andreessen Horowitz told us to do, it probably would have been a really successful company. It's not their fault. It's just investors are often fighting yesterday. war. When Zenefit started, there was this broad consensus among investors that companies in the 2000 to 2012 cohort had really underinvested in sales and marketing, that these businesses could have grown so much more quickly than they actually did, and that the markets were proving to be

Starting point is 00:57:00 much larger than anyone believed, and that the right answer was that you needed to step on the gas way harder. And so as a result of that, what they did. did at Zennephits is just by default, orienting themselves one standard deviation away from their founders and CEOs in terms of how aggressive they thought you should be in stepping on the gas. I showed up after Andrews-Henhorowitz invested and I said, we got a plan. We're going to go from 1 million to 10 million this year. And they said that bullshit, what's wrong with you? Why aren't you growing to 20 million? The problem was is that temperamentally, it just so happened that I was already so far out in terms of how much I wanted to push the company to grow. And I don't think they understood

Starting point is 00:57:45 that. They were just reflexively saying it should be more, more, more. Without having any understanding of what was going on inside the company, a lot of their advice ended up being wrong. And so investor advice, I think, is really largely useless about anything other than capital markets. Their advice about the capital markets is extremely, you know, you want to ask your investors, is this business investable? Is it investable if we do this? Is it investable if we do that? Because they understand that a lot better than you do. And about everything else, the advice is not super useful. But I will say, like, some of our investors have been incredibly useful, really dug in and helping with recruiting and building out the executive ranks, the company. And there's really something to that. I was a lot more skeptical of coming into this.

Starting point is 00:58:31 Parker, it's not often that I encounter totally new idea to discuss in one of these conversations. I think this whole notion of a compound business is one that people listening will be thinking a lot about. I think I love the idea of these existing sort of right over a horizon of opportunity land, so to speak, when we've picked over the stuff that we can see easily. I thank you for all the different ways of thinking about this idea and everything else you built at Rippling. The traditional closing question that I ask everybody is, what is the kindest thing that anyone's ever done for you? There were a set of people that reached out to me when things went really south. Some of them are current investors in Ripley, and some of them not.

Starting point is 00:59:10 But there were a set of people that reached out when it was really not a popular thing to do and were just like, hey, we really believe in you. That meant a lot. And quite frankly, some of them reached out and I didn't even respond to them. I was not in a place where I could even acknowledge it. But it really meant an enormous amount to me. They know who they are and I'm just deeply appreciative of it for all of them. Fantastic place to close, Parker.

Starting point is 00:59:36 Thanks so much. Cool. Thanks a much, Patrick. If you enjoy this episode, check out join colossus.com. There you'll find every episode of this podcast complete with transcripts, show notes, and resources to keep learning. You can also sign up for our newsletter, Colossus Weekly, where we condense episodes to the big ideas, quotations, and more, as well as share the best content we find on the internet every week.

Invest Like the Best with Patrick O'Shaughnessy - Parker Conrad - Building a Compound Company - [Invest Like the Best, EP.303]

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.