Product and design process for remote teams

Hey guys, welcome to the podcast. How's it going? Good. Great. Cool. Kevin, welcome back. For people who don't know you, what do you do? I'm a partner at Y Combinator.

I founded a company called Wufoo back in 2006. I was in the second batch at YC, and that company, appropriately, was a no-office company. We were all remote all the way back then. Huh, that's relevant to today, isn't it? Some early inspiration for us. Wow. What are the odds? All right, Mike, so what do you do?

Yeah. Hi, I'm Mike. I am a co-founder at Zapier. I'm their chief product officer, and I originally started out as a front-end engineer and a product designer, so I have a very deep appreciation for those areas, and I think has kind of how I came to run some of the design team today, and I've thought a lot about scaling design teams over the last seven or eight years. And what does Zapier do?

Zapier is a piece of software that helps you automate your tasks at work, helps you be more productive. So if you use multiple tools for your job, and you're trying to, like you're manually copying and pasting data from one tool to the other all day as part of a task you do, you can use Zapier to automate that and have it done automatically in the background.

So an example would be like if you are a, let's say, a project manager, and you've got a team that works out of GitHub, and you wanted to send some notifications into Slack or into Jira, whenever those issues get closed, you could set that up, just as one example. Cool. And how did you guys meet? Because you've known each other for a while. Kevin and I? Yeah. Yeah.

I came over to the place that you guys were working when you guys were doing YC, and we just like talked for a couple hours, but it was a really interesting conversation. Basically I told you, I was like, this is what we did at Wufoo, and I was like, you should basically just do kind of a lot of the same things in regards to like. .. Specifically, yeah.

Think about remote work, that you're going to be doing this for a really long time. And then integrations was kind of like patching a bunch of things together to a form builder was like a feature at Wufoo. But to me, I saw what they were doing was like turning that into an actual business. And so a lot of my insights were like, this is what works for us.

It's really powerful, and I totally get why every other company would kind of be interested in Zapier. Yeah. You're definitely one of the people who saw the early, I think, vision of what Zapier could be. And I think that software is such a good use case because the data never ends in a form. You want to do something with it.

Usually it's once someone submits a form, I want to go put it in my CRM or qualify that lead or put them in an email list somewhere. It's actually interesting that like, I think the life cycle of people like getting their business online, it's like you start off with like, I need like a presence. It's like, how do I get my stuff out there?

And so use like website builders, like by default become really big. We didn't realize this when we started, but we understood this later on was that like, so then people need to figure out like, how do I collect data from all these people that are coming to us? And so form building, contact forms, et cetera, like all of that became really relevant in surveys.

And then the next thing is like, oh, now I have all this new data. What do I do with it? And that's like, Zapier is like the next step. So these are like the three like stages of every company of like, oh, this is what I need. And they have just giant markets. I remember early days at Wufoo, people would talk to us about like, so what's your TAM? What's like your total addressable market?

We literally were just like, I'm not doing that because it'd be like everyone that ever has a website, everyone who needs to collect data, like, do you want me to calculate that? I have no idea. Yeah. I sometimes think those exercises while useful or sometimes like little misleading. It's misleading when your market is so ridiculously large. Yeah.

When you're thinking about like a consumer adoption, you know, you don't ask Facebook, what's your TAM, right? Right. And for us, when we think about this opportunity, certainly when we got started, you know, our ambitions were, hey, can we build like a cool piece of software and support ourselves?

But over the years, I think we realized, whoa, we've like tapped into something that almost every person who uses apps and software to get their job done should be using something like Zapier.

There's this like huge explosion in SAF software in the industry that is like the barrier to entry to creating software is so low and distributing software is so low that you get these niche tools and more and more folks are using these new tools and bring them into the workplace.

So something almost out of necessity has to exist like Zapier in order to be able to make those tools play well together. And a lot of times, just because of the dynamics of the explosion and how many tools there are, there's no one player in that marketplace that's going to be incentivized to go build thousands of integrations with everyone else. Yeah. But at this point. Customers want it. Yeah.

I mean, at this point, surely you do have to be thinking more specifically about personas and like growing out individual markets, right? So how do you approach it now that you have so many users? Yeah. Honestly, to date, it's still a very horizontal strategy. We have mostly focused over the last seven years about getting more and more apps on Zapier and getting the tools people want on Zapier.

I think that's been one of the things that actually surprised me was how much growth we've been able to get out of like the initial, I guess, decision back in 2012 to build an open platform. Looking back, that was definitely one of the like better decisions I think we made in the early days. We built the first 50 or 60 apps on Zapier ourself, Brian Wade and I, just to like bootstrap that engine.

And when we launched in 2012, I remember we had live chat, I think, Olark on the site at the time. And we got literally, we launched in TechCrunch and had three days straight where all the chat messages we're answering was just people asking for apps that we didn't support. And I had never even heard of.

And it opened my eyes and opened, I think, all of our eyes that if we're going to get this thing to scale, we have to figure out a way to get those apps on Zapier. And we just can't do it with three people. So it was almost out of necessity. We don't have money to hire. We can't build these ourselves. So we have to get, figure out a way that partners can build those things on Zapier.

And at that point, we had enough inertia and momentum from the launch and from early users that were really excited about the product and that carried us. How do you jumpstart that? Because I think that's like everyone, especially I remember back then, people were talking about the platform. You've got to be a platform. Like how can you be like Salesforce?

And the thing is, jumpstarting that is difficult. Like just because you put up an API and tell people like, hey, if you go and do this, then you're going to get benefit. Like how did you guys in the early days get people to be like, I will program against your thing so that I can be part of your ecosystem when it was very, very small.

It is interesting how every, every SaaS company, every software company eventually get big enough and you want to be a platform. I think I'd always, I'd heard the heuristic of like, once you get big enough where you could carve off 1% of your revenue and that could be its own standalone business.

Like you've kind of reached a critical mass that you could actually build a platform that has legs and can sustain itself. For us in the early days, obviously we didn't have that. I think the thing that we leaned on really heavily was the value proposition to some of our partners building on Zapier.

