Hey guys, welcome back.
This is part 2 of my interview with Parker Conrad, creator of Rippling.
Parker, one of the things
that we're definitely seeing across our whole portfolio
is that, well, 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?
- In my views, that 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.
And so, Rippling, one of things that I think was,
I mean, 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.
- So, on day one, you can pay--
- 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.
- 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?
- 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.
- Totally.
So, try to locate your teams
or build your teams around maybe API boundaries.
- 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.
- 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.
- 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.
- Do you have any tips on opening a remote office?
There's a lot of people watching
who are considering doing that.
- 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.
- 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.
- So, 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,
like 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?
And a lot of those day-to-day decisions
are a lot more efficient and effective
if they can happen in one person's head.
And 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.
- And then the product suffers
simply because it's someone else's job, not mine.
- That's right, well, it suffers
because the engineers are not aware.
- 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,
and if you read that, you feel pain, you feel that pain,
and 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 sort of earned a customer forever.
- 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,
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.
- 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.
This is really fun. - That was fun.
- Yeah, man. - Cool.
(jazz music)