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

Hey guys, welcome to the podcast! How's it going? Great! Cool. Kevin, welcome back! For people who don't know you, what do you do?

I'm a partner at Y Combinator. I founded a company called Wufoo back in 2006. I was in the second batch at YC. That company, um, 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?

Wow, what are the odds? All right, Mike, so what do you do?

Yeah, I'm like, um, I am a co-founder of Zapier and we're chief product officer. 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. I have 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 use multiple tools for your job and you're trying to like manually copy and paste data from one tool to the other all day as part of a task you do, you can use Zapier to automate that and have it done automatically in the background.

Mmm, so an example would be like, if you are, 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 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 were doing YC and we just like talked for a couple hours. It was really interesting conversation. Basically, I told you, it was like this is what we did at Wufoo, and I was like, you should basically just do kind of a lot of the same things.

And yeah, yeah, like think about remote work that you're gonna be doing this for a really long time. Integrations was kind of like, you know, patching a bunch of things together to a form builder was like a feature at Wufoo, but to me, I saw like what they were doing was like turning that into an actual business.

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 want to do something with it usually. It's once someone submits a form, I want to go put it in my CRM or qualify that lead or put them in an email with somewhere.

It's actually interesting that I think the life cycle of people getting their business online is like you start off with like, I need like a presence. It's like how do I get my stuff out there? And so you use like website builders. My default to become really big. We didn't realize this when we started, but we've 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?

So form building, contact forms, etc., like all of that became really relevant and surveys. And then the next thing is like, oh, and 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 stages of every company. It's like, oh, this is what I need.

Yeah, and they have just giant markets. I remember early days at Wufoo, people have talked to us about like so what's your TAM? What's like your total addressable market?

And we literally were just like, I'm not doing that because it'd be like everyone that ever has a website, everyone who needs to collect data. Like, do you want me to calculate that? I have no idea.

Yeah, and sometimes think those exercises, while useful, are sometimes like a little misleading. It's misleading when your market is so ridiculously large.

Yeah, when you're thinking about like consumer adoption, you don't ask Facebook what's your TAM, right?

Right. And for us, when we think about this opportunity, certainly when we got started, you know, our ambitions were hey, can we build like a cool piece of software and support ourselves?

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

There's just like an explosion in SaaS software in the industry that is like the barrier to entry to creating software is so low, and distributing software is so low that you get these niche tools.

And more and more folks are using these niche tools and bringing 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 going to be incentivized to go build thousands of integrations for everyone else.

Yeah, but at this point you want it.

Yeah, I mean at this point surely you do have to be thinking more specifically about personas and like growing out individual markets, right?

So how do you approach it now that you have, you know, so many users?

Yeah, honestly to date it still is 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. It wasn't 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 better decisions I think we made in the earliest. We built the first 50 or 60 apps on Zapier ourselves right away to like bootstrap that engine. And when we launched in 2012, I remember we had live chat—I think a lark on the site at the time—we launched in TechCrunch and had three days straight where all the chat messages we 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 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 it was almost out of necessity. We didn'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 heard us jumpstart that scene?

I think that's like everyone, especially I remember back then, too—persona—the platform. You gotta 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, 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 gets big enough where you want to be a platform. I think I'd always heard the heuristic of like once you get big enough where you could carve off 1% of your revenue and that could be its own standalone business, like you've kind of reached a critical mass that you could actually build a platform that has legs and can sustain itself.

For us in the early days, obviously, we didn't have. I think the thing that we've leaned on really heavily was the value proposition to some of our partners building on Zapier.

It wasn't just—but most of the time these platforms play one of the big mechanics you see people building on platforms is for distribution. Like, I might go want to be in the Salesforce AppExchange 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 and they integrated with Zapier, they got access to 50, 60 at the time integrations that were maintained and scaled and were adding more to it, and they got a lot for free.

Oh, 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 future 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 there was value for them beyond, you know, just user acquisition that incentivized in the early days to build into Zapier.

Didn't end up being that, like a lot of people on the frontlines, like recommending you or then support people because for us, like in our company, customer support was where all these feature requests would come in.

And so did end up being—I mean I would imagine a lot of them were like, hey, here's the stock guy, here's how I satisfy you. Those are very common. We get listed a lot in like help docs, health documentation. Sales is also another avenue where we get mentioned a lot where we can Zapier basically help someone close a deal with the customer that they're trying to upsell or converting to a paid plan.

