No Priors 第122期｜对话 Rippling 联合创始人兼 CEO Parker Conrad

[Applause] Hi listeners, welcome back to No Priors. Today I'm here with Parker Conrad, co-founder and CEO of Rippling. Parker needs no introduction as one of the most admired founders in Silicon Valley. We'll talk about his founder redemption arc, why the conventional wisdom is wrong and the biggest companies are actually platform companies, the future of the SaaS industry in the age of AI, leading teams with ownership, how he thinks about going public, and why you should only start a company if you have no other options. Welcome, Parker.

Thanks so much for doing this.

Yeah, thanks for having me. I think there’s a very apt phrase: the best revenge is massive success. What do you think you got wrong at Zenefits that you’ve done differently at Rippling?

In some sense, there are some superficial things. But I think mostly Zenefits failed for dumb reasons, and so I don’t think there were a ton of lessons. There obviously were some specific things that led it not to work that you want to make sure not to repeat. We’re extremely careful about compliance at Rippling, and regulatory compliance in particular.

At Zenefits, we leaned way too much on ops. I think Rippling has, as a result of that, maybe just a deep aversion to it—and maybe actually to our detriment in some cases—where we perhaps should be willing to do things that don’t scale a little more. But we tend to go really deep with software and not take on operational builds and overhead. Those are probably the biggest differences.

There are probably some other things that I took away from the experience, but they’re much more general. For a long time, early on at Rippling, I felt like it was much easier to manage my own psychology on this stuff. It’s just really hard. I always found it personally—maybe I was just not cut out for this—but I always found it very hard to deal with the psychology of running a company and the big ups and downs.

At Rippling, it was a lot easier because no matter how bad things got, I always had this thing where I thought, “Oh man, this just pales in comparison to how bad things were right at the end and just after I left Zenefits, when things got really very dark.”

There’s this idea in Silicon Valley that you should learn a lot from failures. I’m not sure I agree. I think people probably learn a lot more from their successes. Companies fail for many dumb reasons, and it’s really hard to take a lot of lessons away from that. You probably learn a lot more by being at a company that’s working and seeing how it works.

I remember talking to you during that period, when you were just starting the company, and I think you said something to me like, “Starting a company sucks,” especially when you weren’t in Silicon Valley’s good graces. You were fighting a big reputational battle, and you described it as, “You’re just sitting in your parents’ basement again, and nobody believes in what you’re doing. That sucks.” What made you do it anyway and start over?

I felt like I didn’t have a lot of choices, to be honest.

You weren’t going to work at Google.

I mean, I didn’t have an offer. I was probably pretty radioactive, and I think it would have been hard for me to get a job.

I’ve started 3 companies. I started the first company because I was naive and didn’t know what I was getting into. I started the second company because I looked around, and I’d been at the first company for 7 or 8 years. It was sort of worthless from a résumé perspective, and I was totally unqualified for any job that wasn’t entry level, other than maybe starting another company. I felt, “Crap, I guess I’m doing this again.”

The third time around, it really felt like there weren’t a lot of other options. This was the one path that I saw where maybe there was a narrow ray of light. When it felt like I was being buried reputationally, I thought, “Okay, if I could build this specific company and make it really successful, maybe there was some future world where there would be a different story or narrative, or a chance to tell my side of the story.”

In learning from the success, and as far as Rippling’s scale today, what have you learned about founder psychology for yourself, beyond perhaps, “You could go through a really bad crucible and just assume it’s not going to get that bad again”?

Generally, people come to me and say, “Starting a company—do you have any advice? What do you think about?” My advice is pretty much always, “Don’t do it,” because there are a number of reasons. Most people are likely to fail, and I think that failure gets glamorized inappropriately, or just incorrectly, maybe.

You don’t actually usually take away a lot from failure, and it’s extremely destructive. It’s destructive to your psychology, your marriage, and your relationships. It’s really hard. There are a lot of costs to doing this that, in most cases, are not worth it. That’s why I tell people they probably shouldn’t do it.

