Y Combinator Startup Podcast - #115 - Mike Knoop and Kevin Hale

Episode Date: March 6, 2019

Mike Knoop is cofounder and Chief Product Officer at Zapier, which was in the YC Summer 2012 batch. Zapier moves information between your web apps automatically.Kevin Hale is a Visiting Partner at YC. Before YC Kevin was the cofounder of Wufoo, which was funded by YC in 2006 and acquired by SurveyMonkey in 2011.You can find Mike on Twitter at @mikeknoop and Kevin at @ilikevests.The YC podcast is hosted by Craig Cannon.***Topics00:43 - Kevin's intro01:03 - Mike's intro2:03 - How Mike and Kevin met4:03 - Market sizing for consumer software5:13 - Zapier's growth strategy today vs 20126:28 - Jumpstarting a platform like Zapier9:03 - Building an app directory before building a product11:03 - Applying to YC twice13:23 - Zapier after Demo Day14:48 - Zapier's first remote hire16:48 - Remote companies not being perceived as legitimate18:48 - Noticing remote was working then committing21:28 - Qualities to look for when hiring remote employees24:28 - Nina Mehta asks - What’s the best way to share work and knowledge across designers working on different parts of product without distracting from focused working time?25:58 - Remote mistakes in the early days27:33 - When to change modes of communication to allow for deep work29:28 - When to ask for someone's full attention31:33 - Product and design practices at Zapier34:38 - OKRs for teams vs individuals39:48 - Tools for remote teams43:48 - No internal email at Zapier46:53 - Keeping morale high in a remote team49:28 - What happens at a Zapier retreat51:43 - Remote design critiques56:43 - Serendipity and over optimizing for it58:33 - Setting up a remote company for success

Hey, how's it going? This is Craig Cannon, and you're listening to Y Combinators podcast. Today's episode is with Mike Knoop and Kevin Hale. Mike is co-founder and chief product officer at Zapier, which was in the YC Summer 2012 batch. Zapier moves information between your web apps automatically. Kevin's a visiting partner at YC. Before YC, Kevin was a co-founder of Wufu, which was funded by YC in 2006 and acquired by SurveyMonkey in 2011. You can find Mike on Twitter at Mike Knoop and Kevin at I Like best. All right, here we go. 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 WooFoo back in 2006. I was in the second bash 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, is that? Some early inspiration for us. Wow. What are the odds? All right, Mike. So what do you do? Yeah, hi, Mike. I am a co-founder at Zapier.

I'm our 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 like 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 have,

if you use multiple tools for your job and you're trying to, like you've manually copying and pasting data from one tool to the other all day as part of like 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 like send some notifications into Slack or into Gero 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 talk for a couple hours. But it was really interesting conversation. Basically I told you was like, this is what we did at Wufu.

And I was like, you should basically just do kind of a lot of the same things. Specifically. Yeah. Yeah, like think about remote work that you're going to be doing this for a really long time. And then integrations was kind of like, you know, patching a bunch of things together to a form builder was like a feature at Wufu. But to me, I saw like what they were doing was like turning that into an actual business. And so like a lot of my insights were like, this is what works for us. It's like 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 ZAPR could be and form software. 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 at 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 to become really big. We didn't realize this when we started, but we understood this later on was that like oh then people need to figure out like how do I collect data um from all these people that are coming to us and so form building contact forms etc like all of that became really relevant and 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's like the next step so these are like the three like stages of every company of like oh this is what I need yeah and they have just giant markets I remember early days at woofoo people had talked to us about like so what's your tam what's like your total addressable market. And we literally would 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 are 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 tan? 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, 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 explosion in SaaS software in the industry that is like the barrier 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 niche tools and bring them into the workplace.