Mmm, was that like the start of like your dominance in like SEO stuff? It's like, oh, we get people sort of linking to us.

Um, that was a little— that was actually earlier. So we built our app directory before we built the product, before we launched in TechCrunch.

The whole story was pre that we had been burnt 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 landing pages, and we used that to try and gauge what people wanted us to build.

We were building these manually. We didn't—we had a very big opportunity cost on our time in the beginning.

How many apps did you guys integrate and do before you actually had people integrating and doing the work?

It's like 50 or 60.

Yeah, they get 50 or 60?

Yeah, but we had landing 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 and gauge the market demand for this thing before you go invest the time to build it.

But on launch you had 50, I think, so...

Yeah. Because that was a Startup Weekend project initially?

Yeah! Yeah, that's where I met Wade, actually. I met 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.

Yeah, like, I mean, not even worth talking about this point. As soon as I heard Brian pitch the idea for what was called API mixer at the time, my eyes lit up, and I was like, that's what I'm working on this weekend.

So during that weekend, we prototyped out actually what Zapier is. The core mechanics of like mapping data between apps all came out of that weekend.

And I think we had—we built PayPal and Highrise and Twitter, I think, were the first three apps.

How did you pick those?

It was more we sat down and said what would be a cool use case that we could demonstrate this prototype with.

Huh. So during the final demo during Startup Weekend, if I went, the mechanics of the weekend are 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 like tweet something live and then have people pay us something on PayPal, and then you could actually see Zap—the prototype of Zapier run and pull that data into Highrise.

The idea was like, oh, we could aggregate, you know, if someone pays you in PayPal and they're tweeting at you, you'd like to know that in your CRM so that you could pay special attention when you're contacting them.

So it kind of came out of a single use case, and we worked backwards from that.

And so at what point do you end up doing Y Combinator?

Yeah, we applied actually twice. Twice.

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 Ds from Missouri is a hackathon project I hacked my project.

So totally useful exercise, I think, but it definitely lit a fire under us, I think, as far as like what was wonderful about filling out the clutter, showing 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 rejection, we at that point we had enough hints of success who were like, we're gonna keep working on this.

And it gave us actually more motivation to keep burning 40 hours, nights, and weekends a week for the next few 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 or even using the product—it was invite-only at that point.

We were having folks pay—we had our first ten people pay us 100 bucks—like validate it—and we turned down the price to I think five bucks.

And we had a few hundred people who paid us an amount of money, so there was 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 Y Combinator? Did you even have employees?

No, just the three of us. And we hadn't—Zapier had been, I mentioned, we've been doing nights and weekends for that four or five months in early 2012. They still had like jobs.

Yeah, Brian and Wade had full-time jobs. I was still full-time student, actually a grad student. I get the—one starving or dropping out is to star 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 super early or we'd 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, 1 a.m. every night working on Zapier basically.

So it's kind of two full-time jobs for the first few months.

Yeah, and so demo day happens, and then where do you go? What do you do?

Yeah, so after—so obviously YC...one of the things is moving out to California. So that was kind of—it was really, I think, one of the big values of YC for us.

We had a forcing function to go commit. Olin! 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...

Um, you ever thought like this is an interesting hobby?

Yeah, I think, you know, thinking back to the time, you think about our ambitions, right? It was like, hey, we wanted to get this to a point where we could spur ourselves, be our own bosses, control our schedules, and 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 and building it that way by two plans.

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 full-time on it.

After demo day, we actually, leading up to demo day, I remember one of the problems early during that summer was all three of us would wake up in the morning, and we were all doing customer support.

We have a shared Gmail inbox, 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 and wouldn't answer the same email, 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 work 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 know we couldn't convince him to move to the Bay Area.

Like, we—oh, but we didn't want to—and it's not back to like, hey, we were kind of doing Zapier remotely before Startup Weekend or before YC.

You like: what if we could give that a try?

And this coincided with the exact time after YC where my 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 with 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 for part of the time.

So like, let's just give it a go! So it was very much an experiment in 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, yeah, well, let's just see what happens?

Um, maybe more inspiration than plan, I'd say. You look at folks like Basecamp at the time, Wufoo at the time, like we had seen at least small—real companies that had been successful at building fully distributed remote workforces.

So I think there was more inspiration than anything. A lot of times for a lot of people, they feel like the company isn't real until like there's an office. There's like a lot of ego there.

