The Top Mistakes Of New Team Leads and Managers - Principal Engineering Manager AMA

Okie dokie. Let's get this rocking and rolling. Come on, streams. Do the thing. Cool. I think we're live. The streams are streaming. All that fun stuff. I think refresh the chat in a second. Cool, cool, cool. I got to go to actual substack this time. Nice. Okay, I think we're good. We're live. Welcome to the live stream. Um, if you're new to the live streams, this is very much an AMA format. So, please use the chat. I'm happy to try and answer any question I possibly can related to career and software engineering stuff. Um, I have a topic. I always try to come with the topic so that there's something to talk about and then of course if you want to talk about anything else just use the chat. It doesn't matter if it's off topic from what we're going through. Um I would much rather spend time answering questions because that's probably the stuff that really matters if that's what you're here to to ask about. Um I'm realizing there is tons of cat hair all over my face and I keep feeling it every time I go to move there's like one new cat hair. Um which is annoying. I got a beard and the cat hair is what's bothering me. But bear with me. I'll try my best to not fall apart. My chat is not showing up. My chat broken. That's so weird. I can't uh I can't share my chat. I don't know what's going on with that. Usually I have like the chat overlay on the stream, but uh it's just like not it's not there. Sorry folks. I have chat. I think there's people in it. Uh but I don't know. Usually I get to to show it on the on the stream, but it's just literally not showing up. That's kind of annoying. Anyway, topic for the day is going to be this newsletter article. Let me put it in the chat if you're interested. You can go ahead and check that out. Um, one sec. Feeling something suspicious here. Okay. And, uh, yeah, so this is the latest newsletter article just to show you if I go full stream. It's this right here. So, this was a topic from code commute. And on code commit, we talked about this idea of if you are a new team lead or a new engineering manager, like what are some of the the common mistakes? And so I wrote down a bunch of stuff that I've messed up on, especially early on and some other things that I've seen are like common uh mistakes that people repeat. And um the thing I wanted to start by saying is like with this kind of stuff, it's okay. Like basically no one is going to get it perfect. Um, thanks Devin. I appreciate that. I do appreciate that. Um, no one will get this stuff perfect the first time or probably ever, but you can always get better, right? So, I think that for folks that are becoming new team leads or if you're getting into a more like formal people management kind of position, this is the kind of thing where it's going to be weird. It's going to be rocky in the start and don't beat yourself up over it. um kind of look at it like a learning opportunity. And I think that one of the things that you can take with you that will be very beneficial as you're kind of navigating this stuff is is being like transparent about that. Right? If you try to pretend that that's not the case, especially with the people that you're trying to manage or navigate sort of uh you know, people situations with, people pick up on that stuff really fast. So if you're trying to pretend like oh no, no, like I've been doing this for a week, but I'm an expert. I got this. It's you're likely going to have way more success just being transparent. You know, saying that things are challenging, you're figuring them out. That's cool. I think people can respect the transparency. So, let's dive into it. Um, let's see. Uh, I think the first one I wrote about was the first one that it always comes back to me as the first example when I talk about um at least my mistakes as a software engineering manager in the beginning. and that's uh ignoring high performers. And so the legend has it that when I started uh in a in a management position, I had um I've been very fortunate in my career that I've had a lot of really There we go. Finally got the big cat hair. Get out of here. I've had a lot of really good uh software engineers that work for me. And it's funny because that's awesome. Like it, you know, makes makes my job easy, but it also makes my job really hard. And I didn't think about this in the beginning and I think it's a really common mistake, but the thought process was like the engineer is doing good already, right? They don't they don't they don't need me. They're already doing good. I'm going to take like my limited time and energy and I'm going to direct it over here instead. And then I'm going to go try to address problems more specifically with people that um you know, arguably are having more challenges, right? So that means if there's people with some skill challenges or some other things, I'm just going to spend time with them instead. And I think the reality is that even if someone is a solid engineer, you know, they're a top performer, you still need to spend time working with them and not neglecting them. And it's funny cuz like this for me this wasn't like a malicious thing where I'm like, "Oh, this person's doing awesome. like I'm going to sabotage them by not like spending time with them or you know dedicating more of my time to working with them. It was this thought of I guess it was probably like some level of imposttor syndrome where it's like what am I going to do to help this person right there obviously kicking butt already like I just started being a manager I don't really know what's going on like if I move out of the way it's all good but um in hindsight like this is just lack of experience on my part as a manager and so I say think it's really common for new managers to do even people that are very good at what they do can benefit from uh like alignment, from direction, uh from opportunities, from finding work that's engaging, right? If imagine you are a new manager or someone who is responsible for for people in some capacity, and you have someone who, you know, you're working with and they're awesome. They're really solid engineer, maybe this is you. Um and all of a sudden, like they're working on stuff that is just not their interest, right? And even if you're a really good engineer and you're stuck on stuff that you're not finding engaging and that's going to look different for everyone, right? Sometimes it's learning opportunities, sometimes it's impact, sometimes it's just really unique challenges, some technology, it could be anything, very different for individuals. So this engineer is working on something that's really not getting them engaged. Then what happens is over time their their productivity drops, their um their and when I say productivity, I don't just mean like lines of code. what I mean? Like their u their overall output in terms of quality and quantity is declining and they're less engaged and all of a sudden they go from being like really awesome to kind of like they're just getting more and more disengaged. And this can happen when people feel kind of stuck in a spot. And if you're not careful as someone who has influence over people and the things that they get to work on and the direction that they're growing in, people can feel trapped and then they can start to stagnate and then they hopefully I would say hopefully in this case those people leave, right? Not that we want them to go, but for that person's well-being, I hope they leave because they're not getting support from their manager. Right? So this is one of the I think the biggest missteps I made early on. uh took me a few years to learn this kind of a almost feels like embarrassing to say that but it's the reality. It took me a while to learn this. Um the excuse that I give myself for this was like there was a lot going on, right? So um I worked as an individual contributor and a manager. It was at a startup. I was already working a lot of hours. I only have so much time. So if I got to cut something, it's going to be the people that are already, you know, kicking butt. And um I don't know, like was it the wrong move? Like I don't know. Things things worked out in the end. So like again, I'm not beating myself up over it. It just feels kind of silly in hindsight to say that it took me so long to kind of learn that. But I think that's number one on my list for things where I'm like, please pay attention to that and don't uh don't neglect it. My uh I wonder if my Twitter chat's not working. I'm just noticing like reream is showing that there's zero people from Twitter, but usually Twitter is like overwhelming in terms of the the number of people. Am I not even Oh, it says I'm streaming. I just went to Twitter so I could check. You got to check the There's It says there's lots of people. What the heck? Can I join my own thing? How does this work? Open live screen. Wow. Hey chat, it works. So what? Everyone on Twitter says quiet today, guys. Come on. Cool. Okay, let's go to mistake number two. You guys are going to make me wrap up my stream in like five minutes and then you'll get back to coding and other stuff. Um, yeah, Devin, I don't know why I can't get my chat to turn on. It's really weird. Um, I got this little thing that that centers my face when I make YouTube videos, but um, not my chat. So, um, I don't know what's up with that. Anyway, sorry. I will I try to moderate and read out the chat as it's coming in, but like no one's using it today. Isn't next weekend the long weekend? What's What's going on? I'm probably going to be streaming next weekend, by the way, because it's a long weekend and what else am I going to do? Okay, mistake number two, uh, defaulting back to coding. I think this might be the most common one, and this is a it's a little bit controversial, I think, because I think that some people can take really aggressive stances on all this stuff, and you can have your own opinion on it. That's totally cool. But I think it's a a scalability challenge. Can I place a quick note on the screen? Yes. Uh, sorry. Someone on Substack is asking if I can place a quick note on the screen. I think I can. I don't know how I could share my screen or something. But, um, so engineering management and coding, team leads in coding. I want to talk about these things like I think there's a bit of a spectrum of things going on here and what I would say is that if you are working in small teams uh especially like in startup environments right if you're an engineering manager or a team lead and you got like one two three four people kind of working directly with you or reporting to you it probably makes a lot of sense that you're still coding probably what gets interesting is like once we start getting past that number. So 5 6 7 8 9 10 beyond 10 at some point um it's a scalability issue and the reality is that if you're trying to do the other expected parts of your role as a team lead or engineering manager I feel like teams I don't know you probably don't have like 10 people reporting to you as a team lead I realized at different points of my career I have had a team lead title had full comp view and managed teams of more than 10 people So, I don't know, kind of weird. But the reality is this kind of stuff from a scalability perspective, you coding things is not the thing that scales. You coding things is generally not the way that impact is measured. A lot of this stuff changes as you become either more experienced or take on more responsibilities as a team leader, engineering manager. Now again, I'm going to be using some I don't know some roles and stuff here that it's not going to exactly align with like every company and the reality of every situation, but I kind of look at like a team lead role as as a very good stepping stone if you want to get into engineering management. In some cases, like I said in my example, team lead and engineering manager. For me, that the the title changed at one point and nothing was not a promotion. There was no pay increase. no team or responsibility changes just like they relabeled it. So the um the roles can look very similar but it I would say in a lot of places you might have a tech lead, you might have a team lead, you might have like I have some feature crews and for context that's kind of like I have my engineering team of people that report to me and we have that broken up across several feature crews like smaller sub teams and I have a couple of feature crews where there is like a what we call like a tech lead. So it's someone who is more responsible for like technical guidance. Um they would be like you know like the principal engineer on the team or the feature crew in this case. Um someone that you know like they don't have to put every decision through me or anything like that. They're a really good person for technical guidance. Like I would say kind of like the the smaller teams like architect, right? But you'll have tech lead, you'll sometimes have team lead. Um, I don't know if I see both of these together a lot, but on a tech lead side of things, it's, as you might expect, more on the technology side and team lead side, you might have more from like a people perspective. And I see a team lead as, like I said, as a stepping stone for an engineering manager role. But it's not necessarily that it has to go that way or it must, you know, look that way. But you start to have some more responsibilities in your role dealing with people. And as soon as that starts to happen, right, if you watch code commute videos, I know Devon's on the stream, I always talk about level set expectations. If your role is no longer like you know uh engineer, engineer 2, senior engineer and it starts to become like tech lead or starts to become team lead or you become an engineering manager the likelihood that your responsibilities and the expectations of you changes is very high. Right? So if you're a team lead odds are transitioning into that role there's probably like hey you're still coding cool. Um are you coding 90% of the time? No. Maybe that's down now, but you are going to be expected to go do these other things that's going to take up more of your time. That's an expectation of you, right? If you are just coding still and not doing those other things, it's like you're not going to compensate for the things that you're expected to do just by coding more instead. It like it doesn't work that way. You're if you only code and you don't do those things that are expected of you, then all of a sudden you're not going to be meeting those expectations. And I think that this is a big challenge for people that are new to team lead roles and especially engineering manager roles in situations where truly the expectation is that they don't really need to have their hands in the code anymore. Um, like I said, if you're dealing with smaller teams, might be very normal, very natural. Like I, when I worked at Magnet Forensics before Microsoft, I had teams. I was at one by the end of that I was managing two engineering teams and coding like a little bit, but just because by that point, I was kind of running around doing a lot more stuff across the company. So, um, but up until that point, I was still coding like almost every day. um and at that point still could code every day. It's just I physically didn't have enough time to go to do that. What I started to learn by that point, it took me years to really solidify this in my brain is like the my ability to have broader impact meant that I needed less time coding. It is sort of the natural transition as you're scaling up your management abilities. Now, that doesn't mean I'm not sitting here going like engineering managers, it would be dumb if you know how to code. It's not what I'm saying. I'm not saying that engineering managers have to code or don't have to code. I'm not not debating that. The point is that the expectation of you in a team lead role or in an engineering manager role has changed. It's evolved from what it once was as an individual contributor. That's totally cool. So the sort of the mistake that I generally see people making is not acknowledging that and then what ends up happening is that they don't think about that as an opportunity. Now what I mean by that is let's take for an example um you are a team leader, you're an engineering manager and every time there's a problem that comes up and you're like I know how to solve that in the code like I'm going to go do that. Every time you do that, that's now creating a dependency on you to do that. You're not giving other people the opportunity to do it. And instead, I think the better framing here is like it's not that you're not allowed to do that or that it's bad if you do that, but when it becomes every single time, right? Think if you change the scenario a little bit, there's an incident. Okay? You're the you're going to jump in and you're going to go code the solution of the incident. Okay? next time there's an incident, you're going to go in and code the solution of the incident. If you keep doing this, what it's not happening is you're not scaling the team. You're not learning from that going, hey, look, if I'm the person who always goes in and has to fix this particular class of issue or something like, do I need to train up someone else on the team to take care of this? Do we not have enough people on the team? Deon says, you're creating a dependency and uh devaluing your position. Yeah. So, um, and like when I read Devon's sentence there, um, the thing that I would like call out even even more is like Devon says devaluing your position. It's like it's not that it's not that you trying to help is the wrong thing or like you should feel bad for doing that or something, but like you're not you're not scaling. You do not scale that way. that is like they're they're fundamentally different roles as an individual contributor versus someone who is managing a team. And if you're not keeping in mind like this awareness of like how do I grow and scale this team? Growing the team by the way doesn't necessarily just mean more headcount could mean like like skilling people up or build uh building expertise in areas. So when I say growing the team, it could mean new people coming in. It could mean skilling up individuals. It could mean both. If you're not thinking about that and you keep going back to I will put out the fire. I will put out the fire. It's not going to scale. That might be what's needed at a company at some point in time, right? You might be at a startup and that's what you got to do. So the advice I'm trying to give here, like you need to keep the context with it. I'm not here to say like you can never do this, but it I think my statement holds it's not a scalable thing to always do that. Hello, Yuki. Welcome. Good to see you. I'm just going back to Twitter because I think my there's still no Twitter chat. There's a bunch of you on the the Twitter live. You're keeping quiet today. Okay. Okay. How's Instagram doing? Pretty uh pretty dead as usual. That's okay. Um okay, let's go to the next one. Mistake number three. It's kind of similar. Um I called it becoming the bottleneck. And so we can use some different examples here. It doesn't have to be like you're the one who is coding the fix, right? But like there might be some stuff that you've historically been responsible for. It's a very similar example to what I just gave, but you might have been responsible for a bunch of things because you were maybe you were a tech lead or something before. You were a subject matter expert in a particular area. Again, there's nothing wrong with you continuing to have the expertise in an area. It's not like I'm suggesting, hey, you became a team leader. You became an engineering manager. Empty your brain. You don't need any of this stuff anymore. Like, um, that's not what I'm saying. It's it's mostly that you need to start looking at like how you scale yourself. And I just wanted to see if I wrote this. Um, no. Okay. Okay, I'm going I'll talk about it here because this is I talked about this in the code commute video and I'm trying to refine how I talk about this because I I very strongly believe in it but I I don't think that I articulate it clearly. So, um I've done live streams on this actually. So there's a newsletter on it, there's a live stream on it, and I have probably talked about it a bunch on Code Commute, but I always talk about, or I shouldn't say always talk about, I like thinking about this idea that in order to to scale your effectiveness, you need to make yourself obsolete, which sounds ridiculous, and it's kind of on purpose because I I want that to I want that to land. I want you to kind of pause and go, huh? Like, what do you mean? Um because I think immediately people go to like, well that's not good job security. Like what do you mean? Like if I'm obsolete then they don't need me, right? But it's sort of different framing. I think if you were to take this classical view of like job security, right? I have something and people need to keep me. You need me here to do this thing. My job is secure because you can't get rid of me. I got that thing you need. Right? But the reality is, I don't know, people get rid of you. You could you're always replaceable, right? So, instead of looking at this this outlook of like, how do I find the thing that's going to secure my job that people can't get rid of me and latch on to it? I don't like that for many reasons, but one of which is like I actually think that's while that might seem like job security, I think it's false. First of all, I I think that that limits your growth an extreme amount. And the reason I say that is because if you are the only sole responsible person for this this thing, whatever it happens to be, they can't fire you because you're the one who's got the thing or knows how to do the thing. Your time is spent doing the thing. They need to keep you to do the thing. So instead of your time and energy going into other things like that are going to uh be new learning opportunities for you, more impactful areas, could be different moving to a different organization, whatever. You can't you can't because you're attached to this thing that's your job security, right? That's the thing you're anchored to now. So it's a double-edged sword. And I don't think it's worth it, first of all. So, I think I like tossing out that narrative of like, you know, job security that way because I think it's actually very limiting. You could have examples when you want to disagree with me on this. It's totally cool. It's just not the outlook I choose to take. So, park that. And then we go to this other side where I'm like to, you know, to progress and scale yourself, you need to make yourself obsolete. Well, it sounds ridiculous, but my point is that imagine you go into drive impact somewhere. Okay, so you're responsible for uh like as a manager. Let's because we're talking about team leads and managers and stuff here. You can still take this. Let's use a software engineer example first because uh I think most of the audience is probably software engineers and maybe people that are team leads or aspiring to be um or managers. I think if you were tasked with going to drive some really big impactful change in an area, whatever that might be, right? It could be like within your team, could be cross teams or maybe even across an organization and like you're going to go do that thing. Okay, that might be saving a bunch of money, putting a system in place, whatever it happens to be. If you go do that, okay, so you and you spend months on it, right? Maybe it's a year-long project, whatever it happens to be. All of this time and effort goes in and you finally deliver the thing and it's awesome. You were successful. If from that point on you are the person that needs to maintain that thing, that now means that you're paying this tax for this thing, whatever it happens to be, right? And that means that if you are constantly paying this tax, your time and effort goes from whatever like 100% capacity to now whatever that tax is, maybe that's 20% of your time and effort goes to maintaining this thing. So it was awesome that you were able to deliver it. Very big impact, but you pay the tax on it now. So cool, that's 20%, but you still got that 80% capacity. You're going to go tackle another really big thing. You put all your time and energy into that. Cool. Now you got these two things you're paying tax on. And tax doesn't really just add. It's gonna kind of scale in a different way. So now between these two things, you're paying a 50% overhead tax. You see the problem? So you end up delivering this really big impact, but now you have this tax that's associated with it because you're the one you're the person who put this in place, right? It's maybe you're not thinking about it on purpose this way. Like that's your job security, right? Maybe not on purpose, but if you want to go on and do the next set of big impactful things, how can you possibly do it if you're overall capacity keeps shrinking? Because the things that you have landed that have been big and impactful are things that you now have to maintain and support like you do. Not like they have to be in general. You have to spend time on that. It's not scalable, right? So this is, you know, general example of what I mean by I think that if you want to continue driving really big impact, you basically make yourself replaceable. You say, I don't need to be the person that manages paying down this tax. Doesn't need to be me. That could be that could be Bob. Get Bob to do it. Bob would love to do that. Bob is in this position where that's a really good stepping stone for him to really have ownership on this. great opportunity for Bob and like not a great opportunity for me anymore. So like this is not a tax for Bob. This is an opportunity for Bob. This is a tax for me. So give the the tax as an opportunity to Bob and I'm going to go do this other stuff. And now you're freeing up more time and capacity for you to go do other great things. So we can apply this kind of thinking into team lead and management kind of positions because for all these things I was just talking through if you're if you're the bottleneck or you're not sort of scaling yourself you're paying a tax and I don't know if that like that that's landing. I know uh when I was at Microsoft, I think it was the first time I heard someone uh one of the engineers on my team uh you know, principal engineer was was talking to me about something and described something as paying a tax and I was like for me that like really really solidified like I thought it um helped me think through things. So I keep using it as an example, but I think it's it's really true, right? Like if I need to be stepping in to do this stuff all the time, like I'm the go-to person for it. That's a tax. Like I'll give you give you a super simple example, but like there's certain things at Microsoft that like I need to give approvals for, okay? Not not because like I'm super special, but because of my role and how things are done, but it's like if that was one category of things, sure, it's fine. But there's like I don't know like 10 plus categories of things and those can chew up a lot of time. So like that's a tax I have to pay. And although it seems like a small one, I could give you lots of examples where if we look at how my time and energy gets spent, there's lots of little taxes I have to go pay. So I'm always trying to think of ways of like how can I make myself replaceable in this situation? I don't want to be paying a tax. Right? Again, this will sound kind of funny and it's not a good management or leadership approach, but I feel like if I like a a measure that I'm doing my job at least reasonably well in some aspects is like if I can step away from my team, if I could walk away for two weeks, right? Hey guys, I'm going on vacation for two weeks. You cannot contact me. there's physically no way to do it. If I could leave and the team feels like they can still rock and roll, they can make forward progress on the stuff they're working on. Something comes up that was unexpected and they're like, "We feel like we're empowered to make a decision on this and prioritize it or not, right? They can come together and make those decisions and that I'm not there." That's good. Like that's what I want, right? Right? And that doesn't mean that like, oh, I'm not needed then cuz look, they just did it without me. The point is that there was a lot of ongoing effort to try and get the team to a point where that was possible. Okay. So, um I like thinking about trying to make yourself replaceable because I think that that's the way that you scale the best. So, that's um one of the things I wanted to talk about when on the on the newsletter I was talking about like being a bottleneck. Um, I kind of touched on this fourth one already. It's like how we measure impact. And um, my name, what's my name, lad? My name is Nick. Am I a lad? Is that how that goes? I don't know. That's interesting. Um, measuring impact the old way is what I wrote down again. um level set expectations, right? Like how is how is your performance being measured? What is the expectation? Oh, well that's very interesting. You got to you got to get blocked, man. You guys can't see the chat. Someone um Oh, man. I should I should have shared my screen. Someone from Kick just joined and said, "Hi, what's your name, lad? which is why I said, "Nick, you're probably if you can't see the chat, right, you're probably like, what's this guy talking about?" And then right after he said, "You will be killed soon." Okay, you're out of here. Uh, that's a weird thing to say to some stranger. Um, okay. Um, but yeah, level set expectations, right? So again, I always talk about this, but if you are really unclear kind of stepping into a new role, if that's a team leader, an engineering manager, whatever it happens to be, if you're unclear about the expectations, not only like it's very easy to kind of fall back into some of these older patterns because you are used to having your impact being measured a certain way, right? you have been successful so far probably because you've been killing it delivering like large features working through really uh difficult technical challenges like there's probably a lot of things as an engineer that you've done an awesome job on how you've been measured right there's been years of you being measured this particular way that's what you know that's how you got to where you are and that's awesome but it changes and then people don't tell you this stuff like what's management training look like? It's like, okay, well, hey, you've been an engineer and like, um, we're promoting you to a manager, so there you go. Thank you so much for your work and you start on Monday, right? Like there is no training. There's there's training available, but like it doesn't happen, right? This is the kind of thing that people get tossed into and then we're all shocked why like people don't do a good job. Or you might have a new manager, right? someone who's like literally new to you and new to managing and you're like, "Wow, this person sucks." And it's like, "Yeah, man. They suck because they don't know what they're doing." And it's like it's not their fault. Someone put them into that position not really thinking it through. So, I I think that if you are kind of new to this, like it's okay. Go ask for clarity. Go get this stuff sorted out. Ask questions in the beginning. You're new to it, right? I think that's something if I could go back in time I would like like coach myself on that is like I said this near the beginning of the stream. It's like you don't need to pretend like you know everything. You literally don't and you're literally probably going to be pretty bad at your job. But one of the best ways that you can start improving is just by like acknowledging that and being like I got a lot to learn. How do I get better? Right? How do I look at what I'm doing? How do I refine what I'm doing? And how do I get better? and you just keep doing that and you're going to mess up a whole bunch. But when you focus on how you like used to be measured, that will hold you back, right? You're not going to be spending as much time like working with people on your team. Like you like you're skipping one-on- ones and stuff or you don't schedule them and like that's not really that important. I'm just talking to people on my team. I talked to them already anyway. I got code to write. No. Right. like there's things that you need to be doing that are part of your new expectations and you can't be like dropping those to go code um or or whatever kind of pattern you're falling back into. Deon says also consider that and if you're in a growing org, your boss might not even have an idea of what your new job looks like. Yeah, setting those uh expectations up front will be will help resourcing. Yeah, like there's there's just a lot of the time uncertainty and I think that's important to acknowledge. But um for this particular part, you know, I wanted to just kind of touch on the fact that it's uh I don't blame people for this. It's very easy, pardon me, it's very easy to fall back in this pattern of like this is what I used to do and that's what's got me here. I'm gonna keep doing it. And so I think like if you're a manager listening to this, I would highly or like a senior manager, I would highly encourage you when you have new managers, try to be very clear about their new expectations. Don't assume that managers know this stuff. Seems like I don't know like think back to when you became a manager. There was probably no training. Guess what? There still is no training with this stuff. So, if you are becoming a manager, recognize there's probably no training. You need to go ask and get this stuff clarified. And it's going to look different absolutely everywhere. So, you're hearing me on this stream talk a little bit earlier about like, oh, like don't need to be coding as much that doesn't scale. You might be at a startup and that startup is at that certain size for six years and you're like, "Dude, I've been coding every single day and there's literally no opportunity that I'm going to scale my way out of this. Like if I don't code, like our team's falling apart." Yeah, like I get it. Like I worked at a startup. I understand. My point is that like my argument still holds like you do not scale that team if that's what you're spending all your time doing. It might be necessary, which is a difference. It might be necessary in what you're doing, but it does not scale. So, uh, I say what I say for a certain reason, but don't misinterpret it. Uh, and it's not that coding's wrong, and it's not that every situation's the same. It's just that it doesn't scale if you're spending all your time doing it. Okay. Um, healthy conflict. This is one I would like to talk about, I think, probably more than I do. And um I think I have like I don't know from from startup experience I feel like I was pretty lucky that there was a lot of this and I don't know I feel like I don't I don't know what other people's experiences are. Um, people can't see the chat, so it's kind of unfair if they want to share their messages and stuff, but um, I think this would be a great one to hear different perspective on for for folks that have like been through whether it's teams, companies, whatever, where like have you had situations where there's like regularly healthy conflict or is anytime there's conflict, it's like it's heated, people are like aggressive, and it sucks and like you're like, I never want to go back to work again. Um because obviously the latter is not what we want. But I I think healthy conflict is is really good. And when I talk when I like use the phrase healthy conflict, what do I mean by that? It's more like whether it's roles, groups of people, like people feel comfortable taking completely different perspectives and like standing up for that, right? And if we take like traditionally sort of these different roles, right? If I I I realize this is not like generically going to apply everywhere, but we take a product manager, stereotypical product manager, what do they want? They want more features faster than last time. That's what product managers want. I'm exaggerating, but you get the idea. And what do engineers want? We want to pay down the tech debt. That's all we want. We don't care about your new stinking features. This codebase is rotting. We need to pay down the tech debt. There would make be nothing in the world that makes me happier than rewriting this crappy legacy code base. Oh my goodness. Let me rewrite it. Right. And I think, sorry I'm exaggerating to try and paint this picture, but um if we have healthy conflict in a team and we can bring these roles together, I actually think that it's great when you can have someone being like, "Look, man, we need to pay down all of this tech debt. Nothing else matters. Tech debt ends today." And you have a product manager who's like, "I never want to hear about tech debt again. we are shipping all the features by the end of the workday. And then you bring these people together that are like I feel like passionate about my stance on this. But this is where the healthy conflict part comes in. It's not who is louder than the other person or who can be more right than the other person. It's here is my perspective. Here's like my like sort of belief and value system to support that with the evidence that I have. And then the other side does the same thing. But while each side is sharing, the other side is actually listening actually. Because the goal in healthy conflict is not to say, "Haha, I was right. My way wins." That's not the goal. The goal is to take your belief and value system, stand behind it, and bring that to the table when the other side does or multiple other sides do, different stakeholders, whatever it happens to be. and everyone listens because the goal is not who's right. The goal is about finding what the best path forward is and that's what we're aligned on. If you have not experienced this kind of thing, I feel like it's a huge missed opportunity. Um, yeah, Devin says, "Listening, not waiting your turn to talk. There's a huge difference and they might look the same on the surface, but like think about that statement and challenge yourself next time you're sitting in a meeting because when someone's talking to you, if you're like holding on going like but and every time like there's a brief pause you're ready to jump in, like shut up inside your head, stop and just like listen to what the person's saying. Literally try to understand it. Ask them back questions, right? Say the thing that they said to you in a different way back to them. Try it. Take some time to understand what other people are saying because like every single time in my career, which isn't that long, but it's long enough for me to realize like this is a thing that I strongly believe in. When people share perspectives on things and you have differences of opinions, especially when they're like coming from different angles and people are like, I don't agree with that. If you take the time to genuinely listen and understand the other side, almost always, neither side is totally right and there is something good somewhere in the middle. It might be closer to one side than the other. Doesn't matter. It might be neither of those sides. Might be a third thing alto together. The point is does not matter who's right and who's wrong. The point is that that conversation got you forward to the next step. And if you're rolling your eyes at this and you're like that sounds like madeup bull crap, woo woo, whatever. I'm telling you, if you practice this kind of stuff, if you have healthy conflict, it's like it feels like a heated conversation, but you leave the conversation and everyone's like, "Hell yeah." Like, we we did it. Like we like we got better. It feels so good. And it's a lot of energy. I'm very introverted. Some people don't know this, but I'm very very introverted. and like a conversation that's like high energy like that where people are like very comfortable sharing like strong opinions and stuff and people are like like challenging ideas and again not challenging in a condescending way not like oh yeah Billy like you think that's a good idea you dummy like go get the data for this cuz that's bull crap like not not that but like hey like you had this data to back this up but like isn't that sort of uh in conflict with this other piece or how does this other thing stack up against that kind of like just challenging perspective to understand like this whole there's a lot of really cool stuff that comes out of this. I'm just reminiscing. But yeah, it's uh it's a lot of energy and I can think about conversations like that and it's like you almost need to take a nap after. But it's it's a cultural thing. You need to have team culture that supports that. You can't snap your fingers and say, "Okay, everyone, healthy conflict time." You need to create environments where people can do that. You need to lead by example with doing that. Which means if you're in a management or team lead position, you need to demonstrate actively listening. That might mean shutting up and not jumping in with your idea, taking the opportunity to repeat back something to someone in your own words to make sure that you understood it. Right. Um Devin's saying, "I think maybe we sometimes feel like we look stupid if we allow dead air while we think about something." Yep. It's hard to wait until somebody finishes uh before we formulate a response. There's like I think if if people have been I feel like I've seen this a handful of times at least, but you and I'm trying to I don't know I don't know the right way to say this, but there's probably some folks that have experienced this where there's people that they work with or people in their company that they know about and like you know that they're like a you know they're really solid at what they do whether it's an engineer, different role, whatever, but you're like you know this person's really smart, they're good at what they There are some individuals where like it's so impressive because what they're not doing is waiting for that gap where they can like jump in and attack to get their idea in to be like aha like see my idea is the best. It's like they're very calm. They're collected. They're spending most of the time just like listening, right? And then when they speak it's kind of like oh crap. Like that's a very insightful thing. Um, it's okay for there to be silence. It's okay to take time to think and respond to things. You don't need to jump at everything. People need to practice that a little bit more. Uh, Devin says, "A team I was on used to argue and then the boss would jump in and say, "Whoa, you need to agree on something." We'd all sit back, point left, and say, "Is that true?" That's funny if it is. I was uh I was sharing an example uh with a colleague today about um we're talking about complaining. This is the context. And um this it's a little different. So, I know we're talking about like healthy conflict, but uh this can come up in like different types of conflict, but I was saying that um I don't sometimes like when people are like, "Oh, like I'm just complaining about this, like sorry, like I don't mean to just be like venting or complaining." I see like, and I haven't fully formulated this thought, but it's kind of what I said earlier today. I see like generally like two camps of this and like you can have a group or one camp that is they complain but they're not going to ever take any action. They're kind of it's I think the word I would use is they whine, right? It's like here is awareness of a problem. I don't like it, but I don't like it so much that I'm ever going to do something about it. Someone will someone will do something, right? I'm just here to to make some noise about it. That's to me that's like whining. But then there's another camp of people where they're also very vocal about things, but it's because they're trying to drive forward progress. Like they're passionate. They're like, I'm trying to get this thing done. I really care about making this better, but like this thing is in my way. And like I am very okay with that second group of people coming and complaining to me complaining because like I know that they're trying to make things good. So like yeah like vent to me about that thing that's in your way because if you really give a crap about what you're trying to do and you're very passionate about it and this thing is causing you so much friction that you need to complain about it, maybe we got to do something about this, right? And like you're clearly motivated. So like how do I find you help to do that or how do I get someone else to help like that's a that's a good thing like we can use that. Um so anyway just wanted to share that because I as Deon was saying he was talking about a team that he used to work on. I was think was reminiscing about this team that I used to manage and uh like we would basically the the story I share is like so uh you know people would like agile right agile software development by the end of it I would just say like we were you know we focused on continuous improvement but we did retrospectives and um I can like we were all very similar on this team where like we were pretty passionate about things and that meant that we weren't necessarily arguing with each other, but we would get pretty heated about stuff that that bothered us. Like we would get frustrated by it, but we were in camp 2 that I was describing where it's like we're we're venting about these things, but we're going to do something about it. It's kind of like we use that as energy to be like, okay, we all agree, we really find this thing frustrating, like okay, like we're going to get it. And um I remember we had we were doing this retro and we had someone a different role. I won't get into the details, but we had someone who was not on our team sit in on our retrospective. And basically after that they they ended up complaining to my VP or like I don't know complain is not the right word and it's not quite tattle but they like talked to my VP and there was like some concern that like the there was something wrong with the team because everyone was like angry about something and I'm like no man it's just we're just passionate about solving problems right? So that's our safe place. We're going to vent. we're going to figure out the common ground and then we're going to go we're going to go crush whatever's in our way because we're so motivated to go clear that up. And uh I just thought it was kind of funny uh because Deon was saying, you know, you guys you're arguing like you need to agree on something kind of thing, but he says it's a real example. True story. We inadvertently did it a few times and lead into it once. We realized it wound him up. Nice. Um, yeah. And sorry, another Devon had another good comment there. Also, nothing wrong with can we table this while I go do some research, so I give a more informed response. Yeah. Right. Some things if you're debating stuff and it's like, look, like I I don't actually have enough information to make a decision about that. like what's the you're asking me for an opinion like an informed opinion and I don't have data so like please let me go collect the data so I can give you a valuable response if people aren't willing to take that then it's kind of like then you actually don't care right so don't say it so yeah I think making room for that's really important so that people feel comfortable that they can do that kind of thing um so I think it's a great point let's keep going I think We're at the end though. That's the end. We got through the the article. Chat's super quiet. Not a single Twitter message. I feel like Twitter chat's broken, but my chat message came through, so it can't be that broken. Twitter, come on. You're letting You're letting YouTube win. That's crazy. Sorry, I'm just checking some of the stream numbers. Like I think since I moved channels on YouTube, the YouTube stream numbers are down significantly, which I kind of expected. That's fine. It'll take some time to catch up. Um, but it's like Twitter in my chat show zero. Twitter on the Twitter stream is double digits. Nothing crazy. It's not like there's a million people watching or something, but kind of weird. Hey, Marcos, thanks for joining. Thanks for subscribing. I appreciate you. Um, I think that's it. Um, I forgot at the beginning of this stream. I wanted to make a habit of doing it. I wanted to I thought it was fun to have AI go build something. Um, and then we check it out at the end, but I totally forgot about that again. So, that sucks. But um yeah, let me let me wrap this up, I guess, and let me see if I can talk about some things that are coming up on the other channels, too. So, let me flip over. We'll go full screen. Boom. There we go. So, this is where I go through a bunch of stuff. I'm going to spend some extra time on the YouTube channel, so just to talk about things. So, for folks, like I said, if you're new to the live streams, I use my newsletter as topics. And the flow of how this goes is that I have a YouTube channel called Code Commute. On Code Commute, I do vlog entries where it's like Q&A. So, I answer questions. I then take the popular topic from the week and then I make a newsletter article about it and then that becomes the live stream generally. So, if you like the live stream, you do not have to go subscribe to the newsletter because it's an email newsletter. If you don't want that, please don't subscribe. But if you just want to know the topic because you're like, "Hey, this is kind of cool. I'd like to know what's in the next one." Go check out uh Dev Leader Weekly, right? It comes out Saturday morning 5:00 a.m. I think every time I've nailed that. Um and so you have Saturday, Sunday, and all of Monday before the live stream to see if you're interested. Spoiler alert, you'll be interested. You got to come. So that's what this is. So that's my my newsletter. And then let's go check out some of the other channels. So the Dev Leader podcast is where I moved the live stream to. So this is sort of a new YouTube channel. I split out from my main one just so that it's more dedicated. Um kind of I feel kind of bad because I did some YouTube videos like for these interviews and like because it's a new channel like they're not getting any views. So I feel pretty feel bad about that. Uh but um these also go to Spotify. So if you like the podcast episodes where I'm interviewing software engineers, then you can also check that out on Spotify. So there's um Oh, Scott H. Okay. So again, a lot of these are are re-uploads from my other channel, but um but some are not. So the Scott Hansselman podcast episode is going up this week. Uh that's my most popular one. So, Scott Hansselman's a VP at Microsoft. A lot of uhnet developers know him. Um, oh yeah, sorry. I just finally got a Twitter message, but yeah, it's this channel. I'm just going to put it into the chat. Uh, not that you can see the chat on the stream, but I don't know. I hope it goes to the different platforms. I guess it doesn't go to Twitter, though. Let me put it in the Twitter chat. Um, so this is where the live streams go. But yeah, um, Scott Hansselman podcast comes out this week. Uh, another one that I did that's like I don't know like not all these people are like celebrities or anything like that. They're they're software engineers. The whole point is that I'm interviewing software engineers and you can see different experiences for how people got into their careers. Um, I think probably, you know, the most popular person on this list right now is Hassan Hhabib. Uh, he's got an awesome YouTube channel. He's like, he's a super nice guy. And it's very interesting like how much the people side like he's very much a people first kind of person. It literally like spills into his software engineering. Super cool. Um, very philosophical. Uh, I highly recommend Hassan Habib's content online. Uh, I have another one coming. I'm probably going to put it out next week that I'm excited about and I will spill the beans here, but I got to interview uh, Derek K. Martin of Code Opinion. And for those of you again maybe net developers mostly but um Derek is very I would say like he's well known for being very grounded in um in decision-m. So if you were to talk to Derek or listen to something that he's talking about, he will give you perspectives on like architectural patterns or design decisions and you will never hear him say like this is the best way to do it or like always follow this approach or never do this. Everything that he talks about is like context dependent. So, it's super helpful because when you listen to stuff that he talks about, it's not like, and sorry, I'm just going to use this to kind of I don't mean to pick on people, but like, oh, like clean architecture and you know, you must use a mediator and like you have to use these design patterns and like follow this templated solution. Like he's the the opposite of that, which is like there is a time and place for everything. And like if we understand how these things work, then we can go understand how to apply them in the right time and place. So very excited for Derek's interview to come out. Um that's a really special one for me. He actually it's funny if I think about where I used to live back in Canada. He he lives like not very far from me. So yeah, Devin says Derek's a master of it depends, but it it's exactly it. It's all about the like what is the context and he'll walk you through it. So, um, that was one of the questions I asked in the interview. I was like, Derek, like I need to know like how do you channel this in like every conversation you have. It's like very much like a it depends. It's it's very good. So excited for that. And I'll probably do another round of posting to see if I can get more guests because I think I'm most of the way through getting them edited. But we had a a pretty good wave. Um, I thought some really exciting ones like I don't like I feel kind of bad in the title like this guy. But like uh Mike Akens here was like a helicopter pilot and switched over to software engineering. So just like really cool stories. But that's where the live stream is now. And then the podcast episodes. Dev leader is my main YouTube channel. Put that in the chat. Put that on the Twitter chat. And um this is where I have all of my my programming tutorials now. So um this will be C. I'll have my AI programming tutorials and stuff. I figured like I need to layer in AI because if I'm not talking about how we build software with AI, the channel itself will just fall behind. But I don't want it to be like a it's not just going to be like AI tips and tricks. Like it's not the channel. It's still very much programming, but uh like I'm trying to layer in how I'm using tools to do certain things. And we got two backtoback thumbnails that look too similar. So that's nice and awkward. Don't pay attention to that. Um, that's me making YouTube faces. So, yeah, if you're interested in programming tutorials, check that out. And this channel will be solely that now. So, I think I've got all the other videos mostly cleaned up. Um, yeah, you can check that out. The other one, and I'm catching up on some resumeé reviews. This is called Dev Leader Path to Tech. This is where I do resume reviews and I'll have some other content on uh getting into the tech industry andor switching roles because this is another topic that I was covering in general like I covered on this live stream, right? Talked about that a lot, but the resume reviews in particular. Um I have a few more coming this week. I had to catch up. There's a lot of stuff going on. So, apologies that this is a little bit uh more delayed, but um yeah, I think I personally feel like for the people that were watching these videos, they were getting a lot of value out of them. I just don't think that my core audience of .NET developers was like, "Oh, great. A resume video." They're like, "I don't care. Where's the code?" Um so, whole channel dedicated towards it. And if you're interested in having your resume reviewed, just head to the channel. You can watch one of the videos that explains how to do it. And uh I'm a little bit behind, but I'm catching up. Okay, one more YouTube channel. I got a bunch of YouTube channels now. I guess that's what I do. I collect YouTube channels like Infinity Stones. Um we got Code Commute. So Code Commute I've already mentioned, but um just so you can see, right? Like most of the time I'm driving to from work or to from CrossFit and uh happy to try and answer questions that you submit. So, you can leave a question on any video you want. I've discovered that YouTube has been hiding comments for me. And I've seen this on LinkedIn, but I've never noticed it on YouTube. And I don't even get the notifications, but literally I noticed the other day it showed me in one spot there was a comment count of like one on a brand new video. And I was like, "Oh, it must be a a bug or something because there's no comment." And then I switched it from whatever the default is to newest first and there was like a totally valid comment from someone. I was like, "Oh my god." Like I've seen this happen before where there's like the comment counts aren't lining up and now I'm feeling like, "Oh crap, I've probably been missing people's questions and stuff and just didn't know." So, I if you're watching this, I sincerely apologize if you've left questions and um and I've just missed them. But that's what Code Commute is. It's a lot of fun for me. Uh it's like my my loweffort channel because I just get to talk about software engineering stuff. But I do have it available on Spotify as well. This was highly requested. I've almost caught up with the 300 plus videos. Um, I think I've done uploaded like 270 of them or something like that. There's a lot. Um, so we're catching up, but you can check that out if you don't want to just have YouTube open. Um, yeah, Devon, that's right. Top uh top comments uses some weird metric. I don't know what it is, but I didn't even know that was a thing on YouTube. I've seen it on LinkedIn, though. Uh if you want to submit questions on code commute and you don't just want to leave a comment because you're like hey my boss sucks and I want to tell you about my boss like just click this button and write whatever you want or if you're having challenges with a colleague or anything else like feel free to write anything you want here. I'll keep you anonymous and then that way when I get the email for it then I have more context to try and answer your question. I gain nothing from like trying to out people. It's just if you offer more context then I can do a better job answering your questions. So happy to try and help. Uh and then finally we'll just quickly talk about courses. Um I do have courses available in on dome train for C development and some general software engineering stuff as well. So if you're interested in that, the courses are the thing that helps my YouTube channel and content creation go. Um, I do not have a positive income from YouTube. Uh, the courses make up for that, which is great. Uh, but yeah, like basically if it weren't for courses, I would continue to go in the hole on YouTube, which kind of sucks. But courses, if you find the way that I talk through topics, uh, whether that's in the programming tutorials or the way that I navigate stuff like on streams like this, then basically you'll see a lot of that shine through in in these videos. Um, I'll mention, of course, that in these courses the videos are edited, so you're not seeing me like thinking like this or like, you know, I'm not like chilling. It's like they're a little bit more professional. Um, but the style of how I teach uh is is very similar. So, up for you to decide if you're interested in that. There's uh 30% discount just like last week. So, check that out. And uh I will wrap up everything by just briefly saying Brand Ghost is the uh the social media content posting platform that I built. Um I use this for posting all of my social media content. So if you're watching on Twitter, right, if you see my tweets, they come from Brand Ghost. And I do that so that I can scale my content creation. It means that when I'm having my busy on call weeks with work or I'm burnt out, I don't have to sit there and go, "Oh, what am I gonna post this week?" All of my content is perpetually scheduled forever. And when I have times where I'm inspired to go write some stuff or clip some videos, get some new memes for the weekend, I just upload them to Brand Ghost and it will continue to publish my content. If you are a small business and you don't have the time to go posting on social media, you know, you should be doing it, but you're like, "Oh, we got other stuff to do." Check out Brand Ghost. I'm happy to uh to kind of walk you through how you can leverage that for for building your brand as your business. And um I should mention there's a free tier as I'm losing my voice. Free crossing and there's unlimited accounts to do so. So, um, it's a lot more, uh, generous, I guess, than platforms like Buffer. So, check it out. I use this for all of my content. I need it to work. I'm very motivated for it to work well. It's got to succeed for me to succeed with content. So, that's how you know that I'm standing behind it because otherwise all of my content would fall apart. So, that's the stream for today, folks. Thank you so much for being here. I wanted to mention the other you I forgot. I'm so sorry. The other YouTube videos that I got coming this week. Um, one sec. Let me I just got to move some stuff around on my screen. Where where is my stuff? Um, where's my stuff? I because I don't know which videos will be out this week, but I can at least give you over the next little bit. So, one sec. Okay. Um, I mentioned the Code Opinion podcast. I'm going to have two more resumeé reviews coming out. I'll probably post those as soon as they're ready. The Derek podcast will be probably next week. Um, I do have a couple of videos coming out on Needler, which I have up here. So, needler is a dependency scanning sort of framework that I put together. I don't I don't want to make it sound like I invented something new and fascinating. It's just my approach to uh building plug-in systems. So, I made a Nougat package for it. You can download all the source code. So, I'm just using that as a a guide for showing people like how dependency injection works and stuff like that. So, um someone requested on that needler video, hey, can you like just show us how to build some stuff with it? So, we got videos like that coming out. There is one uh coming out that has a uh build a rag system. It's it's cool. I I had um I had AI build it. So, I had AI build it and then I put together a couple videos where I clean it up. I actually uh have a conversion video where I make it work with Needler. And on the stream last time, we did a coding exercise and I was trying to show how Needler can clean stuff up. In this one, it went from like 200 and something lines in the the entry point to like five. So, way better example. That's coming soon. And uh I think that's mostly it, but there's going to be some rag videos coming up. So we can look at semantic kernel. We can look at a few other things in terms of like vector databases and stuff like that. So I'll have some videos like that coming out. But I think that's it for real folks. So uh yeah, if you haven't checked out the other channels, please do if you're interested in those topics. If you're not, please don't subscribe to them. Like I split the channel so that people could focus on what they want to focus on. So, thank you so much for being here. I will hope to see you next weekend. I know it's a long weekend, but I'm going to be here Monday doing the same thing. Maybe we'll code. I don't know. We'll have to see. But we'll see you next time.