Mike Knoop on Product and Design Processes for Remote Teams with Kevin Hale | Transcription

Note: This transcription is split and grouped by topics and subtopics. You can navigate through the Table of Contents on the left. It's interactive. All paragraphs are timed to the original video. Click on the time (e.g., 01:53) to jump to the specific portion of the video.

Introduction Of Speakers

Kevin's intro (00:10)

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 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 today, is that? - Some early inspiration for us. - What are the odds?

Origins And Growth Strategies Of Zapier

Mike's intro (00:30)

All right, Mike, so what do you do? - Yeah, I am Mike. I am a co-founder at Zapier, I'm a 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 copy and pasting data from one tool 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 JIRA, whenever those issues get close, you could set that up just as one example. - Cool. - And how did you guys meet 'cause you've known each other for a while. Kevin and I, yeah.

How Mike and Kevin met (01:30)

- 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 really interesting conversation. Basically I told you, it 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 gonna 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 a natural 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 Zapier could be and form software is such a good use case because the data never ends in a form. You wanna do something with it. Usually it's once someone's in that's a form. I wanna 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 myself out there? And so you was 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, oh, 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 Wufu, people had talked to us about like, so what's your TAMM? 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. I sometimes think those exercises while useful are sometimes like little misleading. It's misleading when your market is so ridiculously large.

Market sizing for consumer software (03:30)

Yeah, when you're thinking about like a consumer adoption, you don't ask Facebook, what's your TAMM? 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, excuse your explosion in the software in the industry that is like, the buried 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 niche tools and bring them into the workplace. So if 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 gonna be incentivized to go build thousands of integrations with everyone else. - Yeah. - But at this point-- - Yeah, 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.

Zapier's growth strategy today vs 2012 (04:40)

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 ourselves, Brian Wade and I just like bootstrapped 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 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 gonna 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 we, it was almost out of necessity. We don't have money to hire. We can't build these ourselves. So we have to get, if figured 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. - How do you-- - That carried us. - Jumpstart that. 'Cause I think that's like everyone, especially I remember back then, people were talking about the platform.

Jumpstarting a platform like Zapier (05:55)

- Yeah. - You gotta be a platform. Like how can you be like sales force? 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 gonna 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 SaaS company, every software company eventually get big enough and you wanna 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 stand alone 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 wanna 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 time integrations that were maintained and scaled and were adding more to it and they gotta let for free. Oh, I don't know. 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 just 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. There's actually a way for you to do this. Go over here. There was value to them beyond just user acquisition that incentivizes in the early days to build on Zapier. They didn't end up being that a lot of people on the front lines 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 it ended up being, I would imagine a lot of them were like, "Hey, here's the stock guy, here's how I satisfy you." That was very common. We get listed a lot in 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 your dominance and SEO stuff? It was 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, the 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.

Building an app directory before building a product (08:30)

We were building these manually. We had a very big opportunity cost in 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, and we had email collection on the pages. And classically in startup, we're 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. - 'Cause 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 gonna pitch a different idea at that startup weekend. And 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 like mapping data between apps all came out of that weekend. And I think we had, we built PayPal and high rise in Twitter, I think, where the first three apps go. - 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, everyone, the mechanics of the weekend as 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 get up on stage and have people actually 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, 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. - Great. - So it kind of came out of a single use case and we worked backwards from that.

Applying to YC twice (10:30)

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. - Yeah, 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 gonna 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 objection, at that point we had enough hints of success. We were like, we're gonna keep working on this and it gave us actually more motivation. It keeps 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, we're even using the product. It was invite only at that point. We were having folks pay, we had our first 10 people pay us a hundred bucks to validate it and we turned down the price to like, I think five bucks. And we had a few hundred people who paid us that amount of money. So there's 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, 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've had one of our bosses let us run to 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, one 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 you go?

Zapier after Demo Day (12:50)

What do you do? - Yeah. So obviously YC, 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 fill in at 40 hours. - 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, you think about our ambitions, right? It was like, hey, we wanted to get this to a point where we could spot ourselves, be our own bosses, control our own 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 of 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 all time, full-time on it. After demo day, we, actually leading up to demo day, I remember one of the problems, early problems you 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 mid-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 for 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.