Nobody ever follows that advice, of course. If anything, it redoubles everyone’s resolve. But I do think that’s the case. I don’t have an answer for the psychology piece. There are some people who are just better at it than I have been in my career.

I think of you as one of the nicest angry people I know. But I remember I saw you maybe a year back, and you told me—you told me you were worried you weren’t angry enough anymore to make Rippling as successful as it should be. Hopefully this is okay to say, but I just burst out laughing and said, “My friend, don’t worry about this. No one else is worried.” Do you think being angry is important?

I don’t know if being angry is important, but I think that, at least early on for the first couple years of Rippling, there was this idea for me personally that this was the only way and the only thing. This focus was the first thing I thought about every morning when I got out of bed; it was the last thing I thought about when I went to sleep, and it was the thing that got me up in the middle of the night.

I think that was extremely motivating—not maybe super healthy. It got me through a bunch of difficult years and a bunch of grind, because it is a grind for a number of years.

Since then—I don’t remember this conversation, by the way—but there are a lot of other motivations. I really love the product we’re building, and I really like the people I work with. There’s a lot that I enjoy about work, and there are a lot of other positive motivations. But the nature of some of that other stuff is that it starts to fade over time. That’s just the reality.

Has the ambition of Rippling changed over time? It was always a wildly ambitious company. You were like, “Don’t worry, we’re going to take HR and IT and identity and do all of it at once from the beginning.”

I remember talking to one of your early engineers in the first—I don’t know if it was the first real office or the first office—but he was just like, “Yeah, we’re going to do Salesforce.” I’m like, “Salesforce took a long time to get there.” And he’s like, “We’re going to do it all now.” Do you feel like the ambition is the same, or is changing ambition part of that?

We’ve probably gotten better at articulating how we think about it. It started out with this belief that all of these ideas people had—that the way to build great products was to focus really narrowly—were wrong. Actually, the right path was to try to build a coherent product suite of seamlessly integrated and interoperable applications.

At first it was just, “No, no, no, we’re going to do HR and IT,” and there were these other things on the roadmap, like finance and stuff like that. Over time, we probably got a little bit better at articulating why that was.

I think the best way to express it is that people get software wrong. Historically, we’ve been building software in a way where, if you focus really, really narrowly on a very specific domain or application area, people think you can craft these artisanal products and experiences that way.

The problem that you run into is that ultimately companies end up having a lot of different applications, and that creates a lot of problems for them. But also, these artisanal software companies really can’t afford to invest in a set of underlying capabilities that are ultimately what make these applications powerful for their customers and that end up being repeated across a lot of these different application areas.

So, things like permissions, reports and analytics, workflow automations, and approvals—there’s a set of underlying capabilities in business software that end up being repeated and relatively conserved across this broad array of domains. If you’re building a lot of applications, you can afford to invest much more deeply in those areas and make what are ultimately much better experiences for customers because of that.

You simply can’t afford to make that R&D investment if you’re building just one thing. And if you look back, this isn’t really a new idea. It’s an old idea that’s coming back again.

This is the way Oracle, SAP, Salesforce, and Microsoft were built: the idea of building what they would call a platform, this underlying set of capabilities that you then use in assembling all these different applications. That kind of articulation came later, but I think the fundamental idea was that the company was deeply committed—religiously committed—to building software in this way right from day 1.

So that’s not been, as you mentioned, the conventional wisdom in building software startups for maybe a decade and a half now. Why do you think people miss that? Because, as you say, some of the biggest software companies for a time—and I’d add Epic to that list—were some of the biggest and most powerful companies. The reason they are so powerful is because they work in an integrated way and they have a lot to sell their customers.

I have a hypothesis, and I was wondering if you do. I think it’s because the platform shift from on-prem to cloud created a bunch of base-hit opportunities with SaaS, where you could peel off one application area from these big on-prem providers that just took a long time to move to the cloud and get that really stood up.

You could very easily get a lot of traction with something that was extremely narrow, and that was good enough for a period of time. I think what happens is, over time, the bar goes up in terms of what you need to be able to do for clients. It’s no longer enough to have a standalone SaaS application. You need these other capabilities, or these deeper capabilities, and that forces things back together.

