What AI Tools and Processes Would You Recommend For TPMs To Ramp Up?

Transcript is auto-generated and may contain errors.

Hey folks, we are going to LinkedIn messages for today's question. I have a sneaking suspicion this is written by AI and not a huge fan of that, but uh I think the question's interesting at least. So there's two. I'll make two videos. So the one after this will be the second question from this person. This reads, "As someone who builds solutions and guides others through complex systems, how do you balance hands-on execution with empowering your teams?" And for me, this one is kind of interesting because I go back to like um you know, one of the one of the ways that people talk about this is like how much as an engineering manager, how much do you code versus like manage teams? And um I I wanted to kind of step back from that a little bit and because the I think the the idea in general is that it it comes from a place of leadership no matter what for me.

So what I mean by that is currently at Microsoft I'm not really coding at work anymore. For the last like five years at Microsoft I don't code at work. I code every day outside of work. I love to program. That's not the point. Um but before Microsoft when I was at a startup I was coding most days. Uh so I worked there for eight years would code every day with my team until like towards the end. And I think that when teams are very small especially like in startup scenarios you have small teams like as an engineering manager it makes a lot of sense to be coding with your team. um simply the I I find at least and it's going to be different for everyone but given the scale of a team being smaller and the sort of scrainess of startups in general like

there's a lot of opportunity for you to still have a tremendous impact by writing code with your team and so I think that's important but when I say it comes from a place of leadership it's like especially in smaller scrappier companies and smaller teams like being able to work with the team to show them like, hey, look, like here's what we can accomplish if we all work together, right? So, it comes from a place of leadership, not a not a um I need to own this. I need to be the one to do it. I need to be the contributor here. Um I don't like I don't think there's a place for that really. And I think that um if you get stuck in that mindset as an engineering manager and try to scale what you're doing then then you become the bottleneck and then not only for like your team but also for your own growth.

So um I my philosophy on this is like if if I need to be the one writing code on my team or and this isn't specific this question is not specifically about code but like hands-on execution if I need to be the one doing it then I have an opportunity um to improve something on my team. So it is not that I will not do it and it's not that I don't want to do it. It's a signal for me from a team perspective. So to give you an example, I'm going to stay sort of in the sort of startup space. Um so by the time I left the company Magnet Forensics that I was at before Microsoft, I was managing two engineering teams and they were unrelated. And so my time that I had to contribute to hands-on stuff was less and less and less.

But it didn't mean that like if something came up that I would not go do it. It's just that like that became the exception. And I think that that's the natural progression because my responsibilities grew. I was managing multiple teams. Not only that, the other teams that weren't under my management, I was going and providing assistance a lot more as like a like almost like a consultant to those teams a lot more from like a strategy perspective. So my my role demanded other things of me and that's not like that's how I was scaling as an individual. That's how I was having greater impact and it meant that again like my time hands on delivering things uh was less and less and less but that was possible because you know the team had been empowered to do great work. Um, and sort of my my role in that hands-on part of that was completely replaceable, which I think is good.

Um, because again, that's how you scale. Uh, and I've I've made this comment before in different videos and different things I've written about, but like I feel like the ultimate sort of growth hack for yourself is like you make yourself replaceable, which sounds kind of backwards to what I think people think of from like a job security perspective, but if you're trying to have a an impact somewhere and you are the sort of like you need to exist there to do the thing to deliver the impact um, going forward then you're limited by that. Like you physically must be present for that thing to be successful. And I think that that is limiting. It sounds like it's a security thing, but it's limiting because now you can't go move on to the next thing to deliver more impact. So um I take the mindset that I must make myself obsolete and that means that by doing that I can deliver my impact.

I can create a sort of team or system around the things and move on to the next thing where I have impact. That's the only way that I can scale. So again, just to repeat, it's not a matter of like if there is something that needs help, you know, uh I need to jump in. I won't do it or don't want to. It's a signal for me that something could be better. The health of the team could be improved. I might have to look at how people are allocated to things. um could it's it's just a signal for me to go hm like what can we do to improve this and this extends to like what I'm doing at Microsoft right so like like I mentioned I'm not coding at Microsoft anymore or at all I it's weird to say anymore I never was coding

at Microsoft I mean coding anymore as an engineering manager in my role and um there's still stuff that I will do hands-on so I program a lot in C outside of work and I've been programming in C for many many many And we use C# at work. So if there's people, especially more junior engineers, if they're getting stuck on stuff, there's times even like senior principal engineers, they're talking through algorithms or they're like stuck debugging something, I will walk through code with them. I will get like handson in that sense. Not that I'm going to go build and develop the feature, but hey, like let's schedule more time. Pull up your pull up Visual Studio. Let's jump in. Let's go through code together. I will do that. But like that's where like I will jump into things to help if it makes sense. But that need I feel like that needs to be the exception, right?