So something almost out of necessity has to exist like Zappier. happier 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, 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, you know, 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 the initial, I guess, decision back in 2012 to build an open platform. Looking back, that was definitely one of the better decisions I think we made in the early days. We built the first 50 or 60 apps on Zapier ourselves, Brian Wade and I, just to bootstrap that engine. And when we launched in 2012, I remember we had live chat, I think O'Lark on the site at the time. And we, you know, we got literally, we launched in TechCrunch and had three days straight where all the chat messages were 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 partners can build those things on Zapier. And at that point, we had enough inertia momentum from the launch and from early users that were really excited about the product. And how do you jumpstart that? Because I think that's like everyone, especially I remember back then, people were talking about the platform. You got to be a platform.

Like how can you be like Salesforce? And the thing is jump starting that is difficult. Like just because you put up an API and tell people like, hey, hey, if you go and do this, then you're going to get benefit. Like, how did you guys in the. 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 heard the heuristic of like once you get big enough where you could carve off one percent

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 that 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 of the the time, integrations that were maintained and scaled and were adding more to it. And they got let for free. So it allows them to go to 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. Yeah. Like there's actually a way for you to do this. Go over here. There's value with them beyond, you know, just user acquisition that incentivized in the early days to build on Zapier. Did it end up being that like a lot of people on the front lines like recommending you were then support people? Because for us, like 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 stopgat. Here's how I satisfy you. That was very common. We get listed a lot in like help docs, help documentation. Sales is also another avenue where we get mentioned. a lot where we can Zapier basically helps them close a deal with the customer that they're trying

to upsell or convert into a paid plan. Was that like the start of like your dominance and like SEO stuff? It's like, oh, we get people sort of linking to us. That was a little, that was actually earlier. So 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. Yeah.

The very first thing we did when we sat down was we built our app directory, which was lining 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. Yeah.

But we had lining pages for, I think, a few hundred at that point. And we had email collection on the pages and classic lean startup of just trying to understand. engage 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 know 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. And like, I mean, 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, like the core mechanics of

mapping data between apps all came out of that weekend. And I think we built PayPal and High Rise and Twitter, I think we're 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? So 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. And during the demo, we said,

hey, wouldn't it be fun if we could get up on stage and have people actually, like, tweet something live and then have people pay us something on PayPal, and then you could actually see Zap, like, the prototype of Zapier run and pull that data into high rise. The idea was like, oh, we could aggregate, you know, 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. Right. So it kind of came out of a single use case and we worked backwards from that. And so at what point do you end up doing YC? Yeah, 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's 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? We're 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. Still, like, optimistic with a prototype. But, yeah, once we got the email objection, at that point, we had enough hints of success. We were like, we're going to keep working on this. And it gave us actually more motivation, I think, to keep burning 40 hours and nights and weekends a week for the next few months. months. And then the second time we applied, you know, by that point, we had had hundreds of conversations and chat logs and messages from actually a lot of folks in like the YC network were even using the product. It was invite only at that point. We are having folks pay. We had our

first 10 people pay us 100 bucks to like validate it. And we turned down the price like, I think, five bucks. And we had a few, you know, 100 people who paid us that amount of money. So 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 still a full-time student, actually, a grad student. I get the one star of dropping out to start Zapier. But yeah, after like our full-time jobs were over, you know, five o'clock, we would go either back to our own apartments and work separately or we had one of our bosses let us run at like, use one of his offices to co-work out of in the evenings.

And we'd go put in, you know, work until midnight, 1 a.m. every night working on Zapier, basically. So it's kind of two full-time, two full-time jobs for the first few months. Yeah. And so demo day happens. And then where do, what do you go? What do you do? Yeah. So obviously why I see one of the things is moving out to California. So that was kind of the, 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 were thought like 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 on schedule. And it hadn't got to the point where we could supplant like our full time income. So it was kind of out of necessity that we were running the company, the building it that way. 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 all time, full time on it. After 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 helps 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 barrier. But we didn't want to. And we thought back to like, hey, we were kind of doing Zapier remotely before

startup weekend or before YC. Like, 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 Missouri and then back out to California to work Brian and 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 a part of the time. So like, let's just give it a go. So it was 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? 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 Base Camp at the time, Wufu, at the time, like we had seen at least small organizations that had been successful at billing 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. 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.