I think that’s where we’re going right now. It’ll be interesting to see, with AI, how AI changes that. Some people would argue that AI is a similar kind of shift from on-prem to cloud, and I probably don’t agree. I think it’s actually probably more centralizing as a technology. But that’s my view on what triggered that, at least for a period of time.

I think that’s right. I also think that the latter half of the SaaS revolution coincided with a massive bull market through the 2022 period. If you had internet distribution of software to mid-market companies that could buy online and rapidly, then—Rippling might be the exception to this—selling point solutions was faster than getting people to shift core systems.

You could start selling with much less product. I think you guys worked on Rippling for a while with a lot of people before you really had something to sell. So I think it’s also part of the investing cycle, in terms of how quickly people expected progress from the investing community.

I think some of that is the nature of the bar-raising. There was a period of time where, if there was no SaaS application for, I don’t know, time tracking or expense management, you could build a standalone thing for that and it would get very rapid uptake.

But as soon as you start to get the bigger core systems where that now just comes standard in SaaS—in the cloud, not on-prem software—suddenly it’s not good enough anymore. There’s a window of opportunity that closes over time, but eventually you need to find new islands of product-market fit that are a little bit further out, maybe over the edge of the horizon.

I think that tends to be something that solves a bigger and broader class of problem for customers. It usually requires you to take on a lot more in order to solve problems that are often about internal business-process coordination, which cuts across a lot of these different applications. It’s a lot less work for customers, ultimately, to be using one thing.

How do you organize at Rippling, given the platform and broad application surface area? I’m sure this has changed over time, but you don’t have many contemporary companies with a similar strategy, and you can’t say, “I’m going to do what Microsoft does” at this scale.

We have teams that build capabilities that are the platform teams, and then we have application teams that are building applications, hopefully out of those underlying platform capabilities. I think it’s really important to have the right leader for these application teams. Former founders are great, but you also need people who can scale over time as the product grows.

Ideally, you want someone with real ownership of those areas who can drive them, because otherwise you get this bottleneck at the level of executive attention. If I have to drive it, I can only do that for so many things, and inevitably a lot of balls get dropped.

You need people in seats who can really own it and run the business holistically—people who can think about the product roadmap, the marketing, the sales elements, the competition, the whole thing—and synthesize it down to, “Here’s what we’re going to do.” That’s always the most challenging thing: finding those people.

We try to hire a lot of founders at Rippling to make it work, but that’s always ultimately the bottleneck.

I don’t know a single founder who doesn’t feel like they could use more owners at their own company. Do you have any advice on how you filter for this?

In terms of filtering, I think it’s hard. People who have had that experience before are one thing. Sometimes it’s just having a conversation with someone: are they naturally jumping to conclusions and implications about the business and getting there on their own, or do you need to lead them there?

The difference comes out in quarterly planning. Some people show up to quarterly planning with a list of the things that they need to get done from a product perspective. The list inevitably unfurls and goes down the hallway, and some people say, “We’re going to do about 1 quarter’s worth of work. We’ve prioritized the list, and 1 quarter’s worth of work is this much of the list. That’s what we’re going to get done. That’s my job.”

The problem is that it’s now my job to make the ends meet, because that’s not going to cut it. We actually have to get a lot more done to make things work, so now it’s my job to figure out how we bridge this gap.

What you really want are people who are going to find a way, sometimes through seemingly impossible constraints. They understand that this is the reality—not that the CEO of the company is giving them an impossible task. The problem is that this is fundamentally the situation we’re in. This is the market reality. We’re here, we need to be there, and we can’t win unless we get there.

A lot of that is what you see at a startup, because running a startup is somewhere between completely impossible and very, very hard. There’s a very slim window between those two to make it out. Companies often have to find early on ways to do seemingly impossible things, and you need someone in these roles who’s going to find a way to make it work.

There’s the innate aspect—finding people with that mentality and ability and recruiting them—and then there’s trying to get people to act more like this, which I’m sure you do across Rippling.