It wasn't just, most of the time these platforms plays, one of the big mechanics you see people building on platforms is for distribution. Like I might go want to be in the Salesforce app exchange because that way more Salesforce customers can learn about the fact that I exist and might discover me. For us, we didn't have that. We didn't have a big user base in the beginning.

The value we gave to partners was around retention. If they built, they integrated with Zapier, they got access to 50, 60 at the time, integrations that were maintained and scaled and were adding more to it and they got it for free.

So it allows them to go say to their customers who are asking for these integrations, no longer do they have to say, hey, sorry, no, we'll put that on our to-do list or our feature backlog and we all know how that goes. They could start saying, hey, yes, you can do that with our product. Go check out Zapier. Here's a link. It was a way for them to say yes to customer requests.

Like there's actually a way for you to do this. There was value to them beyond just user acquisition that incentivized them in the early days to build on Zapier. Did it end up being that a lot of people on the front lines recommending you were then support people? Because for us, in our company, customer support was where all these feature requests would come in.

And so did it end up being, I mean, I would imagine a lot of them were like, hey, here's the stopgap. Here's how I satisfy you. That was very common. We would get listed a lot in help docs, help documentation. That's also another avenue where we get mentioned a lot, where Zapier basically helps them close a deal with a customer that they're trying to upsell or convert into a paid plan.

Was that like the start of your dominance in SEO stuff? Is like, oh, we get people sort of linking to us? That was actually earlier. We built our app directory before we built the product. Before we launched in TechCrunch, that whole story was, we had been working on Zapier for about five months, I think, at that point.

The very first thing we did when we sat down was we built our app directory, which was landing pages. And we used that to try and gauge what people wanted us to build. We were building these manually. We had a very big opportunity cost on our time. So in the beginning, how many apps did you guys integrate and do before you actually had people integrating and doing the work for you?

It was like 50 or 60. Yeah, they get 50 or 60. But we had landing pages for, I think, a few hundred at that point. We had email collection on the pages and classic lean startup of just trying to understand and gauge the market demand for this thing before you go invest the time to build it. But on launch, you had 50? I think so. Yeah. Because that was a startup weekend project, initially?

Yeah. That's where I met Wade at, actually. I'd known Brian for about a year before we started Zapier. But yeah, I met Wade the first time. I was actually going to pitch a different idea at that startup weekend, not even worth talking about at this point.

As soon as I heard Brian pitch the idea for what was called API Mixer at the time, my eyes lit up and I was like, that's what I'm working on this weekend. So during that weekend, we prototyped out actually what Zapier is. The core mechanics of mapping data between apps all came out of that weekend. I think we built PayPal and HiRise and Twitter, I think, were the first three apps.

How did you pick those? It was more we sat down and said, what would be a cool use case that we could demonstrate this prototype with? During the final demo during startup weekend, the mechanics of the weekend is you work for a weekend and then you present to the rest of the crew on Sunday night.

During the demo, we said, hey, wouldn't it be fun if we get up on stage and have people actually tweet something live and then have people pay us something on PayPal? Then you could actually see the prototype of Zapier run and pull that data into HiRise.

The idea was like, oh, we could aggregate if someone pays you on PayPal and they're tweeting at you, you'd like to know that in your CRM so that you could pay special attention when you're contacting them. So it kind of came out of a single use case and we worked backwards from that. So at what point do you end up doing YC? We applied actually twice to YC. We got the email rejection the first time.

We applied basically with the prototype from startup weekend. So we had no customers, no traction. Basically just three dudes from Missouri. It was a hackathon project. So totally useful exercise, I think. But it definitely lit a fire under us, I think, as far as like what was useful about filling out the question. I'm going to show these people wrong.

Did something change while filling out the application? It was helpful to think through what we didn't have yet, I think, for that first time. It made us realize some of the things around traction that we were like, there was a big delta. And still like optimistic with the prototype. But yeah, once we got the email rejection, at that point, we had enough hints of success.

We were like, we're going to keep working on this. It gave us actually more motivation, I think, to keep burning 40 hours and nights and weekends a week for the next few months. And then the second time we applied, by that point, we had had hundreds of conversations and chat logs and messages from actually a lot of folks in the YC network were even using the product.

It was invite only at that point. We were having folks pay. We had our first 10 people pay us $100 to validate it. And we turned down the price to, I think, $5. We had a few hundred people who'd paid us that amount of money, just a lot more social proof and validation that like, hey, this is a problem that a lot of people care about and could be useful.

And so at that point, had you guys committed to being a fully remote company when you went through YC? Did you even have employees? No, just the three of us. And we hadn't. Zapier had been, I mentioned, we'd been doing nights and weekends for that four or five months in early 2012. You guys still had like jobs. Yeah. Brian and Wade had full time jobs.

I was a full time student, actually, a grad student. I get the one star of dropping out to start Zapier. But yeah, after our full time jobs were over, 5 o'clock, we would go either back to our own apartments and work separately. Or we had one of our bosses let us run to use one of his offices to co-work out of in the evenings.

And we'd go put in work until midnight, 1 AM every night, working on Zapier, basically. So it's kind of two full time jobs for the first few months. Yeah. And so demo day happens, and then where do you go? What do you do? Yeah. So obviously, YC, one of the things is moving out to California.

So that was really, I think, one of the big values of YC for us was the forcing function to go commit all in, right? No longer is it a side project. This is actually the full time. Now we could. .. Did you not fully believe in it by then? Or is it like, you thought, this is an interesting hobby? Yeah.

I think, you know, thinking back to that time, it was. .. Think about our ambitions, right? It was like, hey, we wanted to get this to a point where we could support ourselves, be our own bosses, control our own schedule. And it hadn't got to the point where we could supplant our full time income. So it was kind of out of necessity that we were running the company, building it that way.

But once we got to YC, you know, you get a little bit of initial capital. We got an apartment in Sunnyvale, and that kind of allowed us to focus full time on it. So demo day, we actually leading up to demo day, I remember one of the problems, early problems we ran into that summer was all three of us would wake up in the morning and we were all doing customer support.