Like 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, 100, we have like 50 million an ARR. Like, yeah, we're a real company.

But, yeah, it's still one of the reasons why 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. But how did you not get caught into that trap? That's the thing. It has to come from the founders, obviously. And so is it one of those things like, how did we believe that it was not a side project? Or like, why is it that you never felt like you needed to have an office? No, it's just like pure 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's very radical to be like, I'm not going to have an office.

Yeah. I mean, when we were talking to like investors and whatnot through YC, lots of raised eyebrows, we'd get folks turning us away strictly because of that. Even some of the folks who did we went forward with like still would be like, hey, when are you going to, you know, 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 their, in those early couple of first years between, you know, 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 and Wade, around like, hey, this is, 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, 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 costs. We're like, we can't afford an office. But later on, as things were working, we were just like, if you're, if you're 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.

Right. Does we still have the best exit to investment ratio? Uh, the ratio, yes, in terms of like how much percentage of the company that YC owned or are any my angel investors to like 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.

He raised what? We raised $1,000. $11,000. $18,000. YC was $18,000 then. And we raised money from. two angels, PB and PG, and it was $50,000 age. 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 nice and weekends. Like part of the reason and ambition we've, of wanting to like start Zapping 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 that's a that is a company value our number one values default to action and that permeates all the way from the very beginning where we wanted to like we wanted to like build zapier as a company that we would want to 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 830 in the morning every day and like control my own schedule and be able to like just go no go I did. 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 want to be working alone for people who actually do? And is there a good way to do that? Like, how do you get the sense of people are really going to... Is it a company full of libertarians who care about freedom? Or is it a company full of introverts? I imagine it's not one of 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. In the past, it's very easy to lean on your work as that like a social connection. That is a very rare healthy mindset. And if you're if you're going to make a 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 and treats.

You'll see their faces and names all day in Slack. But whether it's like, you know, like side projects or hobbies or like close friends or religion or family or whatever it is, like you'll definitely want to 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 going to be appropriate for remote work? Past experience with the remote is pretty good as 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 going to be effective or not is like how much they can uphold that first value of like defaulting to action. So 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. It 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. And 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 in order for folks to have the information that they need to be able to default 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 metta, 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 a interesting underlying, I guess, assumption here or observational, I could say about this, which is one of the benefits of remote work. a part 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. There's 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 and coordinating with your coworkers. Because I can just tap you on the shoulder, Kevin, and like ask you what you think of my, the work I just did. Where it is 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're, want to communicate. What were some mistakes you guys made in the early days? You said you have to figure this out early 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 how to 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

I the default communication mode is I'm going to 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 yeah so it's like we're taking two people's times up for this um in a remote organization the default is 100% the opposite in the spectrum, which is people don't communicate at all. Like, if you're, say you'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 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. 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 like write these rules down. 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 to a lot of her 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 be faster. 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's schedule.

And so for us, we changed the role 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 said it like at the end of the week on Friday when the team meets together. it ended up being like 90% at a 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. 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 respect is when you 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 you say, like, okay, I'm going to 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 going to be able to get it in a remote company, right? I may not have a path where I can go over and tap you on a shoulder. I might be able to, you know, 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-locate. 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,

you know, one is in Slack, if you tag somebody in a message, like at tag them specifically. It's kind of the social norm to be to acknowledge that within 24 hours. So we have some expectations like that. And the reason we have said 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 going to be some asynchronosity 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,

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 giving contribute value to the goals and how do I better serve our customers here. Yeah. If you're the type of person who like as soon as it get blocked, I'm just going to sit here until I'm told what to do next, you're not going to 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, at Woofoo was like, I was the only designer. We never grew to be on 10 people. So it's easy to communicate with yourself. Exactly. So we never ran into that problem. So I'm really curious. What did you, what's done differently for your design

team and product teams to make that sort of work? Yeah. I think one of the most important relationships in the organization is the relationship within 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. How 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, someone 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. And that for, it 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 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 they have their own unique things they're thinking about all the time, right? Engineer might be thinking all day about the user experience. 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. kind of creeps into the organization where it's like, well, I want the designer to do this or run with 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 stand up type thing? Yeah.