Zapier's first remote hire (14:15)

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. Like, we, 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, let'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 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 who want to hire want to be remote. And I had to be remote for 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 or we 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 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. Because 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 for my home. And so like, is that an, like did you guys even struggle at all about that? Was like, how are we going to be a real serious company without this? - It didn't hurt any efforts in terms of scaling the organization.

Remote companies not being perceived as legitimate (16:15)

It certainly, even, it's funny how pervasive that idea is because even, I remember probably last year or the year before we'd sell people joining the organization who'd comment like, yeah, my parents want to know if I'm working at a real company right now. And it's like, well, yeah, we have like, you know, 100, 100, we have like 50 million ARR, like yeah, we're a real company. But yeah, it's still, this is one of the reasons why like some of the PR things would be 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 company. - But how did you not get caught into that trap? That's things like, it has to come from the founders, obviously. And so, is it like-- - Like, 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? - Well, it's just like peer pressure around startup norms. - Exactly. Like, why did you not succumb to that? 'Cause that's often what I see a lot of people do is that like, I'm spending this money 'cause I think this is what it looks like to normalize me. 'Cause 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 that 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 gonna, 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, in their, in like 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.

Noticing remote was working then committing (18:15)

I do remember specifically having that conversation with like Brian away around like, "Hey, this is working." Like this doesn't, you know, 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 cost. We're like, 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 gonna 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, 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? - Oh, the ratio, yes. In terms of like, how much percentage of the company that YC owned or any of 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. - You raised what? - We raised-- - Oh, I see money. - And 18,000 dollars. 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'd like to work. In the early days, like I think it goes back to this, that nice and weekends. Like part of the reason inhibition we wanted 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 is a company value, our number of values 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 want to work at. And if I'm going to go work at it 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 want to be working alone for people who actually do? And is there a good way to do that?

Qualities to look for when hiring remote employees (20:55)

Like how do you get the sense of people really going to-- - Like is it something 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 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. It's happier or any distributed remote company. Like in the past, it's very easy to lean on your work as that social connection. - That is a very rare healthy mindset. - And if you're going to make it work at Zapier, you have to find a social network that's outside the company. You'll get a little bit of it because we do 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, you definitely want to have one of those networks that's outside the work environment. - Related to this, what are other major characters you look for that you know, this person's going to be appropriate for remote work? - Past experience with a 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 post-past remote experience and they've been very successful, but there is a learning curve attached to it. I think the biggest, one of the biggest things that 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. 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, it'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% 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 to action and be able to know how to operate in this organization. - So you mentioned this, I heard this in another podcast about overlapping time zones and making sure you don't unblock and unblock people. Nita Mehta, who I know, hey Nita, 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 observational, 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.

Sharing And Communication In Remote Work

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? (23:55)

A secondary benefit that I think isn't as obvious is that when you're actually doing your job, the best work gets done not when you're sitting next to someone and 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 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 the process part of the organization gets so explicit is, all right, in a co-located company and 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, where it is a remote team, we just have to be so much more explicit about what are the processes, individual people, individual teams follow when they wanna 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.

Remote mistakes in the early days (25:25)

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 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 it's like we're taking two people's times up for this. In a remote organization, the default is 100% in 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 like just a blinking text cursor, right? And 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-- - Do you guys 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.

When to change modes of communication to allow for deep work (27:00)

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, 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 gotta 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 say to like all discussions that have been paused, we set a time for this and we set it 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 realized it's not that big of a passion. - They didn't even have to have a discussion. They just like, 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 surface 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's a, I mean, it's a good question.

When to ask for someone's full attention (28:55)

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, 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 and 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, you know, one is in Slack, if you tag somebody in a message like @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 have set 24 hours is because we folks all across the world, the sun never sets suns up here, I like to say. So yeah, we have some of these social expectations where there is gonna be some asynchronosity in how the organization works and operates. And it's one of the reasons why I think hiring for default to 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 getting 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 they 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 promote companies. So how big is Zapier right now? Like how many employees? 200, we just cross 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 like at the beginning of the week. 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.