And so I think that's the kind of thing that's amazing about remote teams that actually get really big is 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 a—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 scale and organization. It certainly—even it's funny 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 would 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, you know, 100 people with like 50 million ARR. Like, yeah, we're a real company.

But yeah, it's still this one—you know, one of the reasons why I like some of the PR things would be actually useful because we can send those to friends and family and say, hey, look at this!

This isn't just like a side show; like this is a real—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—we believe that it was not. Oh, why is it that you never felt like you needed to have an office?

Looks just like peer pressure or a startup, nor exactly. Like why did you not subdue that? Because that's often what I see a lot of people do is like I'm spending this money because I think this is what it looks like to normalize me because this is actually very—especially at that time, it was very radical to be like I'm not going to have an office.

Yeah, 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—we were just—I mean, in our a night couple of first years between, you know, 2012 and 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 had 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 where they 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 Brian and Wade around like, hey, this is working.

Like this doesn't—it was probably, I think, right after our first company retreat where we went up to Washington and had like seven of us. Then where it felt like, yeah, this isn't just like an experiment and like an easy way to get better recruiting.

Like this is actually a better way to like run the company for us.

It definitely started off with a cost. We're like we can't afford an office, but later on as things were working, we were just like, yeah, if you have this frugal mentality, we're like there's nothing about the office and wanting to have a commute that made any extra sense.

And we also had relocated from California to Florida, so it wasn't like, oh, yeah, our office in Florida was going to be the driving.

Yeah, I think for anyone, and so, you know, 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—we still have the best exit to investment ratio in terms of like how much percentage of the company that YC owned or any of my angel investors if you like the output.

And I think we're still in like the top 10 biggest exits for YC still—still because of how much equity that was owned because we didn't raise any money here.

Is what we raised was—and hard about $18,000; YC was $18,000 then. And we raised money from two Angels, PB and PG, and it was $50,000.

Age and I was it.

I was just thinking, you know, I think logistics and practicality was one reason why promote was like we believed in it so much.

The other reason, I think, is actually a little bit more tied to Brian, Wade, and I, how we'd like to work in the early days. Like I think it goes back to this that nights and weekends.

Like part of the reason inhibition we've of wanting to like start Zapier 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's a company value or a number of values default to 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 out, and if I'm gonna 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?

Like how do you get the sense of it's really good for a lot 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 those 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 extrovert 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.

It's a peers or a distributed remote company, like you—you in the past, it's very easy to lean on your work as that like a social connection—rare healthy mind.

And if you—if you're gonna 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 come to company retreats. You'll see their faces and names all day and 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 is going to be appropriate for a remote work?

Past experience of the remote is good is a pretty good signal because they know what they're getting into.

Wheat now, with that said, we've had quite a few folks who haven't had past remote experience, and they've been very successful, but there is like a learning curve attached to it.

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

Do they have past experiences where they did not take a consensus-driven approach and instead said, hey, this is the right thing to do, and I believe that this is the right thing to do, and went and caused some kind of action in their previous company or organization?

Because they thought it was the right.

But that sounds like a call; it is 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 today 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 then 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 that we've had to invest really early on in how do we—what's our decision-making framework?

How do we communicate as an organization? What are our processes? You have to get really explicit about your processes in order to be successful and in order for folks to have the information that they need to be able to default to action and be able to know how to operate in this organization.

So you mentioned this. I heard this in another podcast about like overlapping time zones and making sure you don't unblock or block and unblock people.

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

There's an interesting underlying, I guess, assumption here or observation. All 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 the 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 of the 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 alright, you know, in a co-located company, in an office, you don't probably have a lot of explicit direction or like process laid out as far as when you're spending deep time versus when you're collaborating and coordinating with your coworkers.

Because I can just tap you on the shoulder, Kevin, and like ask you what you think of the work I just did, whereas in a remote team, we just have to be so much more explicit about what are the processes individual people, individual teams follow when they want to communicate.

What were some mistakes you guys made in the early days? You said you have to figure this out early.

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 keep—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 a person with you, I—the default communication mode is I'm gonna get your attention, and then I'm going to have a conversation with you, and I have full—I have the full range of bandwidth, right?

I can use body language; I can use my—I can stand up; I can use tone.

It's like full bandwidth. Between a split, I've got 100% distracted you.

Like I have your full attention.

Yeah, now, so it's like we're taking two people's time up with us in a remote organization. The default is 100% the opposite in the spectrum, which is people don't communicate at all.