We had a shared Gmail inbox, like, or not even that, an email would get copied into all three of our inboxes. In order to do support, we would have to sit next to each other so we wouldn't answer the same email. Wow. And we would be spending, you know, until noon each morning, just like answering support tickets and trying to help people get set up with the product.

And that was chewing up a lot of development and forward progress time. So the very first hire we looked at was someone to help us out with support. And we had no network in the Bay Area. We didn't, you know, we just moved out three months ago. We didn't know anyone else. Our networks were from kind of like our college networks and from past jobs.

And when we started looking at the folks we thought might be a good fit for that, the one person who came to mind was one of Wade's, I think, college roommates, and he lived in Chicago at the time. And we knew we couldn't convince him to move to the Bay Area, but we didn't want to.

And we thought back to like, hey, we were kind of doing Zapier remotely before start weekend or before YC, like what's we could give that a try. And this coincided with the exact time after YC where I was, my wife, girlfriend at the time was finishing law school back in Missouri.

So I was flying back and forth every two weeks back to back to Missouri and then back out to California to work Brian Wade. So kind of this perfect storm of like situation where it was like, well, we have some confidence that we can do this remotely because we had been doing it before. And the people we want to hire want to be remote. And I had to be remote for part part of the time.

So like, let's just give it a go. So it's very much an experiment in the early days just to think like, hey, this was working. Let's see if it can continue to work. And did you have any kind of plan or structure or were you just like, well, let's just see what happens and make it work? You know, more inspiration than plan, I'd say.

Like you look at folks like Basecamp at the time, WUFU at the time, like we had seen at least small organizations that had been successful at building fully distributed remote workforces. So I think there was more inspiration than anything. A lot of times for a lot of people, they feel like the company isn't real until like there's an office. There's like a lot of ego thing.

And so I think that's the kind of thing that's amazing about remote teams that actually get really big. It's like somehow they don't have something that's tied to like the thing, the thing I need to show off. They're comfortable with saying like, I got no place to show you. I work from my home. And so like, is that an, like, did you guys even struggle at all about that?

It was like, how are we going to be a real serious company without this? It didn't hurt any, it didn't like hurt any efforts in terms of scaling the organization.

It's certainly even, it's funny how much, how pervasive that like idea is, because even I remember probably last year or the year before, we'd still have people joining the organization who'd comment like, yeah, do my parents want to know if I'm working at a real company right now? And it's like, well, yeah, we have, you know, 100, 150 million in ARR, like, yeah, we're a real company.

But yeah, it's still one of the reasons why I like some of the PR things that we do actually useful because we can send those to friends and family and say, hey, look, this isn't just like a side show. Like this is a real thing. How did you not get caught into that trap? That's the thing is like, it has to come from the founders, obviously. How did we believe that it was not a side project?

Why is it that you never felt like you needed to have an office? No, it's just like peer pressure around startup norms. Exactly. Like, why did you not succumb to that? Because that's often what I see a lot of people do is that like, I'm spending this money because I think this is what it looks like to normalize me.

Because this is actually very, especially at that time, it was very radical to be like, I'm not going to have an office. Yeah. When we were talking to like investors and whatnot through YC, lots of raised eyebrows, we'd get folks turning us away. specifically because of that.

Even some of the folks who did, we went forward with like still would be like, hey, when are you gonna mature as an organization and get an office and start hiring locally, right? Now, do you see a very different opinion in VCs? So which is fun to see that mindset shift. But how did we resist?

I mean, in those early couple of first years between 2012, 2014, it was largely driven out of, I guess, kind of like the scrappy nature of the organization. Like it was out of necessity because we weren't profitable yet. We'd only raised a small amount of money to like help give us a backstop to be able to scale a little bit faster than we otherwise would have.

And the networks of folks who wanted to hire were remote. It was probably around eight or nine people into the organization when it stopped being an experiment. I do remember specifically having that conversation with like Brian Wade around like, hey, this is working.

Like this doesn't, and it was probably, I think, right after our first company retreat where we went up to Washington and had like seven of us, where it felt like, yeah, this isn't just like an experiment and like an easy way to get better recruiting. Like this is actually a better way to like run the company. For us, definitely it started off with cost. We're like, oh, we can't afford an office.

But later on as things were working, we were just like, if you have this frugal mentality, we're like, there's nothing about the office and wanting to have a commute that made any extra sense. And we also had relocated from California to Florida. So it wasn't like, oh yeah, our office in Florida was going to be the driving thing for anyone.

And so for us, it really just was like, I think profitability was the biggest thing for us. Like we were making money. And so if someone had some criticism against like, oh, why are you doing it this way? I was like, I'm making tons of money. So I don't really care what you have to say about this. Does WUVU still have the best exit to investment ratio? The ratio, yes.

In terms of like how much percentage of the company that YC owned or any of my angel investors to the output. And I think we're still in like top 10 biggest exits for YC still. Still? Because of how much equity that was owned. Because we didn't raise any money. You raised what? We raised $118,000. YC was $18,000 then.

And we raised money from two angels, PB and PG. And it was $50,000 each. And that was it. I was just thinking, you know, I think logistics and practicality was one reason why remote was like, we believed in it so much. The other reason I think is actually a little bit more tied to like Brian and Wade and how we like to work.

In the early days, like I think it goes back to this, that nights and weekends. Like part of the reason inhibition of wanting to like start Zapper in the first place was we kind of wanted to own our own schedule and like set our own goals and not be beholden to like a giant organization telling us what to do. We wanted to be very autonomous. And one of like, that is a company value.

Our number one value is default action. And that permeates all the way from the very beginning where we wanted to like, we wanted to build Zapier as a company that we would wanna work at. And if I'm gonna go work at like a big company, I would want that like level of autonomy and no one telling me that I have to be in the office at 8.

30 in the morning every day and like control my own schedule and be able to like just go know, go identify good things to work on and do them. So as someone now who's hiring these people, do you have to filter out people who think that they want that autonomy, who think that they might wanna be working alone from people who actually do? And is there a good way to do that?