Product and design practices at Zapier (31:00)

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 Rufu, it was like, I was the only designer. We never grew to be on 10 people. So-- - You had to communicate with yourself. - Exactly. So we never ran into that route. 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 with thing, 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 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 Ocares, as like an alignment mechanism, and like a designer and a PM and an engineer all own share and Ocares. - A lot of companies can have weird definitions of Ocares, 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 for, it gives like, it gives a lot of focus to that team and it also gives, it kind of helps elevate everyone's role to be thinking about like the impact in the customer first. I think what the thing I've noticed that happens in Scaling Zapier is there's a tendency for engineering a PM designed 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 and 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, 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, it's something we're new, we're starting to do, but so far it's been pretty fruitful in building that 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 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.

OKRs for teams vs individuals (34:05)

OK, and OKRs are kind of our framework for how we pull, how we make that not chaotic, if that makes sense. >> It's like-- >> I like to think about, 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-- >> Are you specific? What does that mean? >> 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? >> OK. >> 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 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 over investing in feature work or under investing 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 to these like EPD trios too. >> How are the teams created? >> Mostly on a-- like do you guys assign them or do 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, hey, here is a new opportunity we wanna go after. Here's an area of the product that we aren't addressing or part of the conversion funnel that we wanna improve and we'll then staff into that. So we've got a decent recruiting team now. >> So what of a team that someone's on that kind of stay with that team all the way through the life of Zapier or? >> It, mostly. >> They're long running teams, I'll say that. We've had folks switch, I wouldn't say we've actually, our earliest product team is only two, a year and a half, two years old. So in some of those folks have shifted, we've had folks restate from one team and 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 experienced at engineering. We've just brought in like more of a staff level or associate level engineer. We wanna like get 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 monthly tends to be the two kind of extremes. Annual just to know like, all right, 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 an OKR? 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 hat that we're learning a lot still with this. We've been practicing with OKRs 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 the ways that they want, that we wanted to start rolling it out with 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 leadership of the organization. What are we trying to accomplish, right? For example, in Zapier 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? And you've got this high level of 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, OK, 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 OCRs 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. Like, this is one of the things that's great about writing down our process documentation in Zapier, writing down our decision making processes. 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, like with different ideas in their head about what is important to have it. It just removes this layer of like 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 Zapier itself to help you guys. We are having these libraries, yes. You use okay hours. What are dog-fooding? 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?

Embracing Remote Work Culture: Tools, Practices And Retreats

Tools for remote teams (39:15)

Either that you've built yourself or that you're using from other companies? Yeah, the one that I actually built this one in the early days, it's a tool called Async, is what the name of it internally. It's an internal blog, essentially. We use Slack as kind of 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 about one of the trouble with that, especially as we scaled, in 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 on 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 the social comfort to be able to leave channels without feeling awkward. 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. We actually have a course working on for how to be effective at using Slack as happier. But this is, in the early days, so we'd set that expectation of that's how we use that tool. One of the things that kind of was missing that I saw was, what is our more thoughtful-- do you see me like the Dan O'Connorman idea, like slow thinking version of Slack? Slack is where work gets talked about, right? It's like quick responses in the moment. I need a decision. OK. 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? Where are final reports getting shown to the organization? And how does that get shown to-- how do the right people get notified that I have something I need you 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 that it was basically-- 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 worked-- we used it as happier 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 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 layering in and customizing the tool instead of having to go throw the tool away and pull into one end and relearn it. So this, in the early days, P2 started breaking for us. It didn't scale. It didn't tie into our auth system. It was funny enough for the reason why I wanted to rebuild it. So I built a version of internally called Async, which can just internal blog. And this was kind of the tool that 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. And this worked really well. In the early days, you've got 20 people, 30 people. 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. Well, you get to 7 year 80, 100 blog posts. Yeah. That starts taking a full day just to read all the information. So you start to run into the same problems even Slack does where it's information overload. But because we own the tool, we can tweak it and tailor it to how we want to run the organization and how we make decisions and how we want communication to work. We started building a default feed view, where it was a curational layer in terms of, OK, who are your immediate direct ports? Who are the folks you need to follow? You can follow folks. 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 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, then.

No internal email at Zapier (43:15)