Every team is 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 process. So you give a lot of autonomy to different teams to try a bunch of stuff. Yes, we do. okay in okayr's are kind of our framework for how we pull how how we make that not chaotic if if that makes sense um 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 specific what does that mean

um what are what are what's our 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 okay um or if it's design what's the like ownership between and where is that handoff like what's the 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, we use GERA 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 the product development process across the whole company.

So we can get a sense of like, where are we doing well, where are we not doing well, identifying issues where we might be overinvesting. in feature work or underinvesting in feature work or tech debt and things like that. So there's like some level of consistency that's important. But we do generally try to give a lot of individual autonomy of these like EPD trios. How are the teams created? Mostly on a like, do you guys assign them or the people kind of like have a draft or? They are picked and like we hire into them, I guess.

So we'll create a lane at the like leadership level of the organization. Like here is 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. And we'll then staff into that. So we've got a decent recruiting team now. So whatever team that someone's on, they kind of stay with that team all the way through the life of Zapier?

Mostly. They're long running teams. I'll say that. We've had folks, which I wouldn't say we've actually, 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 restow from one team to another where there was like, another part of the product they wanted to work on and they had some expertise that could be

used somewhere else. Maybe we brought in, you know, maybe this person's like a really senior level, uh, experienced at engineering. We've just brought in like more of a staff level or associate level engineer. We want to like get up to the work together. What's the timeframe for like these OKRs? Like are they like quarterly goals, like yearly goals? Like you probably have a range of them.

Yeah. Annual and annual and monthly tends to be the two kind of extremes. Annual just to know like, all right, where are we, what are we working towards over the course of year? What is this product team trying to accomplish over the course of 2019? And then kind of monthly check-ins against that where they break those down. And so can you break down how an average team might handle tracking for a no-career? Like, how does that workflow actually go down? Yeah. This is still new to the organization. So I feel like I need to give the coffee

that we're learning a lot still with this. We've been practicing with OK hours at the exact level for the last two quarters in 2018, which gave us enough confidence that, hey, this is actually a very effective tool for us to help align and allow everyone, all these different teams and people in the organization to be autonomous and default to action in ways that they want that 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. I don't think we're quite there yet, is you've got some high level of direction being set by the leadership of the organization. What are we trying to accomplish, right? In Zappar your case,

We're trying to build a piece of productivity software that anyone can use. How do we get Zapier adopted by, you know, tens of millions of people someday? And you've got this high level direction and strategy being set. And then at the team level and lower in the organization, there's a lot of work that is happening that needs to figure out, okay, where is that aligned and how does that bubble up? And there's kind of a meet in the middle approach where you kind of want the work that's happening, 50% of it to be kind of, top down driven and I think 50% of it being bottom up. Because in reality, the exact team leadership is never going to have perfect insight

in all the pieces of work that happen across the organization. And I don't think that's what something like OkR's 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 tradeoffs and have discussions. Like this is one of the things that's great about writing down our process documentation in Zappi, 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. It also, discussions can drift when it's not like tied to the artifact. Yeah. What other tools do you guys use?

Like, I don't have any doubt that you guys just like use Zapor itself to help you guys. We are heavy zabries, yes. You use okay artists. But I remember in the early days talking to you guys, you guys bought a lot of tools for yourself. And I'm just wondering like right now what's like the most helpful tools that you guys are using, either that you've built yourself or that like other that you're using from other companies. Yeah.

The one that, um, I actually built this one in the early days. It's a tool called async is the name of it internally. It's an internal blog essentially. Um, we use Slack as kind of our. our company office for better or for worse. Like this is where folks usually log into in the morning. This is where work gets talked about. We've got, but one of the trouble with that, especially as we scaled, and anyone,