Like how do you get the sense that people are really gonna- Like is your company full of like libertarians who care about freedom or is it a company full of introverts? I imagine it's not one or the other, but it's one of these things where it's like- I do think we probably attract folks that enjoy working alone more, not exclusively.

We do have quite a few folks who are extroverted in the organization who've like been successful and found ways to make it work. One of the things I tell everyone who's going through the interview process is your work can't be your family at Zapier or any distributed remote company. Like in the past, it's very easy to lean on your work as that like social connection.

It's a very rare, healthy mindset. And if you're gonna make it work at Zapier, you have to find a social network that's like outside the company. You'll get a little bit of it because we do two company retreats. You'll see their faces and names all day in Slack.

But whether it's like side projects or hobbies or like close friends or religion or family or whatever it is, like you definitely wanna have one of those networks that's outside the work environment. Related to this, like what are other major characters that you look for that you know this person's gonna be appropriate for remote work?

Past experience with remote is pretty good, is a pretty good signal because they know what they're getting into. Now with that said, we've had quite a few folks who haven't had past remote experience and they've been very successful, but there is like a learning curve attached to it.

I think the biggest, one of the biggest things I look for in interviewing that tells me whether someone's gonna be effective or not is like how much they can uphold that first value of like defaulting to action.

Do they have past experiences where they did not take a consensus driven approach and instead said, hey, this is the right thing to do and I believe that this is the right thing to do and went and caused some kind of action in their previous company or organization because they thought it was the right. But that sounds like a quality that's not just for remote workers.

Sounds like you just want that period for any company. That is one of the probably most surprising things I have discovered or observed scaling a 200 person remote company to date is that the types of things you have to do in order to be a successful remote company make you just a generally better company. They are not unique to remote. However, you do have to figure them out earlier.

And I think that is where a lot of the interesting, when people ask like, how do you run a remote company? I think that's really where it is because we've had to invest really early on in what's our decision making frameworks? How do we communicate as an organization? What are our processes?

You have to get really explicit about your processes in order to be successful and in order for folks to have the information that they need to be able to default to action and be able to know how to operate in this organization. So you mentioned this, I heard this in another podcast about like overlapping time zones and making sure you don't unblock or block and unblock people.

Nina Mehta, who I know, hey Nina, asked a question on Twitter related to this. And that is, what's the best way to share work and knowledge across designers working on different parts of the product without distracting from focused working time?

There's an interesting underlying, I guess, assumption here or observation I could say about this, which is one of the benefits of remote work, apart, like one of the number one benefits is of course from recruiting. You get to hire the best people anywhere in the world.

A secondary benefit that I think isn't as obvious is that when you're actually doing your job, like the best work gets done not when you're like sitting next to someone and like collaborating all day.

Like you have to get into deep work, even for a role like product design, which is very collaborative by nature, you still have to like have chunks of time, like four hours at a time to go really deep and explore a lot of iterations, a lot of different ideas.

And I think this is where like the process part of the organization gets so explicit is, all right, in a co-located company, in an office, you don't probably have a lot of explicit direction or like process laid out as far as when you're spending deep time versus when you're collaborating and coordinating with your coworkers, because I can just tap you on the shoulder, Kevin, and like ask you what you think of the work I just did.

Whereas in a remote team, we just have to be so much more explicit about what are the processes, individual people, individual teams follow when they want to communicate. What were some mistakes you guys made in the early days? You said you have to figure this out earlier. Did you guys make any mistakes?

I think one of the things that we figured out in the early days was when to be intentional about, how to be, sounds generic, how to communicate, when to raise the bandwidth on communication.

There is a, when you're in a co-located organization, a company, like I'm working in person with you, the default communication mode is, I'm gonna get your attention, and then I'm going to have a conversation with you. And I have full, I have the full range of bandwidth, right? I can use body language, I can use my, I can stand up, I can use tone.

It's like full bandwidth between us, but I've got 100% distracted you. Like you, I have your full attention. Now, so it's like, we're taking two people's times up for this. In a remote organization, the default is 100% the opposite of the spectrum, which is people don't communicate at all.

Like if you're, they're using a Slack channel, and that's like your main office, which is how we operate today. If two folks are on a team together, the default is kind of like, you don't say anything. It's a, it's like just a blinking text cursor, right?

And we have to be, we had to figure out when are the right moments, and how do we teach the organization, like when to move up that bandwidth chain, to move from not talking at all, because deep work is important, to text is acceptable, it's like Slack or email or something like that, to when to move that to a video call.

So like, when should I raise the bandwidth from like typing this thing out, to jumping on a video call, and then finally- Would you guys like write these rules down? There, there's some like transition moments to look out for, I'd say, and those are the things that are like written down and shared with the company.

So a good example of one that a lot of folks would be familiar with is like the Slack, many people are typing message that pops up.

So if you like, one of the things I tell a lot of our teammates, if you see that, that's probably a really good signal that you should be like jumping on a video call at that point, instead of wasting, or not wasting, but instead of spending, you know, 10 man hours in Slack debating about this for an hour for across 10 people, just get on a Zoom call and hash it out for 10, 15 minutes, and then summarize the decision back into the team chat tool that you're using.

And it cuts down. So it's like, that's kind of, that's what I mean by identifying the moments that it's important to like increase the bandwidth up to- We had a rule when we were doing remote working, where we knew that this was like really painful. And what we hated was long discussions happening for too long and breaking this sort of like deep work or like maker schedule.

And so for us, we changed the rule to be like, if you're discussing something for like 15 minutes, at that 15 minute mark, just, you got to stop and go on to whatever the next thing you have to do, like to get to like what you say is default action. And when we said like all discussions that have been paused, we set a time for this.

And we set it at like at the end of the week on Friday when the team meets together. It ended up being like 90% of the time, once they slept on it, they didn't even have to have a discussion. They just magically figure something out or how to compromise or realize something wasn't a big deal. And so usually by the time we get to Friday, not many things were ever brought up.

Only the most important things surfaced at that point. Exactly. And so I think it was like, I like this idea that what you're trying to default to is respecting someone else's time. And that the only time you start respecting is when you like need to make it really, really efficient.