So we use email. Email is using a few ways in Zapier. Of course, we do email support. So we just help scout in all of our emails. Basically, if there's any internal to external communication, so when we're talking with our partners or with customers, obviously that happens over email. But internally, there is no mail. It's just slack and async. Those are our tool. We also use QIP for long-term-- 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 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 how much time we spent development-wise on internal tools, actually. It was almost 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% company for so long. And so what is that ratio for you guys? And 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 an internal tools team, 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. My manager for the last six months, I was building this OKRs. We actually built our own OKRs software into async. Gotcha. And one of the beautiful parts of it is like when you're updating your OKRs, it's got annotations that tie into the post-year 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. Like, teams make their own stuff. Yeah, it does tend to be a little more organic. All I was saying 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 async. I'm like, I don't remember this for us. Like, a lot of our internal tools, ended up being like, why see companies down the line in the future? And so I'm hearing async and I'm just 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, and a support team, and product team, where we'll build features into Zapier by building an app on Zapier. And this is kind of where some of the innovation of Zapier comes from, is quite a few of the most popular apps on Zapier were built by one engineer. And a side project at our 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 on the product. Yeah, eventually-- That's actually the biggest criticism for lots of corporate hackathons, is 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 hackathon projects, and we curated them in a way that we thought that there was some value that could eventually 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 keep employee and founder morale high across a remote team? Yeah, probably the biggest thing we do is we do two company retreats a year.

Keeping morale high in a remote team (46:20)

Even though we're 100% remote, there is still a lot of value for getting in person. And we don't discount that. You get to build a lot of empathy. You get to build relationship with folks. And it allows you to be assumed best in the rest of the year. When you're in Slack and you're on that work in that tense project, and someone leaves-- write some message that might be a little more curt than it should have been. It's like, oh, I can hear their voice on 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. 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 that's one of the first things that can easily get lost when you're in tense moments. So there is 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 town. How long are those retreats? It's a week. And then-- --and then-- --what do you guys do during that time? Is it just hanging out? Or I mentioned the sun 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. This password tree, 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? How often? I mean, anytime we're doing a company-wide thing, you're probably going to be a survey sent out about it to give feedback so we can improve it for next time. It's like for 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. Oh, OK. You're not there yet. Yeah, I still do keep my Gmail tab open. But yeah, 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 on the first one? Like, what has changed that you're like, this is way better to do it this way? So this last time, the thing we experimented with, was we added unstructured time.

What happens at a Zapier retreat (48:45)

We had always planned every hour of every retreat to date. Where-- It's fascinating. I know. It's interesting that you didn't think about it that early since-- I know, right. It's probably biased as like being-- thinking-- we're going to remind the 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 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. So there was just the sense where, from the top-- from management perspective, we were over planning all the hours. And one of the things that that prevents is cross-team coordination or cross-team communication conversation. Or what if one person from the data team and one person from support and an engineer had this cool topic that they talked about it, maybe one of our unconference sessions, they wanted to go hack on an idea. There was no time for that to happen in the past format. And it was completely top-down planned. So we added these two afternoon sessions of unstructured time where we said 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. 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 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 the retreat. Just do what-- I'm going to go do normal work. So I 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 overemphasized in almost all my conversations with the team leading up to the retreat to take advantage of the time. And 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 a cool advantage. I think it shouldn't be surprising. When you're hiring a bunch of people who default action, self-driven, et cetera, and then you bring them all together, they're going to 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, how do you guys do design critiques? How does that work in this collaborative environment?

Remote design critiques (51:10)

