This is part 2 of my interview with Parker Conrad, founder of Rippling. Read part 1 of this interview here.
Garry: Parker, one of the things that we're definitely seeing across our whole portfolio is that we're here in San Francisco, but engineers are very expensive. There's not enough housing, quality of life is very difficult at some level... but what's difficult for San Francisco is turning out to be an incredible boon for the rest of the world. How do you guys think about remote work, and what are you seeing across all of your customers?
Parker: In my view, remote work is the worst way to build a company, except for all the others. It's really not possible to build engineering teams at scale in the Bay Area right now. I think it's not something that a company can do, and so, if you need to build a big engineering team, you've gotta do at least some of it, or big parts of it outside of San Francisco.
One of things that I think was not unique anymore, but was unique when we started doing it, is most of the company was actually outside of the Bay Area. We have a second office in Bangalore, and that's, even to this day, more than half the company is at our Bangalore office. And a lot of that is engineering, but there are other functions there as well.
All of the challenges of having remote teams are there, but it's so impossible to build everything in the Bay Area that you need to find ways to overcome those challenges. And we see in our customer base, Rippling is really one of the only systems like this, it's the only payroll and HR system that was built for remote-distributed teams across the globe.
You can hire people outside of the U.S., you can pay them outside of the U.S., you can have one system for everyone, and so, we see this in a lot of our customers. That's one of the big value propositions is for companies that do have people, whether it's employees or contractors outside the U.S., you can do it all seamlessly inside of Rippling.
Garry: What's the secret when you meet with founders and they ask you, how do we even integrate a on-site team here in San Francisco with a remote team? What are the top three things that they absolutely have to nail in order to remote work the right way?
Parker: Gosh, I don't know. I don't know if I've figured that out. Something that we struggle with. Like I said, it's definitely hard. The time difference with Bangalore means that meetings early in the morning and lots of meetings late at night talking with the folks at the other location. I think it helps to have really solid leadership in both places to try to have, and we try this, but I would say a lot of times, we don't succeed, to have certain teams that are all located together and not splitting teams up. So, for a long time, there was this part of our product was entirely in Bangalore, and another part of our product was entirely in San Francisco, and of course, over time, it gets messy, and you end up hiring people on both locations, which creates that coordination problem.
Garry: Totally. So, try to locate your teams or build your teams around maybe API boundaries.
Parker: I mean, for us, there are these very natural break points in our product, where you have payroll, you have insurance, you have apps and identity, hardware. And for a long time, those teams were either in the U.S. or in Bangalore, but over time, now every team has a presence in both places.
Garry: That makes sense. And things get a lot easier with great tools. Rippling, obviously, but then Slack and all the things that people use on the dev side. The tooling has helped a lot.
Parker: Yeah, the tooling's a lot better. I'll tell you one thing that we did that's kinda weird. We have this robot that people sometimes use. It's like an iPad on a stick on top of a Roomba. And there are people that work in that robot and drive around the office. That ends up working, it's not 100%, but the advantages of it are that people, whoever's in the robot, they overhear conversations, so they pick things up in a way that they wouldn't if you were just dialing in for a Zoom meeting. And people can go over to them and expect to be able to talk to them in a particular location. So, it's a little more similar to everyone working in one place.
Garry: Do you have any tips on opening a remote office? There's a lot of people watching who are considering doing that.
Parker: Well, we had actually, the first or second employee at the company was someone who, we actually wanted them to move to the U.S. They were based in Bangalore, but we couldn't get 'em over, they wanted to be in India, this person wanted to be in India, So, it ended up being almost accidental. We said, well, why don't you stay in Bangalore, and maybe we'll hire a few people. And at every stage that we were hiring folks, we found it was a lot easier to find the talent that we wanted to hire in Bangalore than it was in San Francisco. And so, very organically, that team ended up becoming larger than the one that we have in S.F.
Garry: Parker, I think you're one of the strongest product-first founders in the Valley, and in particular, I really love how you think about customer support. How you develop that product actually comes out of what the user needs, and the most direct way you can actually access that is through customer support.
Parker: One of the things that we did that's very different is we didn't hire a support team until, really any support reps at all, until I think we were about five or six million in run rate revenue. And the reason was really that I think there's a discipline.
If you can force the engineering team, and by force— I mean everyone was on board with this—if you can force engineers to support products themselves, what it does is, it gives them perfect context around what are the challenges that customers are facing.
As soon as you start hiring support reps, there's this communication barrier where engineers don't really understand what the struggles are. When the engineers are doing support, there's this great feedback loop that they have, where they have perfect context on what the issues are, and they can internally make trade-offs around, do I take a few hours and fix this issue, and they'll understand exactly what the fix needs to be, at the expense of maybe a longer-term investment that I'm making, or should I stick to that?
A lot of those day-to-day decisions are a lot more efficient and effective if they can happen in one person's head. As soon as you start splitting this out, you start having these different constituencies. You have support, you have sales, you have product management that comes in, really just shuttle information between all these different teams, engineering, and the communication just gets a lot harder. No one's in a position to make one decision around exactly how this is all gonna work.
Garry: And then the product suffers simply because it's someone else's job, not mine.
Parker: That's right, well, it suffers because the engineers are not aware.
Garry: Human beings actually make decisions based on their emotions, and so, if you're the one doing customer support, you have mirror neurons, you are sitting there face-to-face with a user who cannot get something basic done in your software, and they are experiencing pain. If you read that, you feel that pain. So, as the creator—as the engineer who can actually fix it, there becomes this really amazing loop between feeling that pain, being able to resolve that pain basically immediately, and then this wave of thankfulness and gratitude. You've earned a customer forever.
Parker: And it all happens in your head, in milliseconds, as opposed to having to schedule a meeting with all of these different constituencies to decide on the path forward.
So, as we've grown, we've hired out folks in support, but first, it's a much smaller footprint than I think most companies of our size, because the engineering team is still really involved in relentlessly driving down support tickets and issues that customers have.
But also, we've had those support teams, and they're decentralized. There are support reps for payroll that work directly and sit with the payroll team, we have support reps for insurance that sit with the insurance engineering team for apps and identity, for hardware, same thing, and in each case, we really work hard to make sure that the folks on the support team view themselves as, first and foremost, members of the payroll-product team, and secondarily, a support function, because I think you want those teams, you really want small teams that are cross-functional, where everyone has all the context they need to be able to make decisions and move forward.
Garry: Parker, I love talking about customer support with you, because it underscores how much being CEO and founder of a company like this is really about stewardship, how do you think about your employees, your customers, even your investors. You've been really thoughtful with Rippling. Thanks for hanging out with me.