But then what about on the other hand, where you're like, say you're stuck on a certain design problem, programming problem, whatever it might be. At what point do you say like, okay, I'm gonna break both of your focuses and take your attention full on to solve this problem or try to solve it? Yeah, that is a, I mean, it's a good question.

The reality is even if I wanted to get your full attention, there's no guarantee you're gonna be able to get it in a remote company, right? Like I may not have a path where I can go over and tap you on a shoulder. I might be able to DM you in Slack. I might be able to send you a calendar invite and hope to get 10 minutes on your calendar this afternoon.

But a lot of times you don't have like, you don't have the same guarantee of being able to get someone's attention that you do in a co-located. And I think that's actually good because it protects the attention of the person who would otherwise get distracted.

And the thing, like some of the social, I guess, norms of the organization of how we like address that is, one is in Slack, if you tag somebody in a message, like at tag them specifically, it's kind of the social norm to acknowledge that within 24 hours. So we have some expectations like that. And the reason we had set 24 hours is because we have folks all across the world.

The sun never sets on Zapier, I like to say. So yeah, we have some of these social expectations where there is gonna be some asynchronicity in how the organization works and operates.

And it's one of the reasons why I think hiring for default action is so important is if you get blocked in whatever your primary task is and you're waiting on someone else in the org, you have to have the bone to go figure out what are other smart things that I can work on that are gonna contribute value to the goals and how do I better serve our customers here?

If you're the type of person who like, as soon as I get blocked, I'm just gonna sit here until I'm told what to do next, you're not gonna be successful at Zapier or I'd argue most remote companies. So how big is Zapier right now? Like how many employees? 200, we just crossed 200. And then your primary responsibility is all the design work that's done at Zapier.

I spend a lot of time with our, like helping our product teams figure out what to work on next. And I love spending time with our design and engineering teams. How big is the product and design team at Zapier? We've got about seven or eight product managers, a similar number of product designers, and then an engineering org that's about 50 folks attached to that.

So from my experience, I know like how much collaboration is necessary, like especially at the start of like building out new products and sort of like thinking through them and then also designing them. And then also part of like the design culture is like critiques. And so to me, that was one of the things that was like really difficult.

Luckily, Rufy was like, I was the only designer, we never grew to beyond 10 people. So- It's easy to communicate with yourself. Exactly. So we never ran into that problem. So I'm really curious, like what did you, what's done differently for your design team and product teams to make that sort of work?

Yeah, I think that one of the most important relationships in the organization is the relationship between product managers and product designers.

I don't think I'm saying anything new or novel here by saying that, but it's certainly true for us, which is when we are thinking about staffing and hiring a team, we're making sure that those two folks are like intentionally building rapport, they're spending a lot of time together and they have a very strong shared ownership over the goals that they're working towards.

And- How do you do that remote work wise? That's the thing that's difficult, especially when you're trying to respect everyone's bandwidth. Yeah, in the earlier days when we had started scaling, which we'd started kind of scaling these teams maybe about a year or two ago, it was, I'll admit it was more ad hoc. Like we were figuring out this process still.

These days with 200, we've been a lot more, we just have, similar to what I was talking about before, we have to just get a lot more explicit with processes. We started using OKRs as like an alignment mechanism and like a designer and a PM and an engineer all own and share an OKR. A lot of companies can have weird definitions of OKRs. Like how do you guys define OKRs?

Like an objective that that team is trying to accomplish. Like, hey, we want to increase how many users are able to set up a zap by 10% this quarter or something like that. And that's something that a PM, an engineering manager and a product designer would have shared ownership over.

That gives a lot of focus to that team and it also gives the, it kind of helps elevate everyone's role to be thinking about like the impact on the customer first. I think what the thing I've noticed that happens in scaling Zapier is there's a tendency for engineering and PM design to kind of specialize in their own areas.

And like they have their own unique things they're thinking about all the time, right? Engineer might be thinking all day about the user experience. And engineering is thinking all day about estimates and delivery and refactoring and code quality. PM is thinking about business impact.

And if you don't give them some kind of, if there isn't some kind of shared system for how they should value the things that are prioritizing, you get a lot of us versus them mentality that kind of creeps into the organization. Where it's like, well, why won't the designer do this? Or why won't the engineer do this? So you give teams OKRs versus individuals? Yes. Gotcha.

Yeah, this is something we're new, we're starting to do, but so far it's been pretty fruitful in building that like alignment across teams. And so how is the team checking in on each other? Is it like a standup type thing every day? Yeah, every team does a little different actually.

So there's a lot of, one of the things about Zapier, that it's cool to see is a lot of teams experiment with some of the processes. So you give a lot of autonomy to different teams to try a bunch of stuff. Yes, we do. And OKRs are kind of our framework for how we pull, how we make that not chaotic, if that makes sense.

I like to think about there's, like the things that are important to be consistent across teams are the interfaces. Like you need to make sure that the interface between teams is consistent so that both teams know how are you- Can you be specific? What does that mean? How am I dependent on you? Or what is the API layer if it's two product teams that are building in the same area of the product?

Or if it's design, what's the like ownership between, where's that handoff? Like what's the scope role, scope of ownership between two teams? So it's like, or to be another layer might be like, we use JIRA for doing a lot of our issue tracking and project management.

And it's, there is some level of consistency that is important to have across all of our product teams using our project management software so that we can build some observability into. to the product development process across the whole company.

So we can get a sense of where are we doing well, where are we not doing well, identifying issues where we might be over-investing in feature work, or under-investing in feature work, or tech debt, and things like that. So there's some level of consistency that's important, but we do generally get to sign them, or do people have a draft? They are picked, and we hire into them, I guess.

So we'll create a lane at the leadership level of the organization, like, hey, here's a new opportunity we want to go after, here's a new area of the product that we aren't addressing, or part of the conversion funnel that we want to improve, Is there a team that someone's on that kind of stay with that team all the way through the life of Zapier? Mostly. They're long-running teams, I'll say that.