any remote company or any team that uses Slack will be able to tell you this. It gets the overwhelming amount of noise in Slack. How do you keep up with Slack? And very early on, we set the expectation that Slack is not a tool you're expected to keep up with in Zapier. 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 like the social comfort to be able to leave channels without feeling awkward just because it feels like pressure it's like I'm behind on my homework there's some social pressure I just end up muting those channels rather than leaving them yes yeah like we actually have like a course working on for how to like be effective at using slack yeah but this is in the early day so we so we set that expectation of that's how we use that tool um one of the things that kind of was missing that I saw was What is our like more thoughtful to use me like the Daniel Kahneman idea like slow thinking

version of Slack? Like Slack is where work gets talked about. Right. It's like quick responses in the moment. I need a decision. Okay. Where does our final work get talked about? Or where does our more like deeper work that we're thinking more long term and putting

together like where are our final reports getting shown to the organization? And how does that get shown to, um, how do the right people get notified that like I have something I need to read and make a decision on or think about? So 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.

It's really old. It is. Yeah. We used it at Zapier for good six months, and it was pretty good. It started breaking and we wanted to customize it. And this is one of the most interesting things why I like investing in tools is you can tweak and change them to match the like level of company you're at essentially as your company gets bigger you're going to run into these new bottlenecks and you can start like layering in and customizing

the tool instead of having to go like throw the tool away and pull a new one in and relearn it so this in the early days p2 started breaking for us it didn't scale it didn't tie into our off system was funny enough the reason why I wanted to rebuild it um so I built a version of internally called async which can just internal blog and this was kind of the tool that was One of the cadences that we have in Zapier is every week we ask everyone to write a Friday update for what they worked on. And this is kind of the heartbeat of the organization. And so that goes up on the blog. It goes up on ASync.

Yeah. And this worked really well. Like in the early days, you got 20 people, 30 people. You get to read everybody's Friday updates. You get to know everything that's made, everything people are learning, all the work that's happening. Well, you get to 7 or 80. 100 blog posts. Yeah.

That starts taking a full day just to read like all the information. So you start to run into the same problems as even Slack does where it's information. overload. Yeah. But because we own the tool, we can, we can tweak it and tailor it to how we, like, are we want to run the organization and how we make decisions and how we want communication to work. We started building like a default feed view where it was a curation layer in terms of,

okay, who are your immediate direct reports, who are the folks you need to follow? You can follow folks. You can create custom feed views to like build the curation. We work with managers to like onboard new employees to set up their like views in the right way so that it's curated so that they get them. just the information they need. And so 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. Full stop. None. So we use email. Email is using a few ways in Zapier. It's we, of course, we do email support. So we use help scout and all of our emails.

Basically, if there's any internal to external communication, so like when we're talking with our partners or with customers, obviously that happens over email. Yeah. But internally, there is no. Slack and Async. Yeah. Those are our tool. We have one.

We also use Quip for a long-term, like long-form documentation. It is a, it's a wiki. It's a collaborative wiki. Kind of Google Docs mixed with the wiki. And that's more for like documentation. Yes. Yeah. Documenting processes, hiring rubrics, things that kind of 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 Wufu was like, how much time we spent development-wise on internal tools, actually. It was like almost like 30 to 40% of like development time was like, I was building stuff for ourselves. That's why we were able to grow and only be at like a 10% company for so long. And so like what is that ratio for you guys?

And like do you have special internal tools teams like, you know, that Facebook is kind of famous for? We did last year. We had invested in a internal tourism, which was helping scaling some of the async software that we were talking about. I, for better or worse, have been kind of the internal tools manager for the last six months. I was building, mentioned this OKR. We actually built our own OKR software into ASync.

And one of the beautiful parts of it is like when you're updating your OKR, it's got annotations that tie into the post you're writing. So we've got this nice long running graph of, hey, here's this metric I'm moving over the year. You can see, oh, here's where we launched this feature. Here's where we made this decision. And you can see it annotated on the graph. But right now it's kind of just organic.

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, actually. Like, I was just listening to A-Sync, I'm like, I know, remember this for us. Like, a lot of our internal tools, I ended up being like YC companies down the line in the future. I'm like, oh, God, that's a startup right there.