Like if yours—you're using a Slack channel, and that's like your main office, which is how we operate today. If two folks aren't a team together, the default is kind of like you don't say anything.

It's a day—it's like just a blinking text cursor, right?

And we have to be way 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—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 it's like write these rules down.

There are 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 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 across 10 people.

Just get on the 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 professed 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.

Yeah, and so for us, we changed the rule to be like if you're discussing something for like 15 minutes, at that 15-minute mark, just you got to stop and go onto whatever the next thing you have to do.

Like to get to, like when you say it’s default action.

And when we said it, like all discussions that have been paused—we had 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 that once they slept on it they really just have a discussion they view as like—they just magically figure something out or how to compromise or realize something wasn't a big deal.

And so usually, by, to help me get to Friday, not many things were ever brought up—only the most important things surface.

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—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 to solve this problem or try to solve it?

Yeah, I mean it's a good question that 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 the 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 ten minutes on your calendar this afternoon.

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

And the thing—like some of the social, I guess, norms of the organization—of how we like address that is, you know, one is in Slack, if you do—if you tag somebody in a message, like "at" tagging them specifically, it's kind of the social norm to be—to acknowledge that within 24 hours.

So we have some expectations like—then the reason we had set 24 hours is because we have folks all across the world—the Sun never sets on Zapier, I like to say.

So yeah, we have some of these social expectations where there is gonna be some asynchronous 'ti in how the organization works and operates.

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

Yeah, if you're the type of person who, as soon as it gets blocked, I'm just gonna sit here until I'm told what to do next, you're not gonna be successful at Zapier or I'd argue most remote companies.

So how big is Zapier right now? Like how many employees?

200.

Which is 200? And then your primary responsibility is all the design work that's done in 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 how big is the product and design team?

That's a very—we've got about seven or eight product managers, a similar number of product designers, and then engineering—that's about 50 folks attached to that.

So from my experience, I know like how much collaboration is necessary, like associate 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 Wufoo, it was like I was the only designer or it never grew to beyond 10 people, so you had to communicate with yourself.

Exactly! So we never ran into the problem.

I'm really curious. What did you—what's done differently for your design team and product team, yeah, to make that sort of work?

Yeah, I think the 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 newer now well 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 have—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 won't do that remote work-wise. That's the thing that's difficult, especially when you're trying to respect everyone's bandwidth.

Yeah, 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 who was talking about before—we have to scale 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.

If the companies can have weird definitions of OKR, it's like how do you guys define OKRs?

Like an objective that that team is trying to accomplish. Like hey, we want to, you know, 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 and a Jing manager and a product designer would have shared ownership over, and that for it gives like 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 in the customer first.

I think one of the things I've noticed that happens in scaling Zapier is there's a tendency for engineering at PM design to kind of specialize in their own areas, and like they have their own unique things they think about all the time, right?

An engineer might be all day thinking about the user experience, and engineering is thinking all day about estimates and delivery and refactoring in code quality.

PM is thinking about business impact, and if you don't give them some kind of—if there isn't some kind of shared system for how they should value the things that are prioritizing, you get a lot of us versus them mentality that kind of creeps into the organization where it's like, whoa, I want the designer to do this, or why can't the engineer do this?

So you give teams OKRs versus individuals?

Yes. Gotcha!

Yeah, this is something we're new we're starting to do, but so far it's been pretty fruitful in building that like alignment across teams.

And so how is the team checking in on each other? Is it like a stand-up type thing?

Yeah, everything goes a little different, actually.

So there's a lot of expen of the things about Zapier that is cool to see is a lot of teams experiment with some of the process. You give a lot of autonomy to different teams to try a bunch of stuff.

Yes, we do.

OKRs are kind of our framework for how we pull—oh, make that not chaotic, if that makes sense.

Sorry. 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?

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?

OKRs, or if it's design, what's the like ownership between where's that handoff?

Like what's the scope of ownership between two teams? So it's like—there'd be another layer; it might be like if we use a Breeze 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 observable 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 about individual autonomy to these like EPD trios.

So how the teams created mostly on in 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 will create a lane at the like leadership level of the organization. Like, hey, 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 or it's mostly their long-running teams.

I'll say that we've had folks— which I wouldn't say we've etched; our earliest product team is only two-years and a half, two years old.

So well, and some of those folks have shifted.

