Bryan Helmig, сo-founded Zapier in late 2011 with good friends Mike and Wade, which was admitted to YCS12 batch. Zapier is a web automation app to build Zaps which can automate the most tedious parts of your day to day job. Bryan is working with a 100% remote development team since the very beginning of company’s growth. In his interview with YouTeam Co-founder and CPO Yurij Riphyak, Bryan shares his thoughts on working with remote engineers and best practices of managing a development team distributed all over the world.
Yurij: At your recent talk at Y Combinator, two-thirds of the entire time was devoted to remote team management questions. People were asking less about what Zapier does but more about this kind of experience. Our feeling is that people who are working with remote teams formed a kind of small community, almost like a minority, and I feel like we at YouTeam are also a part of it. What I found that most of YC companies are quite sceptical about managing a remote team. Can you remember how did you and your co-founders arrive at this decision to start hiring remote workers in the first place?
Bryan: Well, we didn’t decide from the very beginning that we’re gonna be a remote company. It’s kind of ‘just happened’. We were working remotely and using Slack, GitHub so all the work was done online anyways. We’d got to start there. We had to grow our team and we needed to hire people we trust.
We were in California, Mike (Co-founder & CPO of Zapier) had moved back to Missouri. The people we trusted were folks we went to school with and worked with previously and they worked in the same area as us. We had them in Chicago, we had other people in Missouri, and we wanted to hire them since we knew they were good. We were familiar with an option of a remote team software development. We thought that was a reasonable and really effective way to get awesome people to comprise one team. It wasn’t like a grand plan, it was more emergent based on pressures of what we wanted. It just happened.
Yurij: So it was like a low-hanging fruit for you, something that you could quickly approach and start using, right?
Bryan: Yes, I think so. That’s at least how I remember it. We certainly never sat down and said: “We’re building a remote company”. There was always just “We want to hire this awesome person and they don’t work here or live right by us”.
Yurij: Right, thanks. So why do you think most of the other startups are afraid of hiring remote engineers? What do you know at Zapier that they probably don’t?
Bryan: I think there’s probably two pieces. One — most people are used to going to the office, that’s how they’ve done all the work before. That’s a pretty classic way to work. If you paint for a living, you can’t paint remotely; you have to be at the canvas, you have to be at a certain location. There’s no other option for this type of work. In tech, however, not all people realize that’s not necessary anymore.
We at Zapier are working in a purely remote way. Everybody’s on the same level. Everything’s optimized around it and that’s great.
The other thing is about people that have more experience working in mixed (co-located) teams rather than purely remote. I think that’s the worst scenario if you’re building a remote and in person/co-located team together. Then you have to optimize all your processes for both teams which requires a lot of careful consideration even in little decisions, like how you communicate with staff, how you hold meetings, and how you do calls. You have to ask yourself: “Is it acceptable that you have a quick meeting or an ad hoc meeting in an office but don’t like people calling in?” I would say: “No, that’s not acceptable”, because you have to let people come in. You can go even further and say “Well, we may be co-located, but everybody has to call in to the meeting”, and then “Hey, you’re going to that room, I’m going to this room, let’s split up our Slack chat.” And you really split up. It’s weird, but both are the kinds of steps you will need to take to make that team to work on the same level. I think that’s a point of friction if you co-locate which startups might be afraid of.
It’s a momentum of how people have always worked in tech trying to distribute their workforces. They probably just had tested it in really bad settings. However, we at Zapier are doing it kind of this purely remote way. Everybody’s on the same level. Everything’s optimized around it and that’s great.
Yurij: It’s interesting because what you said is quite counterintuitive like normally you think “Ok, I have a core team, which has to be quick in their uptake, and then I can extend it with a remote team.” But in fact, most of our clients, for example, that set up remote team startups through YouTeam, do it at the very beginning of their growth. First, there are just two or three founders who decide for a remote team software development. I mean, it’s not like they convert to it at certain stages. Well, did you have to develop any external practices and special tools to meet these challenges of managing a distributed remote team?
We built our internal blog “Async” to synchronize everything across different time zones.You post, pull people in, get that context and keep moving. Slack is not suitable for that.
Bryan: We did adopt some tools. There’s a lot of stuff off-the-shelf people use if they work in co-located settings like Slack and GitHub. However, we also have built some custom internal tools only for Zapier employees like dashboards and utilities that help support folks with finding information. We have an internal blog called “Async”, named after the communication style “Async Business”, to synchronize everything across different time zones. It’s great for posting things and gathering contexts. It’s named and used in such a way that you get it in the context. You post, pull people in, get that context and keep moving. Slack is not suitable if you want to communicate in different time zones as people can’t talk to you while they’re sleeping, so we have substituted that with this internal tool.
Yurij: To put it on the other side, what did go wrong? What were the biggest problems you faced and was there something you wish you knew before setting up a remote team?
We hire people we’ve never met before. It’s comfortable and it works. It never seems weird to us.
Bryan: That’s a tricky question. This is the first company we really scaled, so we made just a lot of mistakes that are not really tied to a remote aspect. But one thing we had to double down on more and more is the style we communicate. We really overcommunicate things because you want to repeat the most important aspects in many different channels, and in many different ways. Anything that is worth saying is worth saying a dozen times. So we just overcommunicated some stuff not to miss it in these sorts of strain that’s going by really, really quickly. Being careful of where you post it and how many times you say it — that’s a conscious sort of decision. That’s not unique for a remote team communication but you don’t have to come over and tap someone like reminding them of how important something is. You can have a video call, but it doesn’t scale. Eventually, you cannot lock everyone in the room and have this kind of conversation either, so you will have to rely on these other media. That’s something that we have to power upon as well.
Hiring is another issue. It’s completely remote so we don’t have people come in for an in-person interview. We hire people, and we’ve never met them before. It’s really comfortable and it works well. It never seems weird to us. But when we talk to other people that have worked like traditional co-located jobs their entire life as soon as they realize you hire people you’ve never met, they’re like “Are you insane? That’s crazy! I can’t believe you trust someone you’ve never even sat down with.”
Yurij: Well, going a little bit further to the hiring process, what are the sources of candidates for you as a remote team lead that you look for and what are the most efficient, and then — what are the key things you look at when hiring? In general, how does this process look like? That’s very interesting.
Bryan: Our little greeting step, or the inbound step, is very typical. We’ll be looking through projects, we’ll be looking through LinkedIn and just find people who we think are interesting. We try to email them and try to learn a little bit about them. We don’t spam anyone. We generally find someone like “Wow, this person worked on this library, they worked on this language, they did this — that’s really impressive, and, therefore, I’ll email them and talk to them”.
Yurij: So you kind of screen LinkedIn profiles? That’s a website where you look for remote team members?
Bryan: Yes, LinkedIn. You know, I’ll find things on Hacker News, I’ll find things on GitHub, on Twitter, like really any place where people congregate. And it’s not that hard, we say — that person is great, he clearly takes some insight into the Python module systems, so let’s go see what that person has done. We find them this way, so it’s really kind of curiosity, that’s one aspect. At the same time, we’re also lucky to get a lot of inbound interest for our jobs. We have a large user base and they tend to be more techie, more knowledgeable around the industry, around APIs and integrations. And we really love it whenever candidates come to us and they already know what Zapier is and what it means to be.
Yurij: The brand works, the brand does the job.
Bryan: Yeah, it works with a tool like Zapier, because the tool really embodies the way we work as well. We’re careful about the job boards we post. We try using more specialized boards, those tend to be better for us. We find StackOverflow pretty solid, some of the Python-specific job boards are great, remote work job boards as well. We tend to avoid some of the really big ones since we’ve got lots of inbound remote team candidates.
Yurij: Like Toptal, for example? Did you use that?
Bryan: I’d say, like Monster. Just because of their volumes. We’re really trying to match up the person to the role — do they fit, do they extend the role, do they get Zapier, can they articulate what they’re interested in. Then we try to do a skills test, no matter what the role is. Some of the classic ones is a whiteboard challenge. You sit down, pair with them and give take-on tests to solve. Whenever you’re going through our support process, we give you some questions that users would be giving us. You’ll be surprised at how the amazing folks just shine. We find that’s really, really high signal. We do that for recruiters, we give them a dozen anonymized applications for a role, and we say “Tell us which ones we should talk to and which ones we shouldn’t.” So we get a clear signal and again really awesome people just absolutely destroy those tests.
Yurij: So the talent will show itself eventually.
Bryan: Absolutely. I mean, it’s like until you get an interview or you’re like “Wow, that’s amazing!”, “Is it really gonna work?” Then you finally find that person, and at the end of the interview you’re like “Well, I think that’s just awesome,” and that’s the feeling you want to go for, and that’s why these skill tests are so important. We do standard reference checks style stuff and then an offer call. So it’s that crazy and it’s short, but we’re optimized for these high signals. We want to get the signal, and our role pipeline is designed to get to the nugget of what is awesome and passionate.”
Yurij: Cool! Well, last question. We tech guys like to build stuff, so what is the last thing you thought you wish have built, like for yourself or in general, to help with either remote hiring or managing a remote team? Like something that is missing and you just didn’t have time to build it yourself.
Bryan: Well, I remember one complaint; it’s probably ATS — applicant tracking systems. There’s a lot out there but none of them really nails what we want. So we ended up building our own pieces of it. We wanted to anonymize as much as they can about the candidate coming in and provide a custom form for questions. We don’t want people to just drop the CV and shotgun approach our role. We want people to look at the role, understand it, and answer the questions. A lot of ATSs instantly apply and optimize the inbound roles but are kind of bulky, slow and have weird bugs. We’ve never found an ATS that was just a joy to use. So if I could wave a magic wand to fix this, I would wish to build a really great, simple applicant tracking system.
Yurij: Well, if I hear of anyone building that, I will definitely recommend them to talk to you. Right, Bryan, thank you very much for your time, it’s been pure gold from the very first minute to the last.
Originally published at youteam.io on April 27, 2018.