More recently, most of the internal things that get built in Zapier today are, like, apps on Zapier. We have a lot of folks in our engineering team and even more broadly on a support team and product design where we'll build features into Zapir by building an app on Zapier. And this is kind of where some of like the innovation of Zapier comes from is like quite a few of the most popular apps on Zapier were built by like one engineer and a side project at like 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. Maybe it's the ability. But it actually made it out in the product. Yeah. That's actually the biggest criticism for lots of corporate hackathon.

is like people spend all week and get really excited and they never make it to the life of day. Yeah, we tried pretty hard to pick our packthon projects and we curated them in a way that we thought that there was some value that could eventually make it to the make it out to customers in some format or it would help customers in some way. So what are the other things you guys do to kind of keep employee and founder morale high across a remote team? Yeah. We do, probably the biggest thing we do is we do two company retreats a year. even the fact, even though we're 100% remote, there is still a lot of value for getting in person. And we don't like discount that. Yeah.

You get to build a lot of empathy. You get to build relationship with folks. And it allows you to kind of be, assume best intent the rest of the year. Right. When you're when you're in Slack and you're working on that tense project and someone leaves, you know, writes a message that might be a little more curt than it should have been. It's like, oh, I can hear their voice at my head. Like I know who that is. I understand who that is.

Like I'm not going to jump off and like assume that. They were trying to be mean to me or something like that. And that helps smooth over a lot of 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 it's just that's one of the first things that can easily get lost when you're like intense moments. So there's a lot of value for building in-person relationships still. So 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.

How long are those retreats? It's a week. And then 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. We've mentioned the hackathon. We've traditionally done like a hackathon most of the week. And then we would have a couple days set up for teams to kind of break out in their own

individual silos. This past retreat, we tried something different though. We tried giving one of the things we do a lot. 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? Like how often? I mean,

anytime we're doing a company-wide thing, you're probably going to be a survey sent out about like it to get feedback so we can improve it for next time. Over email? It is tied into Slack actually for how the survey gets sent. I do. There is an email though, too. I'll admit that. You're not there yet.

Yeah, I still do keep my Gmail tab open. but yeah there there is like a slack time but we yeah 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 what's the best thing you guys do at the retreat that you didn't do it on the first ones like what has changed that you're like this is way better to do it this way uh so this last time the thing we experimented with was we added unstructured time we had always planned every hour of every retreat to date where fascinating it's a fascinating it's

I know. It's interesting that you didn't think about it earlier. I know, right? It's probably a bias that's like being like thinking, we're in a remote mindset, right? Which is like design the process. How do we want people collaborating? How do we want them connecting? And like make that happen.

And I think some of our like, you know, managers feel responsible to make sure their teams are taking care of and people know what they're doing and what there should be spending time on. So there was just the sense where from the top from management perspective, like we are over planning all the hours. And one of the things that that prevents is, um, cross-team coordination or cross-team communication or what if like one person from the data team and one person from support and one an engineer like had this cool topic that they talked about it maybe one of our unconference sessions and they wanted to go hack on an idea like there was no time for that to happen in the past format and it just 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 work day but figure out how to best utilize this time with your team and your peers and How did you know it worked well? Mostly through feedback at this point. I was anxious about it going in.

So we added this process in because of feedback we got before. People had specifically asked for time to do this. So we added it in. 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 their retreat. Just do what I'm going to go do normal work stuff. Yeah, work on my roadmap or work on support tickets in isolation. But we want to take advantage of the fact we're here.

So I over-emphasized in almost all my conversations with the team leading up to the treat to, like, take advantage of the time. And when I walked around and just observed the different groups of people that were, like, coordinating in those afternoon sessions, I was surprised at how many people took advantage of the time, like, given my anxiety, I guess, that it was not going to be able to be able advantage. I think it shouldn't be surprised when you're hiring a bunch of people who are, like, default action, self-driven, et cetera, and then you bring them all together, like, they're going