We've had staff folks reach out 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 experienced engineer, and we've just brought in like more of a staff or associate-level engineer we want to like it, but work together.

What's the timeframe for like these OKRs? Like are they of 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 if like, all right, where are we? What are we working towards over the course of the 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 new OKR? Like how does that workflow actually go down?

Yeah, this is still new to the organizations. So I feel like I need to give the coffee epithet.

Yeah, 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 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? For a pure case, we're trying to build a piece of productivity software that anyone can use. How do we get Zapier adopted by, you know, 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 for the work that's happening, fifty percent of it to be kind of top-down driven, and I think fifty percent of it being bottom-up.

Because in reality, the Zapier team leadership is never going to have perfect insight into all the pieces of work that happen across the organization.

And I don't think that's what something like OKR 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, 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 like with different ideas in their head about what is important to have.

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 OKR itself to help you guys.

We are, yes. You use OKR dog for you. 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 I actually built—this one in the early days—it's a tool called Async. It's 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 in to in the morning.

This is where work gets talked about. We've got about 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 we very early on, we set the expectation that Slack is not a tool you're expected to keep up with at 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 turned that off because we wanted to give folks like—great, the social comfort to be able to leave channels without feeling awkward, just because it feels like pressure it's like they're behind on my homework.

There's some social pressure to muting those channels rather than leaving them.

Yes, yeah! Like we actually have a course working on for how to like be effective using Slack to Zapier. But this is an early day, 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 like more thoughtful tease 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 our final reports getting shown to the organization?

And how does that get shown to—how do the right people get notified that like I have something I need you to read and make a decision or to think about?

So those were 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 was basically—it’s kind of like a Twitter feed.

Yeah, Automatic was using this internally, and that's how they run their—the old version of it.

Yeah, we worked—we used it as a pure for a 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. I've why I like investing in tools is you can tweak and change them to match the like level of company you're at, essentially.

Imagine company gets bigger; you're gonna run into these new bottlenecks, and you can start layering in and customizing the tool instead of having to go like throw the tool 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 office system.

It's funny enough, the reason why I wanted to rebuild it was—so I built a version of internally called Async, which is just an internal blog.

And this was kind of the tool that—what one of the cadences we have at Zapier is every week we ask everyone write up for what they worked on.

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 work crew loved it. Like in the early days, you got 20 people, 30 people, you get to read everybody's Friday updates.

You can't know everything that's—every decision that's made, everything people are learning, all the work that's happening.

Well, you get to 70 or 80, 100 blog posts, and that starts taking a full day just to read like all the information.

So let's—you start to run into the same problems even Slack does where it's information overload.

Yeah, but because we own the tool, we can tweak it and tailor it to how we like or 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 that, like, just the information they need.

And so does email have a specific role or is it kind of a catch-all?

Free—we don't send any internal email, really! That's like my fantasy!

Full-stop!

Then we use email, email's used in a few sways in Zapier. It's—we of course we do email support, so we just help Scout and all of our emails, basically.

If there's any internal to external communication. So like when we're talking to our partners or with customers, obviously that happens over email.

Yeah, but internally, there's Slack and Async.

Yeah, those are our tools. We have one—we also use Quip for a long-term, like long-form documentation. It is a wiki; it's a collaborative wiki—kind of Google Docs mixed with a 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 Zapier was like how much time we spent development-wise on internal tools.

Actually, it was like almost like 30 to 40% of our like development time was like building stuff for ourselves.

It's why we were able to grow and only be at like a 10-person company office or so long.

And so like what is that ratio for you guys? And do you have special internal tools teams?

Like you know, Facebook is kind of famous for.

We did last year, we had to invest in internal sodium, which was helping scale some of the Async software that we were talking about.

I, for better or worse, have been kind of the internal tools head over the last six months. I was building mid to this OKRs.

We actually built our own OKR software into Async.

Gotcha! And one of the beautiful—beautiful parts of it is like when you're updating your OKRs, it's got annotations that tie into the poster 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.

And but right now it's kind of just organic, like keys make their own stuff.

Like it does tend to be a little more organic, I'll say. In the early days, I think we invested more time and internal tools.

And it's something I'd love to spend more time on, actually.

Like I was just thinking, just listening to a singer, like I remember this for us, like a lot of our internal tools ended up being like YC companies down the line of the future.

As I—and I’m hearing a sea-can, and it was 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 on a support team and the product design team that where we'll build features into Zapier 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 gonna add this little bit of functionality to the product that doesn't exist.

