And 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 OnVoy. My name is Jonathan Cutrell and you're listening to Developer Tea. I created this 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 please 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-in manager. Why isn't that the route that you've chosen? First of all, and then secondly, what exactly have you chosen instead? Yeah. 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. I think that as you become more and more senior in your career or one's career, the line gets blurry 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 having the capability to sway people to follow a particular task. I think that there's a big difference though between generally leading people and then managing people. I think the difference from a pure management perspective comes down to, I think it people managers first priority is obviously growing and caring for all of the people that ultimately work for them. 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. Those are super important things. If you look at larger companies where you end up having these tiers of management, these obviously super important skills. You need people to be caring about people's careers and doing performance reviews and all of that type of stuff. It's not that I don't think that that's important. It's not what inspires me on a day-to-day basis. I'm much more inspired by solving big technical problems. I love nothing more than to take on a giant challenge, particularly something that is said to be quote unquote impossible. This is not impossible to do in this period of time or it's not impossible or it's not possible to do just at all. I love 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. 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. Those are the things that ultimately make me super excited. I think as I progressed in my career, sure, there's always been opportunities where maybe I could have switched over to people management. To me, for better or worse, our industry, especially larger companies, tends to make people choose between do they want to focus on people management or do they want to focus on technical. I've never been willing to leave my technical aspirations. I just enjoy it too much and I think that I can have a large impact that way. I think at a super high level, that's why I have never become a manager. What do you say to the people who are skeptical that they will stall out? At some point, there's a ceiling for the engineers but there's a higher ceiling for manager type work. How do you respond to those kinds of, I guess you would almost call them accusations, right? This is a super nuanced topic. It's a super tough topic. I think what I would say is that, look, first, it's important to realize that as people grow in their career, these things tend to be pyramids. I mean, there tend to be fewer opportunities as people climb that ladder. That's similar for being an IC or if you're not being a manager or if you're being a manager. I think that there's different skill sets that are obviously required for climbing that ladder in both cases. Some of them overlap. The higher that one goes, there's obviously a politics, there's technical skill, there's people management skills, there's all of these things. I guess my response would be is that climbing the ladder is hard period. It's not like one can eject out of being an engineer and their guaranteed to become a vice president at some large major company. That's obviously not the case, people that become executives at these companies, they have a particular set of skills that have let them rise to that level. Similarly, people that manage to 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, those are people that have done probably fairly incredible things, not always in all cases, there's always exceptions. My response is that climbing the ladder is hard period. There are going to be people that are going to reach their career limits whether they are their engineers or their managers. That doesn't mean that they can't have completely fantastic careers and earn great livings and have fun and provide for their families. Everyone is going to make it to these high levels. I think that as people grow in their career, there's a lot of thinking that goes into how career motivated are people, how high do they want to grow or how high do they want to climb that ladder. I think that depending on that, depending on how seriously people take that ladder climbing or if they want their growth to be organic, 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 lots of companies, and this is a pervasive industry problem, I think people feel that they have to become managers in order to gain that larger influence. Is that what you're alluding to? Influence. Of course, a lot of people are going to be concerned about, is my compensation going to grow? 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 I think that with the first part said, which is that climbing the ladder is hard period, 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 the increase in scope. I think a lot of engineers feel that in order to have that scope, to have the seat at the table, if you will, to make decisions that they have to switch over to people management. Well, we're getting into territory in which I can get into trouble. But I think that many companies, there is some truth to that. 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 suited to doing that and that has its own major set of problems. We have people move away from engineering who are very good at it and can provide mentorship and can teach that next generation of junior engineers. They tend to move into management and might lose some of their technical skills. I do think that there's some truth to it. I think I've seen this at various companies that I've worked. I have just personally made a conscious decision that I am not going to do that. I think that's based on a couple of different factors. One of them is just that 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 people manager, but if you're being in my opinion if you're being a good people manager, your focus has to be different. Your focus is growing that team, nurturing that team, making sure the team is operating at a very high level performance. It's not actually building the thing. I think the second thing for myself, and this is probably part of your line of questioning, is that I have the right personality and I think the right skills to stay a individual contributor and navigate some of the politics that lead people to actually saying, this is not for me, I'm going to become a manager. I think I've been able to navigate that fairly well and I've been able to grow my career in a way that I'm excited about, but it has taken a lot of active management for sure. 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 commitment usually to fight because it is the common picture of leadership as you climb up, you literally climb that pyramid. You should have fewer and fewer peers at your level as you climb up in your career. That's mostly based on the concept that you are essentially training people to do. It's kind of like the old model of a blacksmith, right? Training other blacksmiths to do the blacksmithing work. Once you're good enough to train, then of course you should be training so that you, as you cycle out of your job, those people can take your job. That model is very different now, at least it can be very different with the type of work that we do as engineers. But unfortunately, we still have that mental model from the old hierarchy of managers being almost literally, like I guess, maybe not physically, literally above, but in terms of hierarchy management being the only way to climb. Yeah. And this is a super, super tough thing. And I think that in the Twitter thread that I wrote about this and that I think you saw, the biggest piece of career advice that I typically give people is really this. And it's very simple is that I think that a lot of people, when they enter their first job and they talk to their manager and they figure out what they actually want to work on, I think a lot of people, honestly, they put a lot of faith into their company and into their immediate manager around, 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 the piece of advice that I give people typically is that no one drives your career other than you. And I think that's the most critical thing. And I think that it sounds so obvious, but I've learned from experience in mentoring and talking to people that it's not super obvious to people. And I think that's what I would tell everyone is that don't assume that your manager has your best interests in mind. They hopefully they do, but they might not. Don't assume that they're just going to intuit what type of work you actually want to do or what skills you actually want to grow in. So I really tell people to advocate relentlessly for themselves in terms of figuring out what do they want to work on, what skills do they actually want to acquire. And in my career, and this is something where if you get a manager on your show, they're going to disagree with what I'm about to say, which is that I have found in my own career that it has been just substantially easier to move jobs every few years. I'm not suggesting moving jobs every six or 12 months, but I have found that after three or four years, or somewhere between two and four years at a job that I have extracted what I think I can grow from that job. I've extracted the skills that I can acquire. And then from that point, it's time to 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 stay a individual contributor, I think that it's almost similar to being a consultant in a sense. And you drive your career, like you advertise for yourself, you find your opportunities. Whereas I think to your point, I think when you enter that management chain, there may be a natural progression of manage this team. And then maybe when the company grows, you can manage two teams. And then someone leaves and you can manage three teams. There's a little bit more of a natural progression, whereas I think from a single engineer perspective, there is no natural progression. It has to be much more self-directed. Yeah, absolutely. I think there's some... A lot of people who are listening to this right now, they may not even know what they want out of that. And it takes a lot of introspection and time, it may actually take experience, experiencing the thing that you didn't know that you enjoyed to decide. Well, so there's that. There's also... So there's technical things, do I like doing this particular area or that thing for sure? But there's also we grow as people, right? When I think about myself as a young, early 20s, something, and my personality was like back then, I almost cringe. And I'm not perfectly out. We all do, right? No, of course. And it's like, I'm obviously not perfect now. And it means far from it, but my point is that in our career, we grow not only technically but what we grow as people, too, right? And we learn how to better interact with people, how to navigate political situations, and these are skills that we learn also. So that's what I was saying before is that there is a lot of overlap in terms of 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 just generally figuring out how to navigate this volatile situation. But I think that it is possible for people to have a great career as an individual contributor engineer. But I think it does take some more proactive efforts. Today's episode is sponsored by Discovered Upbot. Discovered Upbot 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 what kinds of innovations are happening, Discovered Upbot 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 Discovered Upbot is doing. We have a lot of discussion already available on best practices for building APIs or UIs, but we haven't had an authoritative source to talk about what it means to create effective bots until Discovered Upbot. Go and check it out. Discovered Upbot slash Developer Teato get started today. Thanks again to Discovered Upbot. Once again that's Discover.bot slash Developer Tea. Let's imagine that we're talking to people who have decided that they want to go ahead and just commit or at least for now they're committed to remaining in IC and they're ready to establish good habits for the long run and avoid some of the mistakes that maybe you've learned about. 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 the first piece of advice is the one that I already gave which is that it's very important 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 I think just having that sense of self and not assuming that anyone management company someone else is going to provide that, I think that's critical. I think the next piece of advice which I talked about in that thread is that as people become more senior in their careers, I phrased it as becoming a breadth IC or a depth IC. And a breadth IC is something I define as someone that may just be an expert in a particular business area, they have a huge amount of contacts, they can design technical solutions that span an entire business. So a breadth IC at a company like Lyft where I work, they may just have an intimate knowledge of right sharing and just be able to develop incredible technologies that span that entire business area. So a depth IC would be someone that is very specific in a particular technology. And that might be computer networking like myself for web front-ends or something like that. And I think it's possible to use both strategies to actually become a long-term senior IC. I think the difference between the breadth and the depth approach, and this is for every personal person to 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. So it might require working at a company like Lyft for many years to understand all of the ins and outs of right sharing so that you can become a very senior IC who develops technologies for that space. Whereas from a depth perspective, 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 for me, for my own personal career, I have found 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 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 onto another company that needs those skills but might be applied to a particular business to me. So if I had to advise people, I would say I think that the depth approach ultimately is probably a little bit easier from a career building perspective but breath can totally work too. 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 will hear this phrase which is the Jack of all trades is a master of none. I think it's an interesting phrase because I think when one is earlier in their career, I actually advise people to go off and to work on all kinds of different things because you don't know what's going to inspire you, particular technology or a particular business area or particular type of computing. So I would work on lots of different things. I do think that people tend to ultimately gravitate to particular areas just because it's what they like, whether they like the style of thinking that goes into that area or they like the businesses or that area applies to you or something along those lines. So I do think that it is important to keep that Jack of all trades as a master of none idea in mind because I do think that as one grows in their career, particularly as an IC, part of what you are growing on is having that domain knowledge, whether it's a business knowledge or it's a technology area. And I think that a certain point actually specializing if one wants to obtain 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 thing that I would say, and this is one of my own personal learnings and it's been hard over time, is that I think the Jack of all trades, master of none phrase, also actually applies to people. And I think in some ways this is even more important from an IC perspective. My 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 if you look at the way technology is built and how a lot of these companies end up working, 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 co-workers, that might be your management. And what I see sometimes is I see people that tend to get stuck in that, 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 a rut that actually limits career progression because again, I have found that to advance to higher levels from being an individual contributor, you tend to have to make bold bets, right? And not only make bold bets, but you have to actually do them, right? But in making these bold bets, you're going to be proposing projects and things that not everyone is going to agree with because that's just the way the world works, right? People don't want to worry on everything. And I think the other piece of advice, and this is, it's not something that we can cover in our podcasts, 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 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 I think again, I think that skill is even more important from an IC perspective because there's less default power, if that makes sense. Like the power is all from natural leadership. And you just have to navigate the situation to know this is the, this is my goal. These are the people, 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 if I have to make some other group of people unhappy for a period of time until we achieve this thing, that might be what is required. I realize that that might be kind of nebulous, but it's a complex dance of trying to thread that needle of getting stuff done, building a coalition of willing people, and then make it happen. Yeah, it's not easy. And 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? Yeah. 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. Yeah. You're going to trade something. And usually those trade-offs happen because of some human interaction, some human relationship that you have to deal with. Yeah. 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 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 guys can 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. And my own experience for better or worse has been that, you know, 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 had to, I've had to make decisions in my career. I've had to look at, you know, look at things that I can do and realize that this decision is going to make this group of people angry. And, 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. So I just tend to think that, you know, as an IC, particularly at higher levels, 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, I definitely recommend reading the tweet thread as well. There's other stuff that was discussed there that we haven't discussed on today's episode. And I really appreciate you again 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, presumably is that you care about your career. You're actually investing time. This isn't just a, you know, 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 episode has, you know, essentially what Matt has provided here is his own story of how he did that and how you could potentially take some of his hard-hired wisdom. I'm sure it wasn't all, you know, easy for you, Matt. 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. 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 fun about this conversation or what is actually surprising to me is we've been talking for about an hour. And I actually feel like we've just scratched the surface, right? I mean, which is such a nuanced and complicated topic that, you know, I almost feel like you could talk for hours about this and not really unpack everything. And it's very interesting to think about. Yeah, and I hope that we will have people who continue this conversation afterwards and ping you on Twitter, ping me on Twitter with questions and that kind of thing. You will do another follow-up episode because I agree there's so much down back here and there's so much complexity that is, you know, the navigation of a career in this industry as a software engineer. So I really appreciate you sharing. I have one more question for you, Matt. Sure. Sure. Sure. 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? 30 seconds. That is so, so tough. I think my advice for developers ultimately would be, is that at the end of the day, there's lots of noise in our industry. There's lots of noise on social media and there's lots of things that people talking about being important from career progression and, you know, etc, etc. I think that my advice for engineers is that ultimately, as an engineer, you have an incredible power because you build things. You actually fix things. You actually make things. And I think that from an IC perspective, I think that is the biggest hammer in the corner that you actually have, which is that ultimately, you are what makes that product 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 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 of 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 is no clock. But yeah, that is excellent advice. Remember that we are building things. Ultimately, all of this management is to support that. And you know, keeping your mind on that, even if you do, you know, you are listening to this podcast, you might actually say, you know what, actually I am interested in leaving people. That is still, you are still supporting this building of things. And that is 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 and 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. Speck 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 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.