do the right thing. Yeah. It certainly worked out well. And I will continue to do something like that in future retreats, I think. Can we talk about, I'm curious, like, how do you guys do design critiques? Like, how does that work in this collaborative environment? Because it's so difficult, like, to even do it in person. Yeah.

And so, like, how do you, and you guys have an interface that has to bridge hundreds and hundreds of apps together and hundreds of different types of features together. And so it's so complex. And I'm trying to think of like doing that without people really close and diving deep on the problem. Like how does that work for you guys? I guess I'd be interested to ask like why what assumption do you have that makes why what like previous belief or experience do you have Kevin that says like 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 like for design in particular I it's hard to like point circle. resketch, etc. There's some things that on pen and paper

in person I can show. Now I know that there's ways to do it where it's like, oh, I can do this, show it by video, et cetera. But it seems slower and more inefficient. I'm just wondering, like, is there things that you do to compensate or is like you think about it differently?

Yeah. It comes back down to being explicit again. So one of the exercises I've done quite a few 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 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 is intentional 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, I was like maybe at a 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 sit at their table right and draw another paper. And they'd hold it up and they'd talk about it. And I had them take a picture and post on the Slack channel. So there was like a higher

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 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 safe. 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. It'll 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, um, a Tuesday, Thursday, um, essentially design review across several product teams. So we would invite several product managers.

several product designers. And the Tuesday 3rd is a cadence was how we built in that feedback week process, where it's like, okay, I want to show something to 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 another cycle, there's a forcing function to turn around and iterate and go deep on it. In 48 hours. They got 48 hours to then turn around and show it back on Thursday and show it again.

So 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's built up this interesting norms around like what is Zoom etiquette, right? Like when to unmute 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 you on 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 there's a question someone asked around like, how do you be innovative as a remote company or how do you be? 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 50 or 100% random.

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. Yeah. One of the things we do is process. It's called a pair buddies. We're actually three people on these now.

We'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, or three folks now should like, here's 30 minutes to chat. Okay. And the idea is like, no agenda, just like a 30 minute call over, share whatever you're working on and talk through some of those ideas.

I actually think this idea is interesting. I actually think a lot of companies or organizations, the group, over-optimized for serendipity. Like, they're like, what about that chance? But to me, like serendipity,

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% in a 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 where all of a sudden it's like, oh, this. This is my opportunity for this.

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 never worked at before. So, like, I have no idea what Kevin's done in the past two weeks, right? Like, I know Kevin's been on the podcast with me.

Very secretive. Yeah. I know Kevin's like crush an email. But like, what has he actually been doing? We don't have that problem. We have the other problem, which is like, I have too much. I have too many opportunities to learn whether they're 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, while when you see folks talk about it and ask questions about it, 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 how I think are at an advantage in this fact, because there is no culture yet, like it is you or you're 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 and 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 ephemeral and can get lost. Those are like the cultural habits and norms that are a lot harder to change in the future.

Because you need everybody doing it. 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'm not going to be successful or happy in my own job. So you can take advantage of that in the early days. it's a lot easier to set those that initial culture up where it's 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 oh 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 overcommunication a lot again coming back to the default no one talks like um 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 you gave four hours ago helps give me some context on something that I should be doing or

how to solve a problem in a certain way that otherwise would get blocked on a, you know, request response cycle from them and especially across time zones. That's tough. So yeah, 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? 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 values, right? What's the biggest thing you wish you could update in the book? So like one, I mean, the biggest thing. Probably how we've scaled async would be what I would go back and like to add to it. in your 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 um what's the 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 um um and then And what are 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 error once you get beyond like 50 people though or even 20 people fully remote. Folks like GitLab 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 have slightly, all those organizations have slightly different value mechanisms than we do. So like that's what we're going to have to figure out as we scale is. All right. 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 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. Thanks, great. Thanks, great. All right. Thanks for listening.

So as always, you can find the transcript and video at blog. dot ycombinator.com. And if you have a second, it would be awesome to give us a rating and review wherever you find your podcast. See you next time.