Maybe it's the ability actually meted out in the product.

Yeah, it's actually the biggest criticism for lots of corporate hackathons is like people spend all weekend getting really excited and they never make it to the life day.

Yeah, we tried pretty hard to make like pick our packet on 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 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 the remote team?

Yeah, we do the—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.

We don't, like, discount that.

Yeah, you get to build a lot of empathy, you get to build relationships with folks, and it allows you to kind of be assume best intent the rest of the earth, right?

When you're in Slack, and you're on that working on that tense project and someone we use, 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 on my head like I know that is; I understand who that is.

Like I'm not gonna jump off and like assume that, yeah, 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 like 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 in tense moments.

So there's a lot of value for building in-person relationships still.

So we do two company retreats a year where we find the whole company into, usually, some quarters order hotel or place around the US.

You know, George! How long are those retreats?

So for a week. And then in the Friday, what do you guys do during that time? Is it just hanging out or I mentioned structure?

Yeah, we've tried a few formats. We've mentioned 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, which I had 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 them.

Does that mean you do a lot?

Like how often? I mean, any time we're doing a company-wide thing, there's probably gonna be a survey sent out about like it to get feedback so we can approve it for next time.

Okay, email—uh, it is tied into Slack, actually. I do, but there is an email though, too.

I wouldn't—that. Yeah, I still do keep my Gmail tab open.

But either there is like a Slack time. But we have a company retreat; there's a survey we send out to the company servers a year.

So we do a lot of that.

What's the best thing you guys do at the retreat that you didn't do in the first ones? 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.

We had always planned every hour of every retreat to date.

Where hasn't it? I know this—you didn't think about it earlier.

Right! It's probably a bias that’s like or 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? What—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 the management perspective, like we’re over-planning all the hours.

And one of the things that that prevents is cross-team coordination or cross-team communication, or what if like one person from the data team and one person from support and one engineer like had this cool topic that they talked about?

It may be one of our unconference sessions they wanted to go hack on an idea.

Like there was no time for that to happen in the past format, and it should because it was completely tapped-out planned.

So we added these two afternoon sessions of unstructured time where we set the expectation that, hey, it's still a workday, but figure out how to best utilize this time with your team and your peers.

How do you know it worked well?

Mostly through feedback.

At this point, I was anxious about going in like it was so—we designed—we added this process in because of feedback we'd gone before.

I want time, like people have specifically asked for time to do this, so we added it in. I was still anxious that like 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, right?

Just do what? Like I'm gonna go do your normal work and I work on my roadmap or work on support tickets in isolation.

What we want is to take advantage of the fact we're here!

So I overemphasized in almost all my conversations with the team leading up to the tree to like take advantage of the time.

And when I walked around, and just observed the different groups of people 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—I think it should be surprising when you're hiring a bunch of people who are like default action, self-driven, etc., and then you bring them all together.

Like think the right thing!

Yeah, it certainly worked out well! And I will continue to do something like that at future retreats.

I think we talked about—I'm curious, like, how do you guys do design critiques? Like how does that work in this collaborative art?

Is it so difficult, you know, 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 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—you know, 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, it's hard to like point circle, re-sketch, etc. Those are some things that like 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, etc. But it seems slower and more inefficient.

I'm just wondering like is there things that you could do to compensate, or as I say, 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. One time, I 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 actually 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 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, or a little while ago— where I asked was like maybe the point 70 or 80 people, everyone bring paper, bring sharpie, and I gave the problem statement up front.

And everyone's like, just on a Zoom call with their video, like sitting on the table and draw on the paper, and they'd hold it up, and they talk about it.

And I had them take a picture and post in the Slack channel, so there was like a 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 when everyone's in a room. There's a pressure of like, no, 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 separate, it's like, oh, you're working in your own kind of—a safe space, it feels a little bit more safer to be daring.

Yeah, and there's like—there were instances where I remember still having to like encourage folks like hey, show it even if you think it's like bad because that's some of some of the things you think are weird ideas often end up leading to the right idea even if they're initially like weird will just trigger like a different way of thinking about a problem that hasn't been thought of before.

But we’ve—so another process we have in addition to like doing kind of team exercises like this, one of our more go-to processes that we've been working really well for us the last year is 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-Thursday cadence was how we built in that feedback—we 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 have to wait a whole nother cycle, there's a forcing function to turnaround and iterate and go deep on 48 hours to then turn around and show it back on Thursday.