When I was looking at the Series A, I called 20-some people who used to work for you. One of the things that was most universally loved was, “I would follow Parker to the ends of the earth,” because you got more out of me than I knew how to give in terms of my own capability, and I got more done.

What advice would you have for founders on making that happen?

It's an amazing skill. I'm not sure I'm great at it.

That's wonderful that you've sort of couched it.

I didn't say it.

There are probably other people who are like, "He just drives everything way too hard. Totally unreasonable."

Totally unreasonable.

Yeah, totally unreasonable.

So I have 2 thoughts on this. One is, I genuinely believe that people are usually capable of so much more than they believe themselves to be capable of. People grumble about the work culture in Silicon Valley being about this grind culture, and I think what that misses is that it's important to understand that it's not that I'm like, "Why isn't everyone in the office 7 days a week?" It's like, look, this is the situation that we're in, and it sucks.

The reality is that we need to find a way to bridge this gap. I can lay out the gap, and I didn't create the gap. Maybe you didn't create the gap either; it's just there. We can either give up and go home, or we can try to find a way.

Sometimes, when you lay it out for people, they can accomplish incredible things. Patrick Collison has this great site that talks about different organizations and how teams of people did the moon landing in 4 years or the Van Ness line in San Francisco in 12 years, or whatever it was. The discrepancy between how some organizations are able to do so much in such a small amount of time and some organizations are not is enormous.

Some people think that if they kill themselves working, it's an extra 20%. Actually, the difference between teams that can really accomplish a lot isn't 20% on the margins. It ends up being an order of magnitude in terms of what you can do. I think you've really got to ask for that and ask people to try to find that within themselves.

One very concrete example of this is that a lot of times, people like to come to CEOs with what I call CEO-in-a-box options. They say, "Look, you can have A or you can have B. Which one is it going to be? You tell us what the priority is." It's this sort of illusion of choice, where the important decision has already been made, because the important decision is A or B versus A and B.

So reflexively, whenever I get choices like that, I try to reject the premise and be like, "I want A and B. Why can A and B not coexist? Does it violate the second law of thermodynamics?" One way of looking at that is, "Oh my God, this guy is asking for something impossible." But sometimes the solution is just to think a little more deeply about the problem. Is there some third path? What's the creative approach?

Often, there is a real cost to making those trade-offs. If you can find a way around it, it can mean the difference between success and failure.

One thing that's striking to me is that there are a lot of very talented people at Rippling, but I think most people would be like, "Well, they're not all Parker Conrad," except that you are treating them like they should be, right? You're saying, "I think you can figure this out." I tend to expect a lot from people, but in reaction, I see people do amazing things. I wonder if more founders shouldn't try to have real belief that their people can figure more out, and we'll get a lot more from that.

For me, it comes from deep reservoirs of panic and insecurity about the company and the looming failure that's constantly there when you're building a business. The way to channel that productively is to push it down into the organization and lay out the situation for people. When you're facing tough situations, see if you can't get people bought in to, "Oh man, this is it—we've got to bridge the gap between point A and point B," versus, "I've got to do this task for the next month or the next quarter." You can get people to take more responsibility for where you need to get to.

I guess I would just posit that many leaders don't necessarily push that problem down into the organization because they don't really believe other people can solve it, right? And I think if they do, they'll get more back.

You have capability teams, and then you have these application teams. What is the cadence of communication and coordination there across such a big product surface?

I think that's an area where, candidly, we don't always get it right. Anyone who's trying to build in this way faces constant tension between people building at the application layer and people building at the platform layer, because the interface there isn't always clean. You get an application team, and they don't want to build on the platform team's stuff. They need something slightly different.

A lot of the really meaty product decisions end up being around that kind of stuff. When do you allow teams to disconnect from the underlying systems? When do you reprioritize the platform team to build the stuff that they need? When do people eventually have to migrate back onto the core underlying platform capabilities?

I don't know that there are good rules of thumb about this, because it's one of these problems where, locally, people would almost always prefer to disconnect. It's easier for them to just build their own thing. But ultimately, in the long term, it's the worst thing for the business and even the worst thing for their application, because you lose the benefit of shared investment in the underlying capabilities if you do this.

