In today's episode, we talk with CTO and co-founder of Zapier, Bryan Helmig about the different challenges he faced when starting Zapier and the challenges he's facing today.
Every company has its own unique challenges. In today's episode, we talk with CTO and co-founder of Zapier, Bryan Helmig about the different challenges he faced when starting Zapier and the challenges he's facing today. Stay tuned for Part 2, coming out on Wednesday.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Every company has its own unique challenges. From special testing requirements based on whatever your product is, to the type of workers that you have, or maybe the type of distribution, remote or local or mixed office environment. These are just a few of the topics that we discuss with today's guest, Brian Helmig. Brian is the CTO and the co-founder of Zapier. If you haven't heard of Zapier, I encourage you to go and check out what Zapier does. I'm very excited to have Brian on the show because Brian faces a lot of really interesting technical challenges with his team. And we're going to talk about a lot of that on today's episode. My name is Jonathan Cottrell. You're listening to Developer Tea. This show exists. This show exists to help driven developers find clarity, perspective, and purpose in their careers. Before we kick things off today, we do not have a sponsor for the episode. So in lieu of visiting our sponsors to support the show, I encourage you to go to teabreakchallenge.com and sign up. This is a daily soft skills exercise. Sometimes it's literally just telling you to think about something throughout your day. Sometimes it's a five-minute literal, you know, on paper kind of exercise. Go and check it out. Tea Break Challenge. Tea Break Challenge.com. These challenges are going to make you a better developer and they're 100% free. That's teabreakchallenge.com. Okay, let's jump straight into the episode with Brian Helmig. Brian, welcome to the show. Thank you. I'm excited to be here. I'm excited to have you. For people who have been living under a rock and don't know what Zapier is, and make sure that I'm saying this right as well, Zapier. I'd love for you to give kind of a basic definition of that. And kind of your role as CTO at Zapier. Yeah, Zapier is the correct way to pronounce it. We always say Zapier makes you happier. So, you know, in a nutshell, Zapier is a way for usually small, medium businesses to automate their online world. It helps you connect different apps that may work together or may not work together. That, you know, a good example is you might have a business that's a little bit more advanced than you are. And you might have a spreadsheet and you want to trigger off of a row in that spreadsheet and maybe send it to Slack and then have someone, you know, Slack emoji it for some sort of next step. And then it goes back and drops into maybe another sheet or makes a change in your CRM. And you can kind of string together all these really, you know, different actions and steps and filters to build your own sort of integration. And it can kind of scale from just like really simple use cases. You know, I just want to, I'm a realtor and I want to, you know, collect my leads into this CRM or, you know, send a text message to these customers all the way up to we have people who've built, you know, 40, 50, 60 steps apps that are really crazy and incredible. So it kind of helps you just automate your online SaaS software. And it's something you can sign up. You can use a kind of the GUI workflow and build your own. You don't have to write code. Though you can. One of my favorite things is you can actually write a little Python in there or JavaScript in there, which lets you do lots of cool little things as well. But it really ranges from non-technical to technical to business owners to individuals to all that. So we just help you automate online stuff. So I have a fun story about Zapier, a very short story. When I was working in agency world, I actually used it to help this, help a company do an entire like online course. And they didn't really have. Yeah, they had a lot. There's so many use cases for this platform. And I'm sure that developers who are listening to this, many of you have used Zapier for something or another. And so you know that the first of all, the technical capabilities of the platform are pretty extensive. And it's essentially it's limited to, you know, what you do with it. But additionally, that there are certainly a lot of technical. Challenges that are associated with this kind of extensive platform. Yeah. And which means that, you know, you have to have a a strong team and you're facing a lot of, you know, a variety of challenges from UX to performance to. I'm sure that there are so many that I'm not going to even be able to think about. So I'm really excited to talk to you because that level of challenge. It feels like. Kind of like a developer playground in a lot of ways. But I'm also imagining that this can be pretty stressful at times. Yeah, it's funny. We I, you know, I do a lot of interviews because we're doing a lot of hiring. And one of the things I always come back to when people ask about like, what's, you know, what's something interesting or cool or also we're on the stressful side of what Zapier does. And because we talked to so many different APIs, we have fifteen hundred like official partners. And that's not to count all the like private APIs. People hooked up on a developer platform and stuff. We joke that we're like an edge case catching machine for the Internet. So literally anything that can go wrong with an API, we find out about it right away and we have to deal with it. And that usually means like some pretty smart logic around, you know, holding off tasks and not trying to run automations for users while the API is returning 503 or something. And then, you know, trickle those out, resume them or retry them. At the same time, you may find that they may not be bringing you the same evolution of evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution And now we've at least put in some of the systems that help us stay ahead of it and be proactive and even let users know like, hey, heads up, your CRM that you're using is currently having an issue, but don't worry, we're holding all the stuff and we'll release it as soon as we see it be healthy again. So it's made things a lot less stressful over the years. So we've gotten better at that. Yeah, I can only imagine. I mean, you've got these long list of integrations. You said 1,500 different partners and then beyond that, things that people have built, custom integrations. Of course, you have things like webhooks. And I can only imagine that it's easy or at least in the beginning, it was probably easy to view all of these services as reliable and they all have similar interfaces and they're all going to follow the rules. And I'm sure that that has been just exactly the opposite case. You have probably with 1,500 different partners. You have 1,500 times some in number of exceptions that you have to make for all of those different services. Yeah. And it's not just the 1,500 services, but all the unique ways that people will combine them together. Right. You might have, it's very combinatorial explosive the way that these services can interact and do all these interesting things. So, yeah, it's definitely not like. A trivial sort of undertaking and one that we didn't think about as much as we probably should have in the early days. But sometimes that's kind of the special part about like naivety, right? At the early times. Yeah. When you're starting these things, if you knew how hard it was going to be, you probably wouldn't start on it. But that's a great thing. Like after you just get a little bit better, a little bit better, and it's taken us years to get to the point where we feel really comfortable with the system we've set up in particular with. At the very least, you may have taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the plunge and taken the pl I have to do whatever. And that's like your entire service set, right? Or a large portion of it. So I can only imagine that you have a lot of interesting problems around testing. And I'd love to know, like, how did the team kind of interact in the early days around making decisions for that long run? You know, how do we test, for example, these external services? How did you organize that early team? Of course. But being able to just kind of dive in and be curious about stuff and poke at things and kind of learn a little bit about it is important. And you mentioned testing. And testing in particular is really challenging across those, for us, especially for so many services we integrate with, that, you know, mocking is something that gets very challenging to do because, A, it's just, I mean, it's just a ton of work to mock out all those inputs. Right. Right. Yeah.!!!!!!!!!! Right.! Right. Right. Right. Right. Right. search of all of our, you know, API calls, how many people are getting a 503. And if we see it's pretty much static, it's like, Hmm, okay, maybe it's something we're doing. But if we see a big jump, we can say, Hmm, looks like maybe an availability zone and Amazon is going a little upside down. So you can see that. It's kind of an interesting opportunity that you have there with that data, you can almost say, you know, you could use some kind of simple learning algorithm to say, Oh, yeah, it looks like this particular zone of Amazon is down, maybe even before they can kind of interesting. Yeah, it's it's not uncommon. We've definitely, we've definitely alerted partners to issues with their APIs. They didn't know about they didn't know about and that's, that's, it's not it's not unreasonable. If you're, you know, if you're a company that does a ton of volume on your API, and there's one edge of it that you didn't really spend as much time monitoring or adding, you know, triggers on for there's exception rates or whatever, it's easy to miss it. So often, we can kind of be that, that that kind of second guard of just, hey, heads up, something goofy is happening. Oh, yeah, we do that a lot. Yeah. I think kind of an abstract lesson to be learned for developers who are listening to this, they don't necessarily work on Zapier. And they're like, well, what, you know, how can I apply this to my work? I think an abstract lesson here is that there isn't one specific way to, for example, test, right? Right. You have to imagine that your testing is supporting the product and the use case, and not just following some arbitrary best practice, which would say, yeah, don't run your, for example, don't run your, your tests against the, the external service. Well, Zapier needs to do that, right? So the idea being that, you know, there's going to be exceptions, there's going to be changes, there's going to be fluidity in the way that your software is written and whatever practices you choose to use. You know, a lot of the time we can start from that, whatever established best practice is, and then venture away from it as we see needed. But we shouldn't arbitrarily or blindly judge our practices based on whether they are following some, some external rule, right? We should, we should instead design our practices around the fact that we're doing something that we're not doing. Around what we're trying to accomplish. Yeah. And I think that's, that's a really good point because it's so easy to get best practices mixed up with dogma. And it's, I think you're right. Your point of just start there, but be, feel free to change it. And that, that's a really good, healthy way to think about, not just like the technical side of things, but, you know, as we've, we're a remote team, some of the stuff that you do in a co-located, you know, company translates, especially on the management side, some of it gets a little bit harder and you actually have to work harder at. So kind of sticking to whatever that best practices as if it is dogma will always put you into some sort of a local maxima, which is never, it's never gonna, it's never going to like really push you further and further, though. It's a great place to start. You shouldn't, especially for management, you should not try some crazy new, new wave thing. You should just use kind of what works and then start from there and then tweak it for whatever might make sense for you. If you have a good reason or a good narrative, then it probably makes sense. Yeah. I'd love to hover over this, this discussion on, on remote for a few minutes. I'd love for you to share maybe some of your experiences around, you know, how, how do remote teams, first of all, how can they get to the point where they're like, oh, I'm not sure I can do this. I'm not sure I can do this. I'm not sure I can do this. I'm not sure I can do this. I'm not sure I can do this. wrong. And I realize that's a very big question. So feel free to compress it down to a few, you know, kind of highlights of, of things that you, you see that could go horribly wrong. And then also, you know, for people like me, I'm, I'm a remote employee and I'd love to know, what have you seen in terms of different types of behaviors that remote employees employ or don't employ that kind of correlate with their success? Yeah, it's great. So the first part, what can go wrong in remote? I think that there's actually a really healthy overlap to what just can go wrong with any company, even in co-located. So you're not, it's not a completely different beast. There's different things that are accented for sure. I think having a mixed environment can be more challenging. It doesn't mean that it won't work. It just means it's more challenging. For example, if you have, if you have a manager who's co-located and, you know, three or four engineers are also co-located with that manager and then three or four are remote and you default to running those meetings in a conference room, and then you expect the remote folks to dial in. That's really, it's an uneven feeling because you have some people who are together and then some people who are dialing in. Some of the companies that have been successful doing that, put pretty strict rules around how that interaction works. For example, they might say everyone has to dial into the meeting, no matter what, unless, you know, unless everybody that needs to be on the meeting is there, you have to dial in and maybe even you have to dial in regardless, even if everyone's in the same room. And that kind of, you don't want to create an in-group or an out-group that can be a big anti-pattern. I remember in the early days, with Wade, Mike and myself, we would be sitting next to each other and just typing. I think it was on probably HipChat back then, but it was on HipChat. And we would just like be chatting with each other about what we're trying to work on rather than talking to each other. So even in the early days when there wasn't a big necessary, I mean, I could have just talked to Wade or talked to Mike, but we were still doing HipChat and doing that in the kind of digital manner. And that just kind of set the roots of our, culture that everything should happen online. And that's really important. Of course we do do calls as well. But in those cases, we often record them. And then anybody who maybe missed them or was curious, they can check out the meeting notes or they can watch the video. And it's not uncommon to see people watching these videos at like 2x speed. Right. And everybody sounds like a chipmunk talking real fast. It's a really efficient way to gather that context. And that does lean into a little bit of the thing that I think is really important. And that's really important. And that's really important. And that's really important. And that's really important. And that's really important. that, you know, if you want to be really successful inside of Zapier as a remote environment, being great at communicating something is really important. Like I'll find myself revising a comment, like on GitHub, like I'm making a comment on a PR and I'll like rewrite it four times. You know what I mean? Just to try to make sure that I'm emphasizing the right thing. Not that I'm, not necessarily that I'm being like super kind or empathetic, but that's a part of it certainly. But that, I'm being clear and what my intention is here. Like there's the right emphasis on the things that are important or, you know, I call out the things that I'm not interested in that you might be misled into thinking I'm really, really care about, or it's just that clarity and communication. If you find yourself like rewriting a comment two or three times before you post it, just to make sure it says the right thing. Those are good sort of behaviors to have in a remote environment because you don't get body language. You don't get tone over Slack or over GitHub or JIRA or wherever the content is going, right? It's just text. So it's easy to misinterpret that. So that thing, classic stuff, this is stuff that's probably applicable in any job being like super inquisitive, being helpful. We often encourage people to, especially new folks, imagine you'll get your chance to pay it, you know, pay it forward. So if you're looking for a job that's going to be helpful for you, ask all the questions you need to be successful. Everyone in Zapier is super kind and empathetic. We'll help you out in a pinch and then you'll get your chance to help the next person that's brought on. So be super, super inquisitive. Ask lots of questions. Yeah. And then pay it forward when the next person comes on. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Brian for joining me. If you don't want to miss out on the second part of this interview, go ahead and subscribe. And whatever podcasting app you're using to listen to this right now. Thank you so much for listening. And until next time, enjoy your tea.