Our earliest product team is only a year and a half, two years old. And some of those folks have shifted. We've had folks restaff from one team to another, where there was another part of the product they wanted to work on, and this person's a really senior-level experience at engineering. We've just brought in more of a staff-level or associate-level engineer. We want to get them to work together.

Yeah, annual and monthly tends to be the two extremes. Annual, just to know, what are we working towards over the course of the year? What is our team trying to accomplish over the course of 2019? And then monthly check-ins against that, where they break those down. How does that workflow actually go down?

This is still new to the organization, so I feel like I need to give the coffeehead that we're learning a lot still with this.

We've been practicing with OKRs in 2018, which gave us enough confidence that, hey, this is actually a very effective tool for us to help align and allow all these different teams and people in the organization to be autonomous and default to action in the ways that they want. We wanted to start rolling it out to all the individual teams this year for 2019.

Practically speaking, I think the best version of this, and this is aspirational, like we're quite there yet, is you've got some high-level direction being set by the leadership of the organization. What are we trying to accomplish? In Zapier's case, we're trying to build a piece of productivity software that anyone can use. How do we get Zapier adopted by tens of millions of people someday?

You've got this high-level direction and strategy being set. There's a lot of work that is happening that needs to figure out, where is that aligned and how does that bubble up? There's a meet-in-the-middle approach where you want the work that's happening, 50% of it to be top-down driven, and I think 50% of it being bottom-up.

In reality, exec team leadership is never going to have perfect insight into all the pieces of work that happen across the organization. Something like OKRs is particularly useful for us to define every piece of work you're doing. I think it's largely useful for helping you prioritize and make hard trade-offs and have discussions.

This is one of the things that's great about writing down our process documentation in Zapier, writing down our decision-making processes, is when it's written down, you have something to debate about. I can go to you and say, hey, can we debate whether this is the right thing we should be spending our time on?

It's so much easier to do that when there's an artifact that you're talking about, as opposed to a group of people with different ideas in their head about what is important to have it. It just removes this layer of conflict in the organization. Also, discussions can drift when it's not tied to the artifact. What other tools do you guys use? You use OKRs.

But I remember in the early days talking to you guys, you guys built a lot of tools for yourself. I'm just wondering, right now, what's the most helpful tools that you guys are using, either that you've built yourself or that you're using from other companies? I actually built this one in the early days. We use Slack as our company office, for better or for worse.

This is where folks usually log into in the morning. This is where work gets talked about. But one of the trouble with that, especially as we scaled, and any remote company or any team that uses Slack will be able to tell you this, it gets an overwhelming amount of noise in Slack. You are free to leave channels. In fact, we encourage it. That is fascinating.

There's a feature in Slack where you can turn off the leave join notifications, and we turn that off. Because we wanted to give folks the social comfort to be able to leave channels without feeling awkward. That's how to be effective at using Slack. We set that expectation of that's how we use that tool.

One of the things that was missing that I saw was, what is our more thoughtful, to use the Daniel Kahneman idea, slow thinking version of Slack? Slack is where work gets talked about. Where does our final work get talked about? Where are final reports getting shown to the organization?

How do the right people get notified that I have something I need you to read and make a decision on or think about? This is where in the early days I actually got inspired by Nick Francis over at Help Scout. They were using a tool, another remote team called P2. It was a plugin for WordPress. It was kind of like a Twitter feed. Automatic was using this internally, and that's how they run there.

We used it at Zapier for a good six months, and it was pretty good. It started breaking, and we wanted to customize it. As your company gets bigger, you're going to run into these new bottlenecks, and you can start layering in and customizing the tool instead of having to go throw the tool away and pull a new one in and relearn it. In the early days, P2 started breaking for us.

It didn't tie into our auth system was funny enough the reason why I wanted to rebuild it. I built a version internally called Async, which is just an internal blog. One of the cadences we have in Zapier is every week we ask everyone to write a Friday update for what they worked on. This is kind of the heartbeat of the organization. It goes up on Async. You get to read everybody's Friday updates.

You get to know every decision that's made, everything people are learning, all the work that's happening. You get to read all the information. You start to run into the same problems even Slack does where it's information overload. Because we own the tool, we can tweak it and tailor it to how we want to run the organization, how we make decisions, and how we want communication to work.

We started building a default feed view where it was a curation layer in terms of who are your immediate direct reports, who are the folks you need to follow. You can create custom feed views to build the curation. We work with managers to onboard new employees to set up their views in the right way so that it's curated so that they get just the information they need.

Does email have a specific role or is it kind of a catch-all for you? We don't send any internal email. Really? That's like my fantasy. Of course, we do email support. Basically, if there's any internal to external communication. When we're talking with our partners or with customers, obviously that happens over email. Internally, there is no email.

We also use Quip for long-form documentation. It's a collaborative wiki, kind of Google Docs mixed with the wiki. And that's more for documentation? Yes. Documenting processes, hiring rubrics, things that need to live a little bit longer in the organization. Both Async and Slack are feed views that roll off.

One thing people were surprised about with us at Wufoo was how much time we spent development-wise on internal tools. 30 to 40% of our development time was us building stuff for ourselves. It's why we were able to grow and only be at a 10-person company for so long. What is that ratio for you guys? Do you have special internal tools teams that Facebook is famous for? We did last year.

We had invested in a tools museum which was helping scaling some of the Async software that we were talking about. I've been the internal tools manager for the last six months. We actually built our own OKR software into Async. One of the beautiful parts of it is when you're updating your OKR, it's got annotations that tie into the posts you're writing.

We've got this nice long-running graph of, here's this metric I'm moving over the year. But right now it's kind of just organic, like teams make their own stuff. It does tend to be a little more organic. I'll say in the early days, I think we invested more time in internal tools and it's something I'd love to spend more time on. I remember this for us.

A lot of our internal tools ended up being YC companies down the line in the future. More recently, most of the internal things that get built in Zapier today are apps on Zapier. We have a lot of folks in our engineering team and even more broadly on a support team and product team where we'll build features into Zapier by building an app on Zapier.