As the underlying systems get better and better, every dollar of R&D that I spend on the underlying stuff pays off 35x, because it hits every system in Rippling. Every system gets a little bit better because of the new capabilities I've built in the underlying systems. That's the dynamic—or really the underlying math—that I think makes this approach to building software work better than building narrow, focused point solutions.

You've got to hold on to that, which means that you've ultimately got to build on the LEGO blocks that you have.

It's very interesting to me. I was talking to Olivier, the co-founder and CEO of Datadog, which I think is one of the other true platform companies of this era. They bought a company that I was on the board of in a new space and then made them rewrite it over the first year and a half onto their platform. I don't think I'm exposing any secrets to say that it was a painful process. And yet, after that, all of the people from the acquired company were like, "We believe," right? There's a religiosity in that.

If you look at companies that at least got to scale in the last era and are still very dominant, like Workday, people tend to make fun of these companies that have, "We have our internal language, we have a bunch of development frameworks, we have a bunch of components, we have a platform team, we have applications," as being very insular. And yet, this is how some of the most dominant platforms are built.

I mean, Workday obviously won in the HCM industry, but a lot of the thinking around this comes from Microsoft. It's certainly the way they think about the world. There are a lot of big, even multicategory companies that think about the world in that way.

Rippling—I mean, we've been talking about a bunch of principles that are very specific to Rippling doing its own thing versus listening to conventional wisdom. How much do you think about beating incumbents in HCM or payroll or identity or whatever it is, versus capturing greenfield? What's your strategy internally?

The 2 things are related. A lot of the time, we can beat incumbents because we've pushed the envelope a little bit into new horizons. That allows us to solve problems for customers that incumbents can't solve.

Even internally, it's not always clear to me what the difference is for customers between new applications versus existing applications, or new features versus bug fixes. A lot of times, whether we categorize something as a fix or a new thing is about whether we internally believed that this capability was part of the original spec.

But from the customer's perspective, it's always just, “I wish it did this thing, and it doesn't do it.” So to them, everything's a bug. We're building a variable compensation product right now. In some sense, it's a new thing—a new application, a new SKU—but it also really helps if you're an existing customer. It's an existing problem that you have; you just wanted Rippling to do this.

They're kind of like, “Oh, yeah, this makes payroll easier because I have people, whether they're salespeople or other people, who are on simpler variable compensation structures.” A lot of businesses end up having bonuses, commissions, and things like that that are tough to manage. If you did it in one place, it would be a lot easier.

But to answer your question more directly, if you look at the headcount of the organization, over 80% of the engineering headcount is really focused on the existing stuff. Very little headcount is focused on building new things. Most of it is continuing to develop and extend all of the existing applications and the underlying platform of the system.

Some of why I think that is that you need fewer people when you're building something new, and you don't have any existing customers yet. You get to build on a lot of these underlying applications, so you can make it very far with a very small team. We always have 4 or 5 new things in the works, but collectively, the teams building those aren't that large. It might be 5 to 7 engineers on each one, out of an engineering organization that's now, I don't know, over 1,000 people.

I'm going to use this as a chance to talk about AI because we're not going to get away without that. We'll start with engineering: an approximately 1,000-person engineering team, right? Do you believe in the premise of doing a lot more with many fewer people over the next 2 years in engineering?

I am very skeptical that AI will be employment-conserving. In basically every area, we have not seen—and I think most large engineering organizations have not seen—a huge number of efficiencies from these coding assistants that are very popular with engineering teams. There are clearly some ways that they help, but it's not like we're saying, “Oh, man, we need so many fewer people to do this.”

It could be that we're just not very good at using them, but in talking to a number of other late-stage companies, I think that's been true for most of the organizations I've spoken with. I don't know quite why that is, and maybe it will come. But even then, I think that if you make it easier to build software, the demand for software will actually go way up.