That's the end? Show it again!

So it's—it’s kind of like a bit of a mix where you still get that deep work in between the two review check-ins, but it’s still in a Zoom call.

Well, one of the things I like to ask people to do in Zoom calls, especially in design collaboration sessions, is like don't mute yourself!

Zapier's built up this interesting norm around like how—what is Zoom etiquette, right?

Like how did—when done with yourself, when to like jump on video—all that kind of stuff.

So we kind of—I have to like intentionally ask folks to like break that habit and say okay for this, please don't give you a mute so to encourage folks to 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—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, right? You want some low level of like—it’s randomness in terms of people talking to each other or what's being shared.

Yeah, I think they're kind of alluding to like serendipitous chance encounters, right? Weird like, you know, water cooler conversation.

Yeah, one of the things we do is a process that’s called the pair buddies.

We're actually three people in these now. I'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, or three folks now should like—here's thirty minutes to chat, okay?

The idea is like you don't know agenda just like a thirty minute call over to share whatever you're working on and talk to you about some of those ideas.

I actually think this idea is interesting!

I actually think a lot of companies or organizations a group over optimize for serendipity.

Like they're like what about that chance phone?

But to me, like serendipity.

Like we're like some random thing happening all of a sudden have a great idea.

Like that's like hitting the lotto, and to me, optimizing for the lotto is very weird.

99% of companies like we have a whole list of things 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—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 liked 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 is like oh this is my opportunity, right?

Versus like yeah, well, not forcing it—just like oh, let's like have it all together and then maybe something will sort of bubble up.

I mean to me it's 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 I have no idea what Kevin's done the past two weeks, right?

Like I know Kevin's don't been on the pot; Kevin's like crashed an email.

But what have you actually been doing?

We—we don't have that problem; we have the other problem, which is like, I have too much—there are too many opportunities to learn whether the people are working on things—it's like how do I curate down to like, alright, who are the people I need to know about what's working on so that I am doing my job effectively?

So kind of wrapping up, I'm curious about like if I were to be starting out a remote company, what's the framework you would offer to say like, okay, you should do X, Y, and Z things and set yourself up for success to really get the most out of this?

I think it is one of the reasons why it is so hard to add remote onto an existing company is because remote, well, when you see folks to 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 your—you know, co-founders or whatever.

And you have the chance to like set up the culture in a way that encourages things that are going to work in a remote organization.

So again, thinking through things like defaulting action and encouraging empowering autonomy and how are we going to make decisions and thinking through some of those things in the early days.

Being exposed 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 it can get lost—those who like the cultural habits and norms, they're a lot harder to change in the future because you need everybody doing them.

I think there's a structural advantage for folks that are a hundred percent 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 be happy in my own job.

So you can take advantage on the early days by like—it's a lot easier to set that initial culture up where it's like, okay, we do want folks to be individually empowered to make decisions.

We want to hire folks that have like demonstrated this ability in the past.

We want folks that are good at written communication that like over-communicate!

Even like one of the things I often tell new engineers that are joining Zapier and product designers is I have to encourage our communication a lot again, coming back to the default.

No one talks!

Like it is more important, and it feels awkward at first to like be just sharing a status update with like an empty Slack channel or a Slack channel where you're not expecting a reply.

Like that takes 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'm should be doing or how to solve a problem in a certain way that otherwise would get blocked on—but you know, request-response cycle from them.

And especially across time zones—that stuff!

So yeah, be 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?

I know we did, yeah! It's a book on running a remote company. It's a couple—I think it's a couple of years out of date from a process standpoint, but it gets like the cultural—what's the biggest—right?

Yeah, 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.

And you're like the book was written at a time where we did—we had enough people that could somewhat reasonably consume all the context that was published there on a monthly basis or on like 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 poem kind of mechanism?

What's the deep—is it the kind of algorithm that powers the default feed view that shows content that everybody should be reading in the organization on a weekly basis?

And then water—like thought leaders and other people in this space that you guys follow for, and like inspiration that other people should definitely check out?

Yeah, there's several folks that are bigger than us that have run robot organizations 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; InVision 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—I'm all those organizations have slightly different value mechanism than we do, so like that's what we're going to figure out as we scale is all right, how does that—how do we apply that size of the organization to where we're at?

But yeah, that's the biggest takeaway I would say is like remote is possible!

There are 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, Craig!

Thanks, really!