This is kind of where some of the innovation of Zapier comes from. Quite a few of the most popular apps on Zapier were built by one engineer and a side project at a retreat hackathon. Just for fun, because it was like, hey, we're going to add this little bit of functionality to the product that doesn't exist. That's actually the biggest criticism for lots of corporate hackathons.

People spend all weekend, get really excited, and they never make it to the light of day. We tried pretty hard to pick our hackathon projects and we curated them in a way that we thought that there was some value for customers in some format or would help customers in some way. What are the other things you guys do to keep employee and founder morale high across a remote team?

Probably the biggest thing we do is we do two company retreats a year. Even though we're 100% remote, there is still a lot of value for getting in person. We don't discount that. You get to build relationships with folks and it allows you to assume best intent the rest of the year.

When you're in Slack and you're working on that tense project and someone writes a message that might be a little more curt than it should have been, it's like, oh, I can hear their voice in my head. I know who that is. I understand who that is. I'm not going to jump off and assume that they were trying to be mean to me or something like that.

There are issues that I think can happen when you are primarily using text-based communication tools, where you do lose a lot of that tone. You have to try really hard to use tone and that's one of the first things that can easily get lost when you're in tense moments. There is a lot of value for building in-person relationships still.

We do two company retreats a year where we fly the whole company into usually some cool resort or hotel or place around the US or Canada. What do you guys do during that time? Is it just hanging out? Or I mentioned there's some structure. Yeah, we've tried a few formats. I mentioned the hackathon.

We've traditionally done a hackathon most of the week and then we would have a couple days set up for teams to break out in their own individual silos. One of the things we do a lot is we run a lot of company surveys and we try to evolve and iterate how we run the company. What does it mean you do a lot? How often?

Anytime we're doing a company-wide thing, there's probably going to be a survey sent out to get feedback so we can improve it for next time. Over email? There is an email, though, too. I'll admit that. You're not there yet. I still do keep my Gmail tab open. Every company retreat, there's a survey. We send out two company surveys a year.

I ran a product all company survey last year, so we do a lot of that. It's way better to do it this way. This last time, the thing we experimented with was we added unstructured time. We had always planned every hour of every retreat to date. It's interesting that you didn't think about it earlier. We're in a remote mindset, which is design the process.

I think some of our managers feel responsible to make sure their teams are taken care of and people know what they're doing and what they should be spending time on. From a management perspective, we were over planning all the hours. One of the things that that prevents is cross-team communication.

What if one person from the data team and one person from support and one engineer had this cool topic that they talked about at maybe one of our unconference sessions and they wanted to go hack on an idea? There was no time for that to happen in the past format, because it was completely top-down planned.

So we added these two afternoon sessions of unstructured time where we set the expectation that, hey, it's still a workday, but figure out how to best utilize this time with your team and your peers. Mostly through feedback at this point, I was anxious about it going in. We added this process in because of feedback we got before. I was still anxious that folks would not take advantage of it.

I was worried that they would just default to what they would do if they weren't at the retreat. Yeah, work on my roadmap or work on support tickets in isolation. But we want to take advantage of the fact we're here. I overemphasized in almost all my conversations with the team leading up to the retreat to take advantage of the time.

When I walked around and just observed the different groups of people that were coordinating in those afternoon sessions, I was surprised at how many people took advantage of the time. Given my anxiety, I guess, that it was not going to be. I think it shouldn't be surprising. When you're hiring a bunch of people who are default action, self-driven, etc.

, and then you bring them all together, they're going to do the right thing. It certainly worked out well, and I will continue to do something like that in future retreats. You guys have an interface that has to bridge hundreds and hundreds of apps together, and hundreds of different types of features together. It's so complex.

I'm trying to think of doing that without people really close and diving deep on the problem. How does that work for you guys? What belief or experience do you have, Kevin, that says, I have to be sitting next to you in order to solve a problem like that? I think it's one of those things where, for design in particular, it's hard to point, circle, resketch, etc.

There's some things that on pen and paper, in person, I can show. It's slower and more inefficient. I'm just wondering, is there things that you could do to compensate? You think about it differently. a lot of times with the team has been like the nine box design exercises. What's that?

Fold your paper into like nine boxes and you have like two minutes to sketch nine different ideas of a solution and then you have everyone present their nine ideas and then you do like a remix usually for like a longer five minute session and you come out with a lot of just divergent ideas in a short amount of time and the time compression on being able to come up with an individual idea to like force folks not to get too deep in the thinking just like go wide instead of deep.

I've run these over zoom calls where I'll literally ask.

I did this with the entire company last year where a little while ago where I asked was like maybe the point 70 or 80 people everyone bring paper bring Sharpie and I gave the problem statement up front and everyone's like just on a zoom call with their video on like sitting at their table right now drawing on their paper and they'd hold it up and they talk about it and I had them take a picture and post in the slack channel.

So there was like a fidelity version that they could see and they're holding it up and pointing to it.

I actually see how that's stronger than normal design collaboration and when everyone's in a room, there's a pressure of like, oh, I can't I don't want to look bad or like if I'm trying to sketch and figure something out like it feels uncomfortable to do so in front of a bunch of other people so I can see how like having everyone separated it's like oh you're working in your own kind of say it feels a little bit more safer to be daring.