I actually think the same thing is going to be true for customer support, which is the other major area of product-market fit here. As you make it easier for customers to access something that feels like support—where the experience is really good and instantaneous, and it's not frustrating because it takes a while to communicate something, there's a lot of back-and-forth, and maybe the person doesn't know exactly what you're asking—I think people will use more of that, not less.

Even as ticket-deflection rates go up, we see, at least internally at Rippling, a lot more use of our AI-enabled support tools. It's clear that people have found that this is an easy way to get things done quickly in the product, and so they start using it a lot more.

On the engineering side, one theory I have is that if and when it gets to a point where it's much easier to build software because engineers are so much more productive, what's going to happen is that, rather than needing way fewer engineers, a lot of these core software systems are going to end up getting highly verticalized. You're going to end up having Rippling for ophthalmology clinics, where there are going to be a lot of specific capabilities in the system just for ophthalmology clinics. That's going to be possible because it's a lot easier to build applications much more quickly as the cost comes down.

Unlike people who are building independent vertical software, if you're a company that's actually building, “Hey, we're Rippling for ophthalmology clinics,” the challenge is that it's really hard to have all of the underlying platform capabilities that you need in that system. Some of the challenges with vertical software historically have been that you have this choice between something heavily customized for the industry but missing a lot of core underlying capabilities.

If you're a company that needs something serious, eventually you need to move to Salesforce or something from the thing that's very industry-focused. I think what will happen is that, as the cost of building applications comes down, it will let the core companies build a lot of industry-specific vertical applications.

This is a long way of giving an example of why I think that if you and your small team can vibe-code an application that gets a lot of distribution very quickly, so can a lot of other people. Inevitably, the bar will go up in terms of what customers expect, and it might not happen immediately. You might be able to get, for some moment of time, a lot of distribution very quickly, but eventually there are going to be competitors, expectations are going to go up, and pricing is going to come down.

The frontier is going to move out, and you're going to need to be there. That's going to take people. It's going to require more engineers and more investment at the bleeding edge of whatever is possible.

The same thing will be true on the go-to-market side. It will become harder to make progress through the market, and you're going to need teams of people who can interface with the world, talk to customers, and talk to decision-makers. Those people may be more productive because some of those interactions are handled or enabled by AI, but you're still going to be competing against a set of businesses that also have all of those efficiencies.

As a result, it's going to be that much harder to cut through the noise. There's always going to be a frontier that you're going to need to play at, and that's usually going to require investment and headcount.

I think I see the race the same way. For some set of industries, there are going to be workflows that are different enough—maybe not around people, but around go-to-market. Pharma is the classic example, right? If you're designing around a regulatory regime, maybe that is different from Salesforce enough.

I think there's 1 version of more verticalized companies that ship something that won't work for customers forever, and then they're investing backward in capabilities in a race against companies that are more horizontal. The other version—and now I'm talking my own book, because I think there are portfolio companies that are doing well in this direction—is that they don't really look at themselves as software companies in the traditional category sense. They look at themselves as doing more of the work that people used to do.

The horizontal players will clearly see this too, but specialization may be useful in some verticals.

Yeah, that makes sense.

I want to go back to something you said at the very beginning about being allergic to ops because of benefits from that experience. I'm sure you've heard about a bunch of these ideas: We believe we're going to need humans doing distribution; they own the distribution. These verticals are not adopting AI technology as quickly as they logically should. We're impatient for that as technology people. Let's go buy distribution and roll services companies up, or whoever has access to the customer. What is your perspective on that, given that those are operationally intensive businesses?

I'm not sure that we fundamentally disagree, because it sounds like they're also saying, “Hey, we don't want to be in the ops business.” So it's about replacing the ops with software. I think it's hard to replace ops with software. At least, I found it difficult.

Maybe AI changes everything, but at Zenefits, we had this theory that was ultimately, I think, part of the downfall of the company: We could move through the market more quickly by doing a lot of things manually.

And then we would just replace it with software over time. It sort of turned out that it was actually very hard to replace operations with software after you’d scaled it up. It’s a lot easier to start small with automation and gradually grow over time—even hopefully grow quickly—but the point is, you start with a simpler set. You start with a small set of customers.

