In today's episode, we're chatting once again with Matt Klein. This is part two of my interview. If you missed out on the first part, that's a better introduction than we can give in the beginning of this episode. Go back and listen to that part first. Matt Klein is an engineer at Lyft, and he is one of the primary contributors to the open source project Envoy. My name is Jonathan Cottrell, and you're listening to Developer Tea. I created the show to help driven developers find clarity, perspective, and purpose in their careers. Matt is talking to us about how to stay an engineer. You don't have to jump tracks and become a manager just to grow in your career as an engineer. Once again, you're going to want to listen to part one before you begin this episode. Let's get straight into the interview with Matt Klein. So I'm going to shift gears a little bit here because there's questions that plenty of people who look at your career or follow you, they may have these questions for themselves when they are 10 years down the road. Why aren't you a manager? What stopped you from doing the normal track where you are a junior engineer and you get your feet wet, you learn how to do stuff, and then you graduate and you get promoted and you get the golden watch, and now you are officially capital M manager. Why isn't that the route that you've chosen, first of all? And then secondly, what exactly have you chosen instead? Yeah. So I think when I look at myself and I look at what I actually enjoy doing, I enjoy being an engineer. I really like building things. And I think that as you become more and more senior in your career or one's career, the line gets blurred, right? Between management and technical leadership. And there's quite a bit of overlap. But I think the way that I would personally phrase it is that, or at least the way that I look at it, is that there's an element of just general leadership principles. And this is like having the capability to sway people to follow a particular task. And I think that there's a big difference, though, between generally leading people and then managing people. And I think the difference from a pure management perspective comes down to, I think a people manager's first priority is obviously growing and caring for all of their people that ultimately work for them, right? So that's going to be figuring out what they actually want out of their careers, looking at the high performers and making sure that they're doing well, looking at the low performers and figuring out how they make them high performers or if they need to be managed out, for example. And those are super important things. I mean, you know, there's like, if you look at, you know, larger companies where, you know, you end up having these tiers of management, you're going to have a lot of people that are going to be management. These are obviously super important skills. I mean, you need people to be caring about people's careers and doing performance reviews and all that type of stuff. And it's not that I don't think that that's important. It's just, it's not what inspires me on a day-to-day basis. I'm much more inspired by solving big technical problems. I just, I love nothing more than to take on a giant challenge, particularly something that is said to be, quote, unquote, impossible, right? Like this is not impossible to do in this period of time, or it's not impossible, or sorry, it's not possible to do, you know, just at all. And I, I love, you know, I, I love taking, taking on those big challenges from a technical perspective and solving them end to end, meaning I love building a plan. I love actually doing technical writing. I love convincing people that the plan is something that's actually, attainable. And then I love doing the actual engineering. And that might mean doing it myself to begin with, or it might mean working with the team to actually do it. But, you know, those are the things that ultimately make me super excited. So I think as I progressed in my career, you know, sure, there's, there's always been opportunities where maybe I could have switched over to, you know, over to people management. But to me, for better or worse, our industry, especially larger companies, tends to make a lot of progress. And I think that's, I think, people choose between do they want to focus on people management, or do they want to focus on technical. And I've just, I've never been willing to leave my, my technical aspirations. I just enjoy it too much. And, and, you know, I think that I can have large impact that way. So I think at a super high level, that's why I have never become a manager. So what do you say to the people who are skeptical that they will kind of stall out, at some point, you know, there's, there's a ceiling for, for the engineers, but there's a higher ceiling for manager type work? How do you how do you respond to those kinds of, those kinds of, I guess you would almost call them accusations, right? Yeah, I, you know, this is a, this is a super, super nuanced topic. It's a super tough topic. I think what I would say is that, look, I mean, it's, it's important to realize that as people grow in their career, I mean, these, these things tend to be pyramids, right? I mean, it's people, they're, they're get, there tend to be fewer and fewer opportunities as people climb that ladder, right? And that's, that's similar for being an IC, or sorry, you know, if you're, if you're not being a manager, or if you're being a manager, you know, and I think that there's, you know, there's different skill sets that are obviously required for climbing that ladder in both, you know, in the, in the, in the, in the, in the, in the cases, and some of them overlap, right? Like the, the higher that one goes, there's obviously politics, there's technical skill, there's people management skills, there's, you know, there's all of these things. I guess, I guess my response would be is that, you know, climbing the ladder is hard, is hard period, right? You know, it's not, it's not like one can eject out of being an engineer, and they're guaranteed to become a vice president at some large, large major company, right? That's obviously not the case. You know, people that become executives at, at these companies, they have a particular set of skills that have let them rise to that level. You know, and similarly, people that manage to, you know, spend a 20 or 25 or 30 year career and manage to become a distinguished engineer or a technical fellow at a large prestigious company. You know, those are people that, have done probably fairly incredible things. Not, not always in all cases, there's always exceptions. But so I, I guess my response is that climbing, climbing the ladder is hard period, you know, there are going to be people that are going to, you know, reach their career limits, whether they are, whether they're engineers, or they're managers. And that doesn't mean, right, that they can't have completely fantastic careers and earn great livings and have fun and, and provide for their families, right. But, you know, not, not everyone is going to make it to these high levels. So I think that, you know, as people grow in their career, I think that, you know, that there's a lot of thinking that goes into how career motivated are people, you know, how high do they want to grow? Or sorry, how high do they want to climb that ladder? And, you know, I think that depending on that, depending, on how seriously people take that ladder climbing, or if they want their growth to be organic, you know, I do think that some people are better suited to potentially either becoming a people manager or staying a technical contributor. I think what you're alluding to, though, is that, you know, at lots of companies, and this is a pervasive industry problem, I think people feel that they have to become managers in order to, to, to gain that, to, gain that larger influence. Is that, is that what you're alluding to? Yeah, influence. And of course, you know, a lot of people are going to be concerned about, oh, is my compensation going to grow? Am I going to be, you know, is this going to be as respected of a job? Am I going to have as much security as an engineer? Maybe I'm more replaceable if I'm not leading a group of people? Sure. Yeah. So, all right. So I think that, you know, with, with the first part said, which is that climbing the ladder is hard, period. I, I do agree that we have what I would say is a pervasive industry problem, which is that I think that we don't default to empowering individual engineers to rise to higher levels that makes them feel that they have the impact that would justify either the increase in salary or, um, the, or the increase in scope. And I think a lot of engineers feel that in order to have that scope to have a seat at the table, if you will, uh, to make decisions that they have to have that, that they have to switch over to people management. Um, and you know, uh, you know, probably we're, we're getting into territory in which I can get into trouble. Um, but I think that, you know, I think that at many companies, there is some, that there is some truth to that. Uh, and I think it's unfortunate because I think we wind up in situations where a couple of things happen. I think we have some engineers become people managers that are not really well, well suited to doing that. And that has its own major, major set of problems. Um, we have people move away from engineering who are very good at it and can provide mentorship and can, can, you know, teach that, uh, you know, teach that next generation of junior engineers, uh, and they tend to move into management and might lose some of their technical skills. So, uh, you know, I, I do think that there's some, that there's some truth to it. I think I've seen this at various companies that I've worked. Um, I have just personally made a conscious decision that I am, I am not going to do that. Uh, and, and I think that's based on a couple of different factors. Um, one of them is just that I, I enjoy, uh, I enjoy doing engineering. I don't really want to be a people manager. I really like building things. It's not that you don't build things as a, as, as a people manager, but if you're being a, in my opinion, if you're being a good people manager, your focus is, is has to be different. Your focus is, is growing. That team is nurturing. That team is making sure that the team is operating at a very high level performance. It's not, it's not actually building the thing. Yeah. And I think the second thing for myself, and this is probably, you know, part of your line of questioning is that, um, I have the right personality and I think the right skillset to stay a individual contributor and navigate some of, some of the politics that lead people to actually saying, ah, you know, this is, this is not for me. I'm going to become a manager. Um, I, I think I, I've been able to navigate that fairly well. Uh, and I've been able to grow my career, um, in a way that I'm excited about, but, you know, it has taken a lot of, a lot of active management for sure. Yeah. I think that this is a question that a lot of people face because they don't see the immediate road and you're right. I do think it is an industry issue and it's one that companies have to make an active, uh, uh, kind of commitment, um, usually to, to fight because it is the kind of the common, I guess, picture of leadership is that as you climb, up, you become, you know, you, you literally climb that, that pyramid. So, you know, you, you should have fewer and fewer peers at your level as, as you climb up in your career. And that's, uh, you know, that's mostly based on the concept that, you know, you are essentially training people to do, uh, it's kind of like the, uh, the old model of, of like a blacksmith, right? You're training other blacksmiths to do the blacksmithing work. And once you're good enough to, to train, then of course you should be training so that you, you know, as you cycle out of your job, those people can take your job. And that model is very different now. Um, at least it can be very different with the type of work that we do as engineers. Um, but unfortunately we still have that kind of mental model from the old hierarchy, uh, of, of managers being almost literally like a, maybe not physically, literally above, uh, but in terms of hierarchy management being the only way to climb. Yeah. And this is a, it's a, it's a, it's a super, super tough thing. And, you know, I, I think that in the, uh, Twitter thread that, you know, that I wrote about this and, you know, that I think you saw, you know, the, the, the biggest piece of career advice that I typically give people is, is really this, and it's very simple. Is that I, I think that a lot of people, when they, you know, when they enter their first job and they talk to their manager and they, and they figure out what they actually want to work on. I think a lot of people, honestly, they put, they put a lot of faith into their company and into their immediate manager around, you know, this person is going to care for me. They're going to grow my career. They're going to help facilitate getting me to be a senior engineer or a super senior engineer. And there's, obviously truth to that. I mean, that is what managers are supposed to be doing. But, you know, the piece of advice that I give people typically is that, you know, no one drives your career other than you. And I think that's the most critical, that's the most critical thing. And I, I think that, you know, it sounds so obvious, but I've learned from experience and mentoring and talking to people that it's not, it's not super obvious to people. And I think just, that's what I would tell everyone is that, don't, you know, don't assume, you know, that your manager has your best interests in mind. They, hopefully they do, but, but they might not. Like, don't, don't assume that they're just going to intuit, you know, what type of work you actually want to do or, or what skills you actually want to grow in. So, you know, I, I really, I really tell people to advocate relentlessly for themselves, you know, in terms of figuring out what, what do they want to work on? What skills do they actually want to acquire? And, you know, in my career, and this is something where, you know, if you get a manager on your show, you know, they're going to, they're going to disagree with, with what I'm, what I'm about to say, which is that I have found in my own career that it has been, you know, just substantially easier to, you know, move jobs every, every few years. I'm not, I'm not suggesting moving jobs every six or 12 months, but I have found, you know, that after, you know, after a few years, three or four years or somewhere between two and four years at a job that I have, you know, I have extracted what I think I can grow from, from that job. I've extracted the skills that I can acquire. And then from that point, you know, it's time to find, find, find something new. And I think that's a big part of how I've landed where I am now is that I've been willing to, I've been very proactive. I've been willing to go after the types of opportunities that I think will help me grow. And, I think that ultimately that's one of the big differences is that I think when you are, when you stay a individual contributor, I think that it's almost, it's almost similar to being a, you know, to like, to, to being a consultant in a sense, like you, you drive your career, like you advertise for yourself, you find your opportunities. Whereas I think to your point, I think when you, you know, when you enter that, when you enter that management chain there may be a natural progression of, you know, manage this team. And then, you know, maybe when the company grows, you can manage two teams and then someone leaves and you can manage three teams. You know, there's a little bit more of a natural progression. Whereas I was, I think from a, from a single engineer perspective, there is no natural progression. It has to be much more self self-directed. Yeah, absolutely. I think, I think there's some, you know, a lot of people who are listening to this right now, they actually, they may not even know what they want out of that. And it takes a lot of kind of introspection and, and time. It may actually take experience, experiencing the thing that you didn't know that you enjoyed to, to decide. Well, it's so, so, you know, there's, there's that there's also, you know, so there's, there's like technical things, you know, do I, do I like doing that? This particular area or, or that thing for sure. But, you know, there's also, we, we grow as people, right? I mean, when I, when I think about myself as a, as a young, like early 20 something and, you know, what my personality was like back then, I, I almost cringe and, you know, I'm not, I'm not, I'm not perfect. Of course. And it's like, I'm obviously not, not perfect now by any means far, far, far off. But, but, but, but, but, but, but, but, but, but, but, but, but, but, but, but, but my, my point is, is that in our career, we grow not only technically, but, but we grow as people too. Right. And we, we, we learn how to better interact with people, how to navigate political situations. And like, these are skills that we learn also. So that's, that's what I was saying before is that there, there is a lot of overlap, you know, in terms of you know, if, if one wants to become a senior IC versus a senior manager, there's going to be a lot of overlap in terms of dealing with politics and personal interactions and, and just generally, you know, figuring out how to, how to navigate this volatile situation. But, you know, I, I think that it, it, it is possible for people to have a great career as an individual contributor engineer. But I, I think it, I think it does take some more proactive, some more proactive efforts. Today's episode is sponsored by Discover.Bot. Discover.Bot was created by Amazon Registry Services as a community for bot enthusiasts of all degrees. If you are just tangentially interested in bots and you just want to hear some of the conversations around, you know, what kinds of innovations are happening, Discover.Bot is made for you, but it's also made for someone who has an extensive library or a series of bots that are already out in production. This is a place to discuss best practices and, to figure out what frameworks are best to add to your existing projects. And the truth is this discussion needs to be moved forward. And that's what Discover.Bot is doing. We have a lot of discussion already available on best practices for building APIs or UIs, but we haven't had a, an authoritative source to talk about what it means to create effective bots until Discover.Bot. Go and check it out. Discover.Bot slash developer T to get started today. Discover.Bot slash developer T. Now, let's imagine that we're talking to people who have decided that they want to go ahead and just commit and, or at least for now they're, they're committed to, to remaining an IC and, and they're, they're ready to kind of establish good habits for the long run and, and avoid some of the mistakes that maybe you've learned about. What, what kind of mistakes have you learned from these mistakes? What kind of advice, and you did some of this in that Twitter thread, what kind of advice would you give to people who are embarking on that journey as a lifelong individual contributor? So, you know, the first piece of advice is the one that I already gave, which is that it's very important, you know, if someone is going to maintain their IC status, that they have a really firm sense of self in terms of what they're looking for, where they want to be, what types of companies they want to work for, possibly what types of problems they actually want to work on. So, you know, I think just having that sense of self and not assuming that anything's going to work for them is going to be a really important piece of advice. I think that's critical. I think the next piece of advice, which I talked about in that thread, is that, you know, as people become more senior in their careers, you know, I phrased it as becoming a breadth IC or a depth IC. And, you know, a breadth IC is something I define as someone that may, you know, just be an expert in a particular business area. They have a huge amount of contacts. They can. They can design technical solutions that span an entire business. So, you know, a breadth IC at a company like Lyft, where I work, you know, they may just have an intimate knowledge of ride sharing and just be able to develop incredible technologies that span that entire business area. You know, a depth IC would be someone that is, you know, very specific in a particular technology. And, you know, that might be computer networking like myself or, you know, web front ends or like something like that. And I think it's possible to use both strategies to actually become a long-term senior IC. I think, you know, the difference, I think, between the breadth and the depth approach, and this is for every, you know, person to kind of think about, is that the breadth approach tends to require spending more time, I think, at a single company to become an expert in that business. Right. So it might require. You know, working at a company like Lyft for many years, you know, to understand all of the ins and outs of ride sharing so that you can become a very senior IC who develops technologies for, you know, for that space. Whereas from a depth perspective, you know, if one is an expert in computer networking or operating systems or web development or something like that, you probably have more flexibility in terms of where you can actually go. So, you know, for me, for my own personal career. I have found, you know, being a depth IC to be a little more advantageous, just in the sense that it has allowed me to take my skills between companies. So when I've been in a place for three or four years and either because of politics or, you know, I've learned what that company has and it's time to move on, it's been a little easier for me to take my skills and then pivot that on to another company that, you know, that needs those skills. But may be applied to a particular business domain. So, you know, if I had to advise people, you know, I would say, I think that the depth approach ultimately is, you know, is probably a little bit easier from a career building perspective, but breath can totally work, too. You know, I think the other major piece of advice, which I would touch on, which I didn't actually really talk about in that thread, is that, you know, when youension your career, you may find yourself bringing your evolution behind you and bringing evolution behind you. actually really talk about in that thread is that, you know, you will, you will hear this phrase, which is, uh, you know, the Jack of all trades is a master of none. Right. And, and I think it's an interesting phrase because I think when, when one is earlier in their career, right, I actually advise people to go off and to work on all kinds of different things, right? Because you don't, you don't know, like, you don't know what's going to inspire you a particular technology or a particular business area or, or a particular type of computing. So I would, I would work on lots of different things. I do think that people tend to ultimately gravitate, you know, to particular areas just because it's, it's what they like, whether they, they like the style of thinking that goes into that area, or they like the businesses where that area applies to or something along those lines. So, you know, I do think that it is important to keep that Jack of all trades in mind. And I think that's a really important thing to keep in mind. Jack of all trades is a master of none idea in mind, because I do think that, you know, as one grows in their career, particularly as an IC, part of what, what you are growing on is having that domain knowledge, whether it's a business knowledge or it's a, or it's a technology area. And I think that a certain point actually specializing, if one wants to obtain, you know, really, really good knowledge, you know, you can, you can, you can, you can, you can, you can really high levels on that IC ladder. It is required to actually build some domain expertise over many years, because that's what people are looking for when they want to hire someone at that high level. The other, the other thing that I would say, and this is one of my own personal learnings, and it's been, it's been hard over time, is that I think the, the Jack of all trades master of none phrase also actually applies to people. And I, and I think in some ways, this is a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, this is even more important from an IC perspective. And by people, I mean that I think sometimes some of the traps that people get into from a career perspective is they try to make everyone happy. And, you know, if you, if you look at the way, you know, technology is built and how a lot of these companies end up working, it's, it's virtually impossible to make a decision that's going to make everyone happy. And by everyone, that might be your customers, that might be your coworkers, it might be your management. Right. And what, what I see sometimes is I see people that tend to get stuck in that, you know, I'm going to try to make everyone happy, but by trying to make everyone happy, I don't end up making anyone happy, if that makes sense. And that can be, that can be a, a rut that actually limits career progression. Because again, I have found that to, you know, to advance to higher levels from being an individual contributor, you tend to have to make bold bets, right. And, and some of these, and, and, you know, and not only make bold bets, but you have to actually, you know, do them, right. But, but in making these bold bets, you know, you're going to be proposing projects and things that not everyone is going to agree with, because that, that's just the way the world works, right? Like people don't agree on everything. And I think the other piece of advice, and this is, you know, it's not something that we can cover. In a, in a, our podcast is not something that I could probably even write down. It's something that you learn from experience. And I have made many mistakes over my career in this area. But I think that, you know, you have to know when it's okay to say no to someone or to do something that someone's not going to like and when to actually push forward. And, and I think, again, I think that skill is even more important from an IC perspective, because, you know, there's less default power, if that makes sense, like the power is all from natural leadership. And, you know, you just have to navigate the situation to know, you know, this is, this is the, this is my goal. These are the people or the group of people that are going to help me achieve my goal. I'm going to try to work with them and make that situation work and make them happy and make it happen. And, you know, if I have to make some other group of people unhappy for a period of time, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, and, you know, until we achieve this thing, that might be what is required. I realized that that might be kind of nebulous. But, but it's, it's, it's, it's a, it's a, it's, it's a complex dance of like, trying to thread that needle of, you know, getting stuff done, you know, build a coalition of willing people, and then make it happen. Yeah, it's, it's not easy. And these, these kinds of, you know, at any point where you are growing in your career, you are going to run into a not optimum solution, right? And the situation where there are no good answers, or there are going to be a, you know, trade offs in whatever answer you choose. You're going to trade something. And usually those trade offs happen because of some human interaction, some, some human, uh, uh, uh, relationship that you have to deal with. Yep. And, and that's, and that's, again, I think that is why that there is a perception that climbing the ladder as a manager is quote, not as hard as an IC. And, you know, and there might even be some truth to that, just in the extent that, like we talked about before, as a manager, you know, you start with a group of people, if you do a decent job, maybe you get a second team, and then things just naturally go from there. And you have, you know, like, built in power, built in, built in ability to tell people what to do. Whereas as an IC, you don't implicitly have any ability to tell anyone to do anything. It's all natural. It's all natural coalition building. Um, and my own experience for better or worse has been that, you know, um, I don't want to say burn bridges because I don't know that that's quite the term that I would use, but I have definitely, I don't know that that's the term that I would use. I've definitely had to, I've had to make decisions in my career. I've had to look at, uh, you know, look at things that I can do and realize that this decision is going to make this group of people angry, but you know, it is the right thing to do. And, you know, this other group of people supports that. And because I can't tell any of them what to do, right? Like I'm going to balance this natural coalition building to figure out the right way to achieve my goals. Um, so I just tend to, I'm not going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. Um, you know, as an IC, particularly at higher levels, um, it tends to be a lot more fluid in terms of how things are done, you know, how you, how you get people behind your ideas and how you push things forward. Yeah. Yeah. Yeah. This is excellent advice that you've given to developers. And of course, um, definitely recommend reading the tweet thread as, as well. There's other stuff that was discussed there that we haven't discussed on today's episode. Uh, and I really appreciate you again, uh, coming on the show and talking about this. I think it's really critical for, for developers who are listening to the show. You know, the reason you listen to the show, uh, presumably is that you care about your career. You're actually investing time. This isn't just a, you know, uh, uh, an entertainment podcast by any means you care about your career and you're investing time. You're trying to get better at it and you're trying to become a better developer. You're also trying to figure out how do you navigate all of the people, problems, all of the politics, how do you navigate job changes? And so this, this episode has, you know, essentially, uh, what Matt has provided here is his own story of how he did that and how you could, uh, potentially take some of his, uh, hard-earned wisdom. I'm sure it wasn't all, you know, easy for you, Matt. Uh, I'm sure there were times where you weren't entirely certain. It sounds like you're very confident now, but maybe, some of the decisions that you made in the beginning, you weren't as confident about it. It wasn't so easy. Uh, uh, you know, of course, hindsight is, it's very rosy looking back because all of this has led to this wonderful career where you are now, but in the middle of it, it may not necessarily be so easy. Yeah. I mean, what's, what's fun about this conversation or what, what is actually surprising to me is we've been talking for about an hour and I actually feel like we've, like, we've just scratched the surface. Right. I mean, which, which this is such, this is such a nuanced and complicated topic that, you know, I, I almost feel like you could talk for hours about this and not really unpack everything. Um, and it's, it's, it's, uh, very, very interesting to think about. Yeah. And I hope that, um, we will have people who continue this conversation afterwards and ping you on Twitter, ping me on Twitter, um, with questions and that kind of thing. Maybe we'll do another follow-up episode. Uh, because I agree there's so much to unpack here and there's so much complexity, uh, that is, you know, the navigation of a career in this, in this industry, uh, as a software engineer. So I really appreciate you sharing. Uh, I have one more question for you, Matt. Sure. Sure. Go ahead. If you had only 30 seconds, since we want a couple of hours, but if you only had 30 seconds worth of time to provide advice to developers at any level in their career, what would you tell them? Oh, 30 seconds. Um, that is so, so tough. Um, I think, I think my, uh, my advice for developers, uh, ultimately would be, is that at the end of the day, there's, you know, there's, there's lots of, there's lots of noise in our industry. Um, there's lots of noise on social media and there's lots of, um, lots of things that people talking about being important, um, career progression and, you know, et cetera, et cetera, et cetera. I think that my advice for engineers is that ultimately as an engineer, you have an incredible power because you, you build things like you actually fix things, you actually make things. And I, I think that from an IC perspective, I think that is, that is the biggest, that is the biggest hammer that you actually have, which is that ultimately you are what makes that product get, you know, you, you, you, you, you, you, you, you, you, you, you, you, you, you, get built. You are what makes that product stop crashing. And I think that, you know, really keeping that in mind and really realizing that as much as everyone talks about lots of lots of the ancillary stuff, it is the engineering, it is the code quality, it is how well things work, it is how efficiently you can build that software or that hardware, you know, that is ultimately, at the end of the day, what people care about, because that's what the businesses do. So I would just say, don't forget that, like, it's important to look at all this other stuff. But at the end of the day, you know, we make stuff, we build stuff, and lots of people use it. And that is very important. So sorry, that was longer than 30 seconds. But that is the piece of advice that I would give people. It always is longer than 30 seconds. There's no clock. But yeah, that's excellent advice. Remember that we're building it. We're building it. We're building it. We're building it. Ultimately, all of this management is to support that. And, you know, keeping your mind on that, even if you do, you know, you're listening to this podcast, you might actually say, you know what, actually, I am interested in leading people. And that's still, you are still supporting this building of things. And that's, that's really what it comes down to, right? Yep, for sure. Matt, thank you so much for joining me on Developer Tea. I appreciate your time very much. All right. Thank you for having me. A huge thank you again to Matt Klein for joining me on Developer Tea. You can see and start using some of the work that Matt has produced by heading over to envoyproxy.io. Thank you so much for listening to today's episode. And thank you again to discover.bot for sponsoring today's episode. If you are interested in creating maybe a chatbot or a voice interface to a service that you already provide, or maybe you just want to read a little bit about the news, the latest bot news, go and check it out, discover.bot. Slash developer tea. It's a community to join. It's free for you. Discover.bot slash developer tea. Thank you so much for listening. This show would not be possible without the spec network spec.fm. Spec has been around since the beginning, essentially the beginning of developer tea. We started it to help driven developers and designers level up in their careers. Go and check it out. There's tons of other awesome content like for example, react podcast and tools day, design details and does not compute and, there's a ton of other con awesome content. Go and check it out again. Spec.fm. Thank you again to today's producer at spec, Sarah Jackson. Thanks so much for listening. And until next time, enjoy your tea.