How Zapier’s Founders Built and Scaled a Remote-First Company

Zapier’s path to success didn’t start in the Valley with a bunch of successful former founders. It started at a college hackathon in Missouri, of all places. Of course, Zapier is now one of the biggest names in SaaS, has over 1.5 million users, and is famous for its remote-first culture. But none of that was the end goal when founders Mike Knoop, Wade Foster, and Bryan Helmig started building Zapier at Mizzou’s startup weekend in 2011. The end goal was to create an amazing product. From that hackathon weekend and initial team of three, they’ve grown to a distributed team of 85 people all over the world. We talked to Mike about what he’s learned along the journey from hacking in his spare time to managing a distributed team of 85 people across the globe. Here are the biggest takeaways for founders on how to build a company and scale your remote team.

Founders: give yourself permission to hustle

Before building Zapier’s prototype, Mike had been itching to work on a project like this. But without that hackathon weekend, Zapier wouldn’t have happened. As Mike told us, he just hadn’t allowed himself “permission” to work on his side project. He was a full-time student and his co-founders were working full-time—who had the spare hours to build something as difficult as an API to connect APIs? It wasn’t until Mike had to pay a $100 entrance fee for the hackathon (a steep price for a broke college student) to allow himself to focus on building Zapier for an entire weekend. But in just that weekend, the team built a prototype that connected PayPal and Twitter. What’s more—they won the hackathon. The main lesson Mike says founders need to learn here: You need to give yourself permission to focus on your passion project.

“You need to give yourself permission to focus on your passion project.”
- Mike Knoop

You can’t just work on something part time and hope it will take off. You need to invest some time (and maybe money). The same effect happened when Zapier went through Y Combinator. Doing YC allowed the team to stop treating Zapier like a side project, and see what hustling could get them. They realized their side project could and would scale.

Bottom line: Give yourself the permission to devote yourself to it—even if it’s only for a weekend or a month—whatever you have to spare. Get to the Minimum Viable Product and take it from there. Yes, it’s a risk. But if you don’t take that risk and initial investment, you’ll never get any users.

Hiring remotely: you can scale processes, but not people

Zapier is one of the biggest names in remote work. But Zapier became a remote company almost by accident. As Mike told us, “There was no single moment where we decided ‘Zapier is going to be remote’—it just happened.” After YC, Mike happened to be going to and from Missouri to be with his girlfriend. By doing that, the team had a sense that remote _could _work for them. So when they needed to scale their team, they opened the search to remote employees simply because they needed to hire the best people. One of the biggest hiring takeaways, Mike says, is that you can’t clone your team. Everyone is a “T-shaped employee,” but not all T’s are shaped the same.

text on image reads "I'm great at this one thing and familiar with all this other stuff."

A founder’s job—especially if your team is remote—is to figure out how those “t’s” fit together. Let’s say you have an engineer who actually has some UX chops. You probably don’t need to pair them up with a senior designer. You might be able to pair them up with someone a bit more junior. Or say you’ve got a front-end engineer who doesn’t have as many visual design chops, you might want to pair them up with a stronger visual design who maybe doesn’t have that UX or information architecture design background.

Bottom line: Assembling a team is hard work, but it’s worth it to put in the effort. You can’t just hire for one quality or try to duplicate someone, cross your fingers, and hope that it will work. You need to figure out _exactly _what you’re looking for, and how the new hire will fit into your existing workflow and culture.

Zapier’s framework for remote work communication

The team at Zapier has written a lot about remote work. In the years since they’ve been building a remote team, they’ve learned a lot about how to communicate to make things actually function. Mike told us a bit about the framework they use to communicate with each other. As Mike told us, there are four different stages of communication in an organization, each with its ups and downs. Each stage is higher “bandwidth,” meaning it’s easier to communicate, but lower efficiency. Here are the stages:

No communication: Low bandwidth/high productivity. People aren’t talking or texting. Everyone is focused, but no one is talking.
Text only: People are using group texting or live chat. They’re communicating, but it takes a while to get all points across.
Text and video: Teams are using video (Google Hangouts and Zoom) in addition to Slack. It’s a bit time-intensive and distracting, but communication happens easily.
In-person communication: High bandwidth/low productivity. In-person communication allows teams to use nonverbal cues to communicate. It’s very distracting (think lots of office chatter and tapping people on the shoulder), but everyone is on the same page.
The biggest lesson, for Mike, in managing a remote team? Be intentional about which kind of communication you’re using. When everyone’s typing at once in Slack, Mike knows it’s time to jump to a video call—even if it wasn’t planned. Likewise, when you’re onboarding new employees, you need to put a human behind the Slack avatar. That’s why Zapier gets together for onboarding retreats.
Bottom line: Know how to communicate with remote employees for different situations, and choose your platforms wisely. Remote work can be amazing, but only if managers handle it well.

Let your failures motivate you

Zapier’s journey to success was not a straight shot. But rather than letting the bumps in the road get him down, Mike tried to get them to _motivate _his team. Every time there was a mishap—like when they initially didn’t make YC, or lost major customers in the early stages—they used it as a chance to say “Ok, how can we do better next time?” Because the team was so certain that the product could be amazing, they didn’t get defensive when they had a small failure. Instead, Mike says, they thought “Let’s prove these guys wrong.” Every startup story comes with high highs and low lows. But if you assemble a team that is confident enough to motivate themselves through those lows, they’ll make it to the other side.