I don’t really think that there are customers with simple needs. I think all customers ultimately have a bunch of edge cases and long-tail things that they require. But a smaller set of customers is easier to deal with than a larger set of customers, and if you start with that, I think you can gradually expand the capabilities over time. If you start with a really large group, it’s hard to even capture the superset of all the requirements that you need the system to handle.

That was the problem that we found. We thought we were going to automate everything, and then the automation was just much harder and was constantly delayed. We were in this situation where the automation was constantly coming but never there, and that caused a lot of issues.

I don’t know if people will be more successful at that with AI, but I think it’s really important to understand whether you’re in an area where things have to be deterministically correct. That’s obviously the place where it gets harder to do that reliably with AI, particularly when you have a really large, complex space of edge cases, long-tail scenarios, and things like that that need to definitely work correctly every time. That’s sort of the space that we’re in.

If your payroll is not correct, you’re super pissed. You need deterministic rules about how this needs to work, and you need to make sure that the rules engine is programmed in. It can’t be subject to the entropy of some of these AI systems.

Rippling is one of my favorite examples of software companies that I think are very durable to everything that’s happening with AI.

Does it change anything about your strategy fundamentally?

It definitely makes us a lot more focused on data, like a lot of other companies, and on capabilities around data. What I think is going to be very durable with AI is that, from everything I’ve seen, building the applications is—I don’t want to say trivial, because obviously everything’s hard—but what’s much harder than building AI applications is building governance and permissions, data pipelines, and things like that.

Those are the areas that we spend a lot of time on because they tend to be our core strengths, particularly because permissions and governance are very tied to an understanding of the org chart. Usually, permissions are about job, role, function, and org-chart relationships. If you understand that deeply, you can be opinionated about who should have access to what and who can do what in the system.

Ultimately, I think all of these AI agents are going to need to inherit the permissions of a person. Some people would say, “Well, maybe it can be a service account that has distinct permissions.” The problem then is that people are ultimately going to be interfacing with it. If it has different permissions than they do, there’s just this leakage problem.

I think you always need to ensure that the agent inherits the permissions of the person that it’s working with directly. When you do that, you need to understand, “What permissions does this person have across all these systems?” You start getting into identity, job function, governance, and things like that, which I think tend to be some of our strengths from a platform perspective.

A last question for you. Rippling is already at public-company scale, but at the same time, companies are staying private for much longer. How do you think about this choice?

I don’t have any religion about it, and I’m not sure that I’m the world’s expert on it. Historically, one of the big advantages of being public is liquidity. What’s happened over the last couple of years is that there’s obviously a lot more liquidity in the private markets, whether it’s for employees or early investors.

If you can do that in the private markets, there’s a lot of upside to staying private. Certainly, I think you look at Databricks versus Snowflake, and it seems like Databricks has had some advantages by not being public in that fight.

You also have this dynamic in the public markets where the public markets have become something of a retirement community for very slow-growth but very profitable companies. Everything is structured around that. When research analysts are talking about high-growth versus low-growth public companies, they’re asking, “Are you growing more than 20%?” It’s not more than 30% anymore, because that doesn’t exist in the public markets.

If you’re a company that is growing a lot more quickly than that, there just aren’t comps in the public markets. I think there’s actually a lot of risk as a result of that because there aren’t clear comps for what the multiples will be or what the valuation is going to be.

That could change, though. We could look at this in a couple of years and suddenly it could be very clear that the public markets do value fast-growing companies more than slow-growing ones. Maybe there isn’t as much capital in the private markets anymore, and suddenly the entire calculus changes.

We’ve decided to be private for now, but that doesn’t mean forever. You get to make that choice again every year. Obviously, if you go public, it’s hard to undo.

Awesome. Thanks so much, Parker. This is great.

Cool. Thanks, Sarah.

Find us on Twitter at No Prior Pod. Subscribe to our YouTube channel if you want to see our faces. Follow the show on Apple Podcasts, Spotify, or wherever you listen. That way, you get a new episode every week. And sign up for emails or find transcripts for every episode at no-priers.com. [Music]