Yeah, and there's like there were instances where I remember still having to like encourage folks like hey show it even if you think it's like bad because that's some of some of the things you think are weird ideas often end up leading to the right idea even if they're initially like weird will just trigger like a different way of thinking about a problem that hasn't been thought of before but we've so another process we have in addition to like doing kind of team exercises like this one of our more go-to processes that we've has been working really well for us the last last year was we were doing a a Tuesday Thursday essentially design review across several product teams so we would invite several product managers several product designers and the Tuesday Thursday cadence was how we built in that feedback we process where it's like okay I want to show something the team and get feedback on it get critique and then it's instead of only doing one a week where you'd have to wait a whole nother cycle there's a forcing function to turn around and iterate and go deep 48 hours to then turn around and show it back on Thursday that's and show it again so it's it's kind of like a bit of a mix where you still get that deep work in between the two review check ins but it's still on a zoom call well one of the things I like to ask people to do on zoom calls especially in design collaboration sessions is like don't mute yourself zapier is built up this interesting norms around like what what is zoom etiquette right like how to when done with yourself when to like jump on video all that kind of stuff so we kind of I have to like intentionally ask folks to like break that habit and say okay for this please don't give me a mute so to encourage folks just jump in right I want folks to feel comfortable not waiting to give their feedback but just like to generate a little bit more like randomness in that conversation I think this is probably one of the things that is very interesting about remote and you there's a question someone asked around like how do you be innovative as a remote company or how do you and there's some amount of like randomness that you I think is probably desirable in an organization certainly you don't want it to be fifty or a hundred percent random right you you want some low level of like randomness in terms of people talking to each other or what's being shared yeah I think they're kind of alluding to like serendipitous chance encounters right weird like you know water cooler conversation yeah one of the things we do is process we it's called a pair buddies we're actually three people in these now I've gotten big enough where we have a bot that randomly just picks people that are in a slack channel and says hey two people should there's three folks now should like here's 30 minutes to chat okay and the idea is like you don't know agenda just like a 30 minute call over share whatever you're working on and talk talk through some of those ideas I actually think this idea is interesting I actually think a lot of companies or organizations group over optimize for serendipity like they're like what about that chance one but to me like serendipity like we were like some random thing happened all of a sudden we have a great idea like that's like hitting the lotto and to me optimizing for the lotto is very weird 99% of the company is like we have a whole list of shit that we have to get done and so to me it's like optimizing for that should always be the first priority not for the off chance of these other chance encounters I'm always wondering like what is the right ratio because I think there is some I think back to our hackathons right where this is a totally individual driven thing and we had great things that got built that no one would have like top-down plan to go build and surprised us like in terms of how popular it became but I think it works out better when you build up a kind of pressure and then it needs like a release yeah like we're all of a sudden it's like oh this is my opportunity right versus like yeah well not forcing it just like oh let's like have it all together and then maybe something will sort of bubble up I mean to me like a lot of it ends up getting solved by just knowing what other people are working on which is a problem across every company I've ever worked at before it's like I have no idea what Kevin's done in the past two weeks right like I know Kevin's done been on the podcast very secretive yeah I know Kevin's like crushing email but what is he actually been doing we we don't have that problem we have the other other problem which is like I have too much I have too many opportunities to learn whether people working on it's like how do I carry it down to like all right who are the people I need to know about what's working on so that I can do my job effectively so kind of wrapping up I'm curious about like if I were to be starting out a remote company what's the framework you would offer to say like okay you should do X Y and Z things and set yourself up for success to really get the most out of this I think it is one of the reasons why it is so hard to add remote onto an existing company is because remote well when you see folks talk about it and ask questions about it's always very process and tools based I think the honest answer is that it's more of a cultural change than it is a process and tools thing so folks that are starting out actually I think are at an advantage in this fact because there is no culture yet like it is you or it is your you know co-founders or whatever and you have the chance to like set up the culture in a way that encourages things that are going to work in a remote organization so again thinking through things like defaulting to action and encouraging empowering autonomy and how are we going to make decisions and thinking through some of those things in the early days being explicit about writing down and sharing all the work that you do and building it a habit into the organization to write down everything that's done and share that with colleagues as opposed to relying on context sharing over like a zoom call that's a ephemeral and can get lost that those are like the cultural habits and norms that are a lot harder to change in the future because you need everybody doing and I think there's a structural advantage for folks that are 100% distributed that everyone's in an equal boat they're all in the same boat right I'm all in my home office if other people aren't doing that thing then I I'm not going to be successful or happy in my my own job so you can take advantage of that in the early days by like it's a lot easier to set those that initial culture upwards like okay we we do want folks to be individually empowered to make decisions we want to hire folks that have like demonstrated this ability in the past we want folks that are good at written communication that like over communicate even like one of the things I often tell new engineers that are joining zapier and product designers is I have to encourage over communication a lot again coming back to the default no one talks like it is more important and it feels awkward at first to like be just sharing a status update with like an empty slack channel or a slack channel where you're not expecting a reply like that takes that's a habit to build where it's like you have to realize how useful that is to the person on the other end where hey I might get blocked on something that status update gave four hours ago helps give me some context on something that I'm should be doing or how to solve a problem in a certain way that otherwise would get blocked on you know request response cycle from them and especially across time zones that stuff so yeah being just setting up the right values around like autonomy and written communication are probably the two most important you guys wrote a book about this right kind of we did yeah it's a e-book on running a remote company it's a couple I think it's a couple years out of date from a process standpoint but it gets like the cultural what's the biggest right there what's the biggest thing you wish you could update in the book so like one I mean biggest thing probably how we've scaled async would be what I would go back and like to add to it in there like the book was written at a time where we didn't we had enough people that could somewhat reasonably consume all the context that was published there on a on a monthly base or on like a daily basis or weekly basis that's not true anymore like we've had to be a lot more and thoughtful and intentional about what are the is it a push first pull kind of mechanism what's the deep what's the kind of algorithm that powers the default feed view that shows content that everybody should be reading in the organization on a weekly basis and then what are like thought leaders and other people in this space that you guys follow for and like inspiration that other people should definitely check out yeah there's several folks that are bigger than us that have run remote organizations it's kind of a little bit of rare air once you get beyond like 50 people though or even 20 people fully remote folks like get lab is bigger than us envision is another organization that's largely remote automatic is another early one that we looked up to I think the biggest thing again we took away from those was not from not a process standpoint or even a cultural value standpoint it was hey it exists this is not impossible right like someone has proved that it is possible we are not having to trailblaze the fact that like it is possible to have a company with that many people that's fully remote now they haven't slightly I'm all those organizations have slightly different value mechanisms that we do so like that's what we're gonna figure out as we scale is all right how does that how do we apply that size of the organization to where we're at but yeah that's the biggest takeaway I would say is like remote is possible there's very large organizations that are doing it so you're in good company if you decide to build a fully remote company that's a great place to wrap it up all right thank you thanks great thanks Mike.