Because it's so difficult to even do it in person. And so how do you-- and you guys have an interface that has to bridge hundreds and hundreds of apps together and hundreds and hundreds of different types of features together. And so it's so complex. And 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? I guess I'd be interested to ask, what assumption do you have that makes-- what previous 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, et cetera. 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. And I'm just wondering, is there things that you could do to compensate? Or is it-- 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 the nine box design exercises. What's on? Folder paper into nine boxes. And you have two minutes to sketch nine different ideas of a solution. And then you have everyone present their nine ideas. And then you do a remix, usually, for 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 force folks not to get too deep in the thinking, just to 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 0.7 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, and like, sit at another table right now, and draw another paper. And they'd hold it up. And they'd talk about it. And I had them take a picture and put it in the Slack channel. So there was 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 don't want to look bad. Or if I'm trying to sketch and figure something out, it feels uncomfortable to do so in front of a bunch of other people. So I can see how having everyone separated, it's like, oh, you're working your own kind of-- it feels a little bit more safer to be daring. Yeah. And there were instances where I remember still having to encourage folks, like, hey, show it even if you think it's bad. Because some of the things you think are weird ideas often end up leading to the right idea, even if they're initially weird. It'll just trigger a different way of thinking about a problem that hasn't been thought of before. So another process we have, in addition to doing kind of team exercises like this, one of our more go-to processes that has been working really well for us last year, was we were doing a Tuesday, Thursday, essentially design review across several product teams. So we would invite several product managers, several product designers. And the Tuesday, third, is a cadence, was how we built in that feedback we process, where it's like, OK, I want to show something to the team and get feedback on it, get critique. And then instead of only doing one a week, where you'd have to wait a whole other cycle, there's a forcing function to turn around and iterate and go deep on for-- 48 hours. --like a 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 in a Zoom call. Well, one of the things I like to ask people to do on Zoom calls, especially in design collaboration sessions, is don't mute yourself. Zapier's built up this interesting norms around, what is Zoom etiquette? How to win to unmute yourself, win to jump on video, all that kind of stuff. So I have to intentionally ask folks to break that habit and say, OK, for this, please don't give you a mute. So to encourage folks to just jump in. I want folks to feel comfortable not waiting to give their feedback, but just to generate a little bit more 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 asks around, how do you be innovative as a remote company? And there's some amount of randomness that 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 randomness in terms of people talking to each other, or what's being shared. I think they're kind of alluding to serendipitous chance encounters, right? Weird, like, water cooler conversation. Yeah. One of the things we do is a process that's called a pair buddies.

Serendipity and over optimizing for it (56:10)

We're actually three people in these. Now we've gotten big enough where we've a bot that randomly just picks people that are in a Slack channel and says, hey, two people? There are three folks now, here's 30 minutes to chat. And the idea is, no agenda, just 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 group over-optimized for serendipity. They're like, what about that chance moment? But to me, serendipity, some random thing happened, all of a sudden we have a great idea. That's 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, what is the right ratio? Because I think there is some-- I think back to our hackathons, where this is a totally individual driven thing. And we had great things that got built that no one would have top down plan to go build and surprised us, 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 a release. Where all of a sudden it's like, oh, this is my opportunity for this habit. Versus like, yeah, well, not forcing it. Just like, oh, let's have it all together. And then maybe something will bubble up. I mean, to me, 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. It's like, I have no idea what Kevin's done in the past two weeks. I know Kevin's done-- I've been on the podcast with me. Very secretive. Yeah. I know Kevin's like, crush an email. But what have you 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 people are working on it. 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, OK, you should do x, y, and z things and set yourself up for success to really get the most out of this?

Optimizing Remote Work For Success

Setting up a remote company for success (58:00)

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 is your 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 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 exposed about writing down and sharing all the work that you do and building it a habit in 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 that initial culture up where it's like, OK, we do want folks to be individually empowered to make decisions. We want to hire folks that have demonstrated this ability in the past. We want folks that are good at written communication that over-communicate even. 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. It is more important and it feels awkward at first to be just sharing a status update with an empty Slack channel or a Slack channel where you're not expecting a reply. 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 Up D 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 request or a response cycle from them, and especially across time zones, that's tough. So yeah, just setting up the right values around 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. I think it's a couple of years out of date from a process standpoint, but it gets the cultural values. 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 your-- like the book was written at a time where we had enough people that could somewhat reasonably consume all the context that was published there on a monthly basis or on a daily basis or weekly basis. That's not true anymore. Like we've had to be a lot more thoughtful and intentional about what are the-- is it a push-first-pull kind of mechanism? 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? Mm-hmm. And then what are-- like thought leaders and other people in this space that you guys follow for an inspiration that other people should definitely check out? Yeah, there's several folks that are bigger than us that have run organizations. Kind of a little bit of rare air 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 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 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 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 that 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, Crib. Thanks, Mike.