If if most of my time if I find where people are like, "Oh, Nick, we need you for this. We need you to be hands-on doing this." Then I'm going like that does not scale like I I become a bottleneck on the team if you need me to be hands-on for all these things. So that again feedback that signal for me is to go hm what like what do we need to change or improve on the team like is it that we don't have domain expertise in this area is it that we are missing some historical context for this part of the code now and like that has to be built up I need someone more dedicated to that it could be many things right but um I'll keep saying it because I don't want the message to be uh confused is like if that

is not the except ception then there's an opportunity for me to improve things because I need to move in the direction of how do I obsolete myself that's how I scale so um the other thing that I wanted to talk about here is like part of this question was like empowering the teams right I want to make sure that people can work on stuff that is engaging for them that's interesting for them and I need to balance that with like like priority and like delivery speed as well I don't think long term term. It's a smart strategy to just like look for who is the best at something and give them the work that they are best at. That seems like a smart move like from an optimization of throughput, but I don't think that it's a long-term solution.

Um, and you might get lucky and you have people on the team where they're like, "Hell yeah, like I'm happy to keep doing the same things that I'm awesome at over and over and great, like lines up well." But I think that creates silos over time. So I think that there is still a balance where you don't want to create silos uh if you can avoid it but it's a tricky thing as an engineering manager finding opportunities for people to grow um in different skill sets different areas of code different domains their interests um that could be focusing on a weakness that could be focusing on just like something that they genuinely are interested in learning more about. How do you balance all of that with like with throughput? So, you know, in an ideal state, things aren't being rushed and everything's not on fire.

And I can say to people, hey, like um you know, you know that Jimmy is the subject matter expert in this area on the team, but like I know this is an area you want to work on. So, like um let's like, you know, we'll give this one to you. You can work through it and like, you know, as needed like consult with Jimmy because like you know, he has the background on this and he'd be very happy to help you and then I can help. This is great for many reasons. I can help create more subject matter experts on the team. I can get people engaged with stuff they're interested in. Like it's a it's a positive on all fronts except in the very short term it's a little bit slower. Um but I would rather lean into that because I think that long term that creates a healthier and healthier team.

So um basically I will try to do that as much as possible. And then the flip side of that is like when there are fires to put out, whether that's me jumping in to help, whether that's pulling in a subject matter expert and saying, "Hey, like, you know, um we have a critical thing that we got to fix and like you are the expert here. Like can we lean on you for this?" Uh and then I, you know, I can say like, "I'm happy to help. Let me know how to help. Like, do you need me to, you know, is it reviewing your code? Is it um is it brainstorming like algorithm changes with you? Is it uh researching different um tech choices? Is it um you need me to pull data for stuff like let me know how to help. I am here to help.

Um so it's just that my hands on looks a little bit different. And one more thing uh by the way I recorded this before and didn't have my mic on so I'm trying to do it from memory. Um, one more thing that I wanted to touch on too is like there is a very big difference between my role at Microsoft versus where I was and that's that at the digital forensics company I was there since like the beginning of it. So I had built or was part of building a lot of the code base. So for me to jump in and help was a lot easier um in terms of writing code because I'm like hey like I actually know that code because I wrote it or I was part of building it or whatever. very familiar even if I haven't touched it recently. Microsoft completely different, right?

I wrote none of the code. I was not there from the beginning. I am very very very late to the codebase. So how I contribute looks different for me to still add a benefit. Um you know if someone said like we need you to be contributing to the codebase um that's going to take me significantly longer to get to a point where I can be effective. And uh truthfully at this point um in this stage of my career that is I would consider that a step backwards. That's not how I scale. Um so yeah anyway that's how I look at balancing those things. I hope that that's a helpful interesting perspective. I don't know that's what the question was about. So uh a reminder if you want questions answered about software development or career stuff leave them below in the comments. You can go to codecommute.com.

You can submit stuff anonymously there. I also have several other YouTube channels. This is one of many. So, my main channel, Devleer, is where I have my car.net and AI programming tutorials. You can go check that out. And I have Dev Leader Path to Tech, which is where I do resume reviews. You can submit your resume to be reviewed for free. And I'll have some interview prep and help there as well. And then I have the Dev Leader podcast, which is software engineering interviews, so you can learn about people's career journeys. And then I also host a live stream there every Monday at 700 p.m. Pacific. So go ahead and check those out. If you check the description of my videos, I have the links to them and stuff. So, um, check it out. I'll see you in the next one, which is the followup to the question in this chat.

Take care.