Every company has its own unique challenges. In today's episode, we continue the conversation 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. Part 1 released on Monday.
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/.
Sentry tells you about errors in your code before your customers have a chance to encounter them.
Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.
Transcript (Generated by OpenAI Whisper)
It's easy to believe that problems that you face as developer will eventually just go away. That eventually you'll totally figure out how to communicate perfectly and that your team will find a way to gel just right and that you'll finally get over these hurdles and be able to focus on just the code. Unfortunately, this is very unlikely to be true and a lot of your career will be about interpersonal relationships. It's going to be about the human dynamics and the work that you do. This is some of what we're talking about in this second part of my interview with Brian Helmig. Brian is the CTO and co-founder of Zapier. If you missed out on the first part, make sure you go back and listen before you get into this second part. My name is Jonathan Cutrell and you're listening to Developer Tea. This show exists to help driven developers find clarity, perspective, and purpose in their careers. We're going to jump straight into the second part of my interview with Brian Helmig. I think one of the challenges that makes environments face is that some people get a totally different context than others, right? And to your point, it's not just about imbalance or feeling left out, although that's certainly a part of it. But it's also the sense that if I text my wife, texting my wife that I'm on my way home, I can be very tert. Second, hey, I'm on my way home. Scene a bit. If I was in a remote relationship with my wife, let's say for example, that I had a long distance relationship, and that's the amount of communication that I had with her. Right. Yep, on my way home. That's vastly different, right? It's vastly different because the expectation of that connection and that interpersonal, you know, the moment that you have there is very different. It's a memory in one scenario, and it's holistic in the other, right? You have this supplementary conversation that's sideline to your physical relationship, which is kind of the primary line of relationship. And then for your remote employees, you have this holistic. This is all they see of you. Everything that they know about you is represented in an avatars Slack or in your video meetings or whatever. So putting that extra effort, especially, and this is the key, especially if you are in that physical location, then you're more prone to this because you're going to be having to kind of switch context between the people who you do see who are physically co-located with you and the people you don't. And so there's some context shifting there that's important to understand. And I think a lot of companies have learned how to manage this. A lot of companies have yet to face it. And this is a truly difficult thing to solve. There's no easy solution, unfortunately. No, I don't think so. And I love the idea of thinking of your communications as a portion of the totality. Your entire bandwidth is purely remote textural. That is a completely different piece than if it's supplementary. I like kind of thinking of it that way. I think it's difficult for companies to switch in from one to the other. Unless you really invest, and I would say even from top down, I mean from us, like us three founders, we were doing this remote from the very beginning. We've gone all in and we're 100% remote, right? So there's no doubt that we're like all in. So everybody's all in as a result. And I think that really, really helps. So I'm not going to like going back to having that mix of iron. It sounds like you were also in a mix of iron. I don't think that it's fatal, but it just the discipline, right? That it requires is so much higher because it's just not your everyday. You have to remember not to have that long conversation in the hallway, right? And to bring it online. That's hard to do. That's really difficult. That's changing a lot of behavior. It's difficult. And I think it's worthwhile to mention that there's some legitimate like psychological factors that make this important. It's not just, you know, it's not just a new thing that people have a need for emotionally supportive workplace, right? It's not new. Our psychology, when we don't have something available to us, we fill in with bad. This is a very strange thing that we do and it's difficult to reverse. But when we have silence, for example, the natural tendency for our brain is not to think optimistically about the silence. It's to think negatively about the silence. Keep on saying science. It's to think negatively about the silence because that allows us to predict and then protect against some kind of threat, right? That's the evolutionary response. And unfortunately, most of the time, that silence is because that person is whatever, playing ping pong, they're at lunch. It doesn't really matter. They aren't just thinking about the silence like you are. Yeah, that's really interesting. It kind of hardens back to, if you have that kind of person that was relentlessly optimistic in a dangerous environment, it was did not bode well on your survival, right? Right, we're certainly in a different, certainly a different era for just people and what they have to really worry about. Obviously, I'm very fortunate. I don't have to worry about food or being warm or loved ones. That's very fortunate. But yet, I still have that exact same brain that I would have had 10,000, 15,000 years ago, right? Yeah, would freak out at the rustle of a leaf, you know what I mean? So it is funny, isn't it? But you see it all the time, and I fall prey to it just like anyone. You hear someone say, yep, and they misspelled, yep, you know, it's like with two peas or something, and you're like, oh, I just wrote something really thoughtful out. And that's all they had to say. And it's really easy to kind of build that up yourself, you know, but yeah, and maybe their keyboard malfunctioned. You don't know. Totally possible. Totally possible. So that is something. And you know, for me, I feel like I'm definitely getting better at this, at least in work environment by asking people what they mean or to clarify. And sometimes it's like, sorry, I'm on call, right? You know, and they have to be like Kurt because they want to give that person full attention. So I was like, okay, that makes sense. And now it dispells that. So it takes practice as well, certainly. And in remote, it's again, you don't get the, you don't get to see someone like hustling off to the next meeting, right? All you see is, yep, with two peas. Right, right, exactly. Yeah. All you see, there's this phrase that comes from one of my favorite books. When the phrase is, what you see is all there is. And this is a book about psychology and what we're able to understand. And we are just really bad at filling the blanks when there are blanks. Brian, I'd like to ask you kind of a totally different question, shift gears a bit. I'd like to ask you about your experience. And you know, a time in your career where you felt like things were uncertain. You didn't really know what was next, what to do. Maybe you didn't even know if you wanted to do this at all. I'd love to hear a story that kind of takes us to that moment of uncertainty in your career. You know, I think it starts, it's kind of a double edge sword because I look back, it's funny. You look back on these things with kind of rose tinted glasses and nostalgic. So you kind of, you miss them at the same time. You're like, man, that was quite stressful. As we were getting started as Abier, of course, we've been very fortunate. So we've been very lucky. I'll, I'll preface it by that. But in the early days, we certainly were a lot smaller and the future was a lot more uncertain. And if I even, you know, wind the clock all the way back to when we were just getting started, you know, I think Wade quit his job to go full time on Zapier. Before we had enough money to sustain ourselves. So we were, we were certainly like it made sense. We're going to do, we did the risk and the calculus and Wade was cool with it. We were cool with it. And we kind of took the leap, but it all worked out in the end, but at the time, it seemed like a very large leap, you know? So those sorts of things, you know, I look back again with like rose tinted glasses. Those were also really fun times. Like we were doing, you felt like you were been on an adventure. It was really exciting. But also at the same time, it's a heavy kind of decision where, you know, he was, he was married, he had his life and we were all trying to like throw in on this. It's a big thing. So making that kind of decision, I think, just comes to mind as, you know, a very poignant turning point, at least for Zapier of like, we're not just, we're not going to stop at, you know, weekends and nights and stuff, which we were doing a lot of. But we're going to try to take it to the next level, right? We're going to go, we're going to try to go full time. We're going to try to peel all of us off full time. And that was a plan. But that first step, you know, was a big one. Yeah, it was there a moment there where you thought, okay, you know, worst case scenario, I go and get a, you know, a capital R regular job. Yeah, well, you know, this is where I think we were kind of, we were kind of smart about it. We didn't all quit, right? So we tried to be realistic about it where we would try to peel off. And we always knew that if we had to, we could go, yeah, go back to the, like a real job. So while of course it's like a big kind of decision at the same time, like when, you know, certainly for us, when we were young, you know, mid 20s, early 20s, we, you can kind of take those risks, especially before you have kids, like before you have a big family, like it's a lot harder, but you still have to be like realistic about it. It doesn't mean that they're without, you know, certainly without risk with involved in it. But if there's a time to do it, that ended up being a pretty good time to do it. I like that the overreaching theme of that story is how closely you relied on that team. You know, it's very little of what you're saying starts with, you know, here I was, right? It's very, you know, we were smart about this. And so you've distributed this risk a little bit and you've distributed the decision making process as well. And that's, that seems to be a little bit unique amongst stories that I've heard from developers who found themselves in that kind of difficult place or a decision turning point like you did. Yeah. And maybe we like to think that it's our, we're originally from Missouri. So we have those Midwestern sort of values where we're pretty easy going and we don't get very flustered. So our relationship has kind of been us founders and by that, I mean, like Wade, Mike and myself. We've been very fortunate that our relationship's been really strong through that. We've been good friends. When it comes to these sorts of decisions, we just kind of sit back and think about it and lay out a couple of the options and then decide on the one we think is the best and just kind of move forward. And it's never got a lot of drama to it. It just seems very kind of straightforward. And we've always found that to be the arena in which those sorts of decisions certainly happen. So, you know, both on a personal level and professional level, it's been a pretty good process. And that was one of the early big ones. Like, are we really going for this? Like, oh, we are, okay. Here's a logical way to kind of go about it. Does that make sense to everybody? And then it's like, all right, let's do it. And it seemed with not a lot of fanfare. We had decided to do that. And then you look back on it and you're like, oh, wow, that was, I feel like most people are maybe not. But most people would spend a little more time thinking about that. But it just seemed right and it seemed, you know, we were all on the same page. And if we're all in agreement, like, let's do it. So, yeah. It kind of works out. At least, you know, certainly maybe a bit of survival bias going on as well. But definitely, definitely worked out for us. Do you know what's worse than finding a bug in your production environment? Not finding it for a long time. And then hearing about it from a customer. You shouldn't treat your customers as your QA team. Not only are you not paying them for this, but it's also a terrible user experience to wait on your customers to tell you what's wrong with your application. Now, if we had a perfect world, then we could solve all these problems ahead of time. We could write every possible user case test that we can. And we would know every single way that a user would interact with our app. Unfortunately, not only this is not possible, but even if it were possible, it would cost way too much to implement that much testing. The best companies know that finding errors in your code base is not going to happen with just one strategy. You need multiple strategies to attack this problem. So yes, you should have tests, but you should also be relying on things like Century. Century tells you about errors in your code before your customers have a chance to encounter them. But only do you see the details about the error, but you'll also see how many users have been impacted by the bug already, the stack trace, the commit, and even the engineer who wrote the line of code that is currently busted. There's plenty more information that you get, but I want you to go and try it out for yourself. Head over to century.io to get started today. That's century.io. Thanks so much to Century for sponsoring today's episode of Developer Tea. We've talked about psychology a few times. I think there's an interesting psychology here of the safety and numbers. If everybody agrees that this is OK, then it must be. So that can jump around or a short circuit that fear of uncertainty that you face when you're alone, you say, OK, I'm not crazy. None of these people are crazy. Therefore, probably I'm not crazy. You all point to the other person and be like, yeah, he said it's fine. So it's fine. But then it turns out that everybody's pointing and then you all make that decision together. Yeah, certainly. That's certainly how a lot of what we do even today is, Abier, as a team. We're constantly trying to figure out what are the next steps we want to take in the product. The next things we want to do for users, as long as you stay close to it and something that we do that I really adore is we have all hand support. So everybody as Abier does support, which at the end of the day, you're serving customers, right? So if everybody spends time with customers and sees the pain they go through and the joy of when they actually do get their things solved and they see what cool stuff Abier can do, it kind of brings everyone, it gets everyone on the same page. No matter what little project you're working on or what little, you can kind of see how it fits into the tapestry of what we're trying to do. And it's always has the customers as the backdrop because every couple of weeks you're going to set aside a day or a half day depending on your rotation to talk to customers all day. And you're going to try to solve the problems through the lens of what we do and sometimes don't do or could do better. It's really humbling in that case and it gets everyone on the same page. So whenever you do make those decisions together, you have that context. It's a shared context, right? That's real powerful. Yeah, I think that's a really interesting idea. And one that Zappier has a unique position where the average customer, I'm sure you have multiple customer kind of archetypes, but it allows you that ability to say, okay, a developer can help with another developer pretty well. So if it turns out that a developer is asking for support, man, it'd be really awesome if I can talk to another developer, right? Yeah, it is really awesome. And one of our values is Zappier is build the robot, right? Which is a very, it's a very Zappier value as well. That's our product. We help people build automations and build the robot. So for us, instead of being a robot, you want to build a robot, you're talking food, you're including your own product all day long, you're building on the same platform that your customers do. So again, you have the shared context, not with the team, but also with the customers. So again, all of that is like not to be dismissed. That's a powerful thing. I don't know if I've worked on products that didn't necessarily, like they were cool products and meat, but I wasn't the user in making that connection and getting that context. This is hard. So when things get tricky, you have to rely on something else to guide you. Whereas at least with a product like Zappier, especially if you're a user yourself, it can click a lot easier. You know what the customer wants because you yourself are one in a way. Yeah, that's such an excellent thing. And if people are listening to this and you want a little bit of heuristic advice here, find a way to become a customer of your own product or find a way to use your own product as your customer would. There's little that you can do to improve your context than actually feeling what a customer feels. And this is true in any industry, not just software development, not startup, not just in agencies, but pretty much everywhere. 100% agree. Brian, I'd love to ask you a couple of final questions here. I know we're kind of running out of time. I like to ask these questions to everybody who comes on the show. And we'll start with the first one. What do you wish more people would ask you about? You know, something that comes in mind for me is as we've grown the company, we've had the chance to bring on more and more talented folks and especially recently more on the executive side, which has really helped kind of grow out or I shouldn't say grow, but it kind of define what my role is going forward. And I think that's a part of a conversation that isn't often out there that much. For me, it was that VP of engineering compared to, let's say, the CTO, right? How do those two hats live in harmony, right? Two sides live in harmony going forward. And that's something that certainly I'm going through a lot now and it's going amazing, by the way. But it's awesome. It's also a piece that just not a lot of stuff is written about. And there's so many different archetypes for what a CTO can be or what a VP, a V could be and what those like, that relationship looks like, that, you know, it's everyone I've talked to so far as I like search around was like, yeah, this was just a process of self-discovery and like figuring out the business needs. There is no like roadmap to a lot of this stuff. So it's funny that, you know, the further you get along with this, the more similar the terrain feels. It's like you're kind of relearning stuff over and over again. But you know, that's something that comes in mind for me that it's least certainly recent is that that journey kind of never ends. And, you know, even when you get to, you know, the fortunate position of where we are, that's still kind of a, still kind of a similar journey, still a similar part. And that's that constant refining and understanding the human side of things and then how humans turn into companies. Yeah, yeah. Excellent. So the other question I love to ask on the show is if you had just 30 seconds of advice to give to developers, no matter what their background or experience level, what would you tell them? I would say that a lot of hard skills when it comes to, you know, just raw coding, writing code and thinking through problems, it comes down to what we talked a lot about here that these are at the end of the day, there are people problems. There's always people on the other side of whatever you're doing. And if you can find a way to get your dopamine hits from the, maybe not necessarily one, you know, an exclusion of the other, but how the two combine, there's, there's so much more fertile like ground there. And you know, mind you, I can really geek out to the hardcore technical side of stuff. So that really touches a spot deep in my brain, but the, where it really turns like into magic is how it interacts with people and how teams work and how the customers are rolled into that. And at the end of the day, all technology has that human component and really seeking that out has been pretty special. So I would, I would say something to that don't, don't discount that aspect of it. The hardcore technical stuff is super fun, but that aspect of it will get you really, really far because at the end of the day, people make the world go around. Yeah, excellent advice. I think, you know, if we can always remember that every problem is a people problem that's a quote from Gerald Weinberg who died last year. Jerry was a, he was an American computer scientist and wrote quite a few books. Many of you have probably encountered his books without even realizing it was him, but Jerry was, he, he had the same idea that people are really kind of the fundamental reality. And that as we build systems, as we encounter technology, we get the dopamine heads, like you said, from solving really technical, interesting problems. At the end of the day, all of this comes back to those relationships and the people that are using those things. So if we can always stay kind of centered around that, then not only is it rewarding, but it's actually the only thing. And if we can remind ourselves that when we're solving problems, we'll grow as engineers, but we'll also just grow as people. Brian, thank you so much for joining me on the show. I appreciate your time tonight and thank you for having patients with me. As we go a little bit over time, thank you so much again for coming on to Developer Tea. Thanks, Jonathan. I had a lot of fun. I really appreciate it. Thanks so much for listening to today's episode of Developer Tea. A huge thank you to today's sponsor, Century. You can find errors in your code base before it affects your customer base at over to century.io to get started today. Today's episode of Developer Tea and every episode of Developer Teacomes to you as a part of the spec network. If you haven't heard of spec, then I encourage you greatly encourage you to go and check it out. Spec.fm. There are other shows for you as a driven developer to level up in your career. For example, recently React podcast became a part of the spec network. If you guys remember, we had Michael Chan as a guest on the show. He's at Chanastic on Twitter and React podcast is now a part of the spec network. Go and check it out, spec.fm. You can find and play every episode of Developer Tea and plenty more, including an excellent search. You can search all across the entire network for different episodes covering similar topics, for example. Once again, specs out of them. Thank you so much for listening to today's episode and until next time, enjoy your tea.