PITFALLS To Avoid: Senior Developer To Engineering Manager

Transcript is auto-generated and may contain errors.

all right it's Saturday January 11th I got a topic from Reddit which I think is a good one really like this one I actually went on to Reddit to respond to the person to write a bit of a a bit of a post and I let them know that I'll be sending this over to them I've done this with someone else now um and kind of wrote on Reddit like hey I'm going to send you this video that's going to be on YouTube uh and they were really happy about it which is cool um so I might do this a little bit more um I don't really like writing on Reddit because I find that that for whatever reason people are generally crappy on Reddit I don't know why that's the case topic today is about someone transitioning from a senior software engineering role they

said into like a tech lead slash engineering manager um I don't really know the like why the slash but I think part of what they're talking about is kind of like Engineering Management um in terms of the transition so they say senior software engineer for around 10 years uh they've been put for for promotion to Tech lead okay um but they say that by definition it's like leading two small teams uh and some people manage okay so it's like a technical manager role which is exactly what I did for eight years U before Microsoft so this would be the first time I for forly managed a team although I've air quotes managed uh interns and subcontractors before it's a bit weird for me because I hadn't held the senior title before this role so um it's not like they've been like senior uh at different

companies or something or different teams it sounds like so um impostor syndrome is starting to eat away at them yeah makes sense curious what other people's experience with moving from an IC role to Tech leadership have been how does it change your relationship with colleagues that's an interesting one what uh challenges do you face going into the role how does this vary between different organizations okay so um I wrote a few things but there's like million different directions to go on this one because it's literally the first eight years of my career so um I do have some experience on this one probably uh in terms of the topics of experience this is like the number one thing that I feel I can talk about to share perspective and experience on now doesn't mean that my perspective or experience is like you know uh the

universal truth or anything like that but this is just something that I've lived right so happy to to dive into a bunch of different things here couple reminders for folks if you want questions answered uh please just leave them in the comments I already know I have a couple today that I'm going to get to um I'm not commuting anywhere today which is why I'm sitting here but I have to film a ton of YouTube content so I figured I'm going to start things off get the I don't know get the can I say creative juices flowing I don't know that sounds kind of weird uh by doing a bit of code commute I guess uh so leave comments uh people have sent in some messages I got even more on linked even more on LinkedIn now I don't edit these so when I screw

up I just keep going um so I do appreciate that thanks for taking advantage of it and I'll say a quick note too um I did I don't know if I can hook it up on this channel at the same time but on my main Channel Dev leader um I had people that I had posted some memes online people were and it was a mug with some programming jokes on it so people were like hey I really want that and I was like I can probably sell that um so I did set up on my main Dev leader Channel um I connected it to the YouTube store or whatever there's some fun mugs I'll probably add a bunch more if I remember I'll put a link above here um but it's at st.dev leader.com might be you um you can check that out but uh

with that said let's kind of dive into some of the different aspects I just have it pulled up on my screen here so when I'm glancing over I'm just kind of looking at some of the notes I made uh this one's a bit of a cheat because I did uh write a couple things down um I'm not even sure where to necessarily start out I I want to go back to some of the things he said that I didn't make notes on so um how does it change your relationship with colleagues this one's interesting um when I I kind of moved from IC into manager role and it was a technical manager role like this person's describing uh I was still writing code on the team so you could imagine that it might create this weird dynamic where like your peer in terms of writing

code is also your manager so like what does that mean for code reviews like hm like you know are you going to go debate things on code reviews and you're like but that's my manager I guess I just have to like let them push their code through like kind of like you might be thinking that people are thinking this way um and they might so I think that this is worth actually kind of kind of having a conversation about and thinking through like what do those Dynamics start to look like um in my experience I don't think I ever really had that kind of thing happen but I think that just a kind of it's it's a weird balance but I think a lot of the strategy that I had in my transition to to managing people was when it came to actually writing code

um and I kind of take this philosophy with me still I try to make people feel like I am their peer now the end of the day if I'm managing them I am their manager um and if I have to sort of make executive decisions on things or veto things to move them along or whatever kind of call the final thing to make progress like I will do that if I have to stop conflicts I will interject and do that so there are things that make me sort of like not your peer but at the same time when it comes to regular interactions if we're talking about designing software I don't want to go into a meeting to discuss a software design and then have people feel like oh I guess Nick said so and like he's my manager so um so any I like

consciously try and create an environment where I'm letting people know that like my opinion is not especially like in designs or Co like I I want these things to be driven by the team so I need to demonst rate that there will be times where I'm putting my input forward I want to make sure that other people's voices are heard so some things I try to do in this case to balance that out so that it's not like oh crap manager says so um you know making sure that new people on the team so if we're in uh you know we're having a discussion about the path to move forward on something might have senior Engineers discussing things but if I want to include Junior engineers and I'll even try to get them to kind of voice their opinion and make sure that like we're

demonstrating that anyone can be putting thoughts forward right it's not it's not a conversation for only the highest level engineers and it doesn't matter anyway because the manager is going to veto it it's like these discussions are meant for a team to have now the more senior people on the team may have more experience on certain things they may understand and be able to analyze things better and ultimately come up with like a a final decision more effectively but that doesn't mean that we shouldn't be listening to other people on the team so um like I said I personally haven't really run into problems like this but I have I feel like I've spent a lot of effort trying to create a dynamic like that where um when we're going into like the technical aspects right in terms of write the actual writing of software

I want to make sure that people see me as a peer in that regard um where like if you're also contributing to the um like your Sprint objectives if you're doing some type of agile or whatever you want to call what you're doing if you have some commitments whatever system you're using um this one can get kind of spicy because I think a lot of people don't realize especially going from an IC into a manager position and then when you have this hybrid technical manager role the people management side of things or like the people aspect of management takes up so much more time than you could possibly imagine and what I would say is if you find that it's not it's because you're not investing the time into the people and this person is going to be managing two teams it sounds like um

for in my case probably mean leading two small teams yeah so like that's what I was doing uh before moving over to Microsoft was managing two small teams um like PE people take a lot of time there's career discussions there's going to be things that you'll want to be kind of working through with individuals on the team that you might not as an individual contributor ever have seen before had conversations about there may be people on the team that are having challenges outside of work and it's really difficult for them to focus because they have family issues or like personal issues that are going on like these are conversations that end up coming up and you want to make sure as a manager that you're helping team do their best work possible so like there are all sorts of things and you have interpersonal challenges

on the teams maybe people don't work well together and you haven't really picked up on it maybe you have picked up on it before and now guess what you're managing the team that's something that you're going to have to try and help course correct and of course you want to empower people on the team having those challenges to try and work together to solve them right so it's not just like okay now I'm the boss you guys can't fight anymore like you want to be able to coach people through that so um definitely takes up a lot more time I think probably this is not really the same thing but probably the only sort of weird thing that I encountered in this regard was like when I moved into that kind of position it wasn't just colleagues but it was like older colleagues um and

like when I say older I don't just mean like purely by age I I realize that's what older means but also like just by years of experience in the field so um I basically went into being an individual contributor and manager at the same time but managing someone on my team that had been like in industry for many years before me so you can imagine that's probably a weird dynamic right you can imagine when this person is talking about impostor syndrome I was literally an imposter because I had never managed before it's not even impostor syndrome for me at that time literally an impostor how do I manage a team I don't know so I was truly and I'm kind of saying this in a like trying to be a little bit funny about it but like realistically I've never done it before the first

little bit I would have been an impostor but I tried to make sure that I was I don't know like investing time into becoming a better manager uh it's it's a really weird thing to navigate but that's I I mentioned this some previous videos that's why I created Dev leader in the first place in 2013 was because I was like hey you know what like I need to do a better job of like of actually learning about management things so that was a step I took to like go and learn and public and try to just be like how do we how do I become a better manager um so that was an interesting Dynamic but I think like with a lot of this stuff it comes to just like building trust and respect right um You don't respect is not something that you like

command of people so it's not hey look I'm the manager therefore respect me this is something that you earn and you earn it by building trust with people and then demonstrating to them that you're accountable to the things that you're saying you're taking responsibility and over time that makes people respect you for the things that you're doing so U both of those things go hand inand and what I would say is if you have individuals on your team that have been your peers and you're like I haven't really like like okay there's like Joe and Bobby on the team I always work with and like Sally definitely a lot but like there's like Tim and Steve like don't really work with them much like you know I know them but like I'm not like actively working in the same things as them all the time

for a couple years um like at this point now that you're going to be managing them in terms of improving those working relationships building the trust building the respect that's going to be something you got to spend time on the reality is there's no like like I don't know like a stepbystep like cheat guide for three easy steps for making everyone trust and respect you it's going to be individual it's going to take time and I think the shortcut if there is one is accepting that you're going to have to take the time and put in the effort to do that so um I would say that about the relationships with colleagues something to think about um challenges that you face going to the role that's a lot of what I wrote about so I will go back to that and how does this vary

between different organizations I would say just on that note I want to spend time on the challenges but how does this vary between organizations this role in particular is a unique one the sort of technical manager one I would say this is probably more common at smaller companies or at least with small teams or new newish kind of teams and that's because if you're taking someone who is a strong engineer in this person's case senior engineer for around like 10 years of experience okay Pro like let's we don't know the person let's assume strong engineer um especially if they're being put up for this kind of promotion um the reality is that when a with a manager role like kind kind of like I was hinting at you spend so much more time on people and not as much time writing code it's really difficult

for organizations that have really strong Engineers to kind of like lose that um what's the like the throughput or the sort of the the deliver the ability to deliver by that senior engineer right like hey this person's really good they're really productive that's awesome and like now let's just make them not write code and you're like but they were so good at it like what are we going to do um so in some cases I think that it can be a very smart move uh either as an organization or even from a transition into an em roll kind of thing to keep some of that Hands-On stuff the the the big kind of challenge here is like these things compete with each other and it's just the reality of the work so um I think some organizations will say like I've heard you know even

when I was looking at jobs when I was uh going between magnet forensics and Microsoft it was like some some places were saying like we expect our our managers to be technical makes sense some were saying we expect our managers to code uh in my opinion that's something that doesn't scale I've I spent the eight years doing that uh I code every day outside of work I love to code but in my opinion growing in as growing as an engineering manager means that you're spending less time writing code and for me going into like I didn't apply to positions that said engineering managers will be expected to write code like as a daily thing and that's because in my opinion that is not growing in the role that I want to be in I've talked about this before but like I've been a I technically

I've never been promoted in my entire career which is very interesting um and that's mostly because like in startup land it's like we didn't really even have like levels to do it so I've end I've been a like a a middle manager my entire career which is super weird right I had two two years of internships so six internships four months each intern software developer started at Magnet forensics was an engineer and then very shortly after that was put into a technical manager role but I've been an engineering manager for like 12 and a half years now so that's a really weird spot to be in and growing as an engineering manager in like that sort of career path you move on from managing uh individual contributors to managing other engineering managers so Microsoft the term for that like a group engineering manager so manager

of managers some places they call like a senior engineering manager but the point is like it's the same it's an it's going to be a bit of a segue here but that type of transition as an engineering manager into a manager of managers is also like an impact multiplier so as an individual contributor and by the way I want to be and if you're new here like uh I should probably clarify this stuff more right but I I never want when I describe different roles and things like that um I never want you to get the feeling that I'm trying to say something like oh an engineer is like a subordinate role to a manager or like a product manager or project manager subordinate one of these things is better I've I've had conversations like this with testers and things like that my I I

don't want you to hear words I'm saying and say oh well Nick must think that one of these is like better or worse they are just completely different career tracks I just want to be very clear about that um many many places are doing a much better job of having career tracks for individual contributors that also like allow you to grow like to very top level um some places I think historically kind of have that like capping out a little bit and then all of a sudden like you don't really have a choice but to move into like managing people um but the reality is like in in either case your impact your scope of impact is growing and your circle of influence is GR growing too so the idea being that when you're going to be going from an individual contributor the the influence

you're having is going to be the sorry the impact you're having is going to be on the work that you're doing or the projects that you're leading and then sort of your ability to multiply the effectiveness of your peers right so this is why like many Ming or like informal leadership is very valuable because you can start to be a multiplier for people on your team but that multiplier effect is almost like this is kind of just my perspective on it it's almost like held back by the fact that you have individual contributor responsibilities you can't spend as much time on that multiplier effect because you're spending time actually still delivering code and there's nothing wrong with that it's just that your ability to scale that effect is is more limited so as an engineering manager and this is like the transition that I had

to have and it I said this in a previous few videos it took me like seven years to realize like oh I actually am starting to have a bigger impact through that multiplier effect and taking my hands out of the code more took me a very long time part of that is I think because uh I don't think this is like a it's it's a weird kind of thing to say because it just feels awkward but like I'm a pretty strong programmer I I love to code so I spend a ton of time writing code and then I was also put in these situations where I could deliver things and get very good feedback for doing it so this like feedback loop was like keeping me constantly doing it when you kind of take that next step right so now you're a manager you're if

you're spending more time on the people and less time writing code your ability to expand that multiplier effect is greater and that's why I was saying when you kind of move from mid-level manager to um you know group engineering manager or senior manager manager of managers now your multiplier effect is hopefully multiplying the multiplier effect of other engineering managers meta math um but that's you know conceptually what's going on there so the I think yeah different organizations some places I know that was a bit of a tangent some places won't even have technical manager roles right so like right now at Microsoft I don't code I haven't written code I mean aside from like querying data or something to do analysis I haven't contributed code to the code base at Microsoft in the five years that I've been or almost five years I've been here

so four and a half years um but I mean even like the work the projects that I'm on right now it's not like my manager would be like no you're not allowed to I'm sure he would be like hey if you want to go ahead but my my perspective on this stuff is like if I feel that I need to what am I not solving with my team because this is my opinion a common trap if we start to go look at some of the challenges I think a common trap that people have going from an IC role into a manager role is because they are so used to being a strong developer and being like there's a lot of problems that I'm very comfortable solving I've been kind of the senior person on this team I know the co based like I'm very comfortable

I've been helping people maybe the team is very Junior like hey like uh we need we need more throughput and you're like okay well how do I get the team motivated to do this and what okay well if I just do more if I just code more like we can we can still solve this and like you're not wrong in saying that but it's a bit of a vicious cycle and in my opinion it's kind of using your I see comfort as a crutch in management and to be clear I'm not saying because it's impossible to say stuff on the internet with people like going oh what the hell are you saying um it's always going to trigger someone right so I like to try and be careful about this stuff I'm not saying that being technical is not good I'm not saying that a

manager being able to contribute to the code base is not good like totally It's not that it's the fact that if you were trying to use your own developer experience to solve other problems in the team that are probably like a team scaling issue or an engagement issue or perhaps issues with individuals on the team like there are a lot of ways that you could approach those challenges as a manager to improve them and if you're not experienced in doing it what are you going to lean on the stuff you know right so um that's I'm just trying to be clear about that it's not like you know you're a terrible person if you do it but it's a it's a common trap I see I did this for forever right this is why I was saying it took me a long time that I

could start to it's almost like looking at the patterns that I was doing okay so we got to we got to pick up the pace on something or uh we're having challenges in this area of code we're going to have to refactor we need to do more tests like oh no like how do we trust people on the team to do this I don't really have famili with it but ien to know it really well like I can go Crank that out like when you start to look at the things that you're trying to pick up the slack for and like like I said it took me a long time to realize this and maybe it maybe it probably takes you know a significant time for for a lot of people to pick up on these patterns but like how can you teach other people

to be doing those things you might have to fight the fires for a while but if you're just doing that and not reflecting and going okay I just fought this fire why did I have to do that as the manager on the team like why did I have to go into the code base and do it not that it's wrong but why did I have to do that as a manager okay well we don't have enough experienced people on the team in that area okay so what can we be doing about that right do I do I need to try and carve out more time for some of the senior people to look in that um is this part of the code base that maybe we should be retiring like there's a a million directions we can go on that um I'm there's just so

many things where you can say like if I had to go jump in to solve this why is it that I'm doing that right so I'm trying to think of these on the fly so um you know you have a tight deadline except you always have a tight deadline and we're always trying to scramble for releases okay maybe maybe we need more headcount maybe we need to have better conversations with our product owners about uh the capacity that we have like maybe we need more clear Sprint B boundaries retrospectives to like identify these gaps and stuff like again so many things to go look at but as an engineering manager you're leading the team now you should be trying to go look at those things and empowering the team to kind of raise awareness to them so that ultimately we don't fall back to the

crutch which is like let me just go code it not that it's wrong to code stuff but if you're not sort of growing these other skills surpris these are the new expectations as an engineering manager these are things that you're going to need to get better at to excel in your role because guess what your role is different now okay um something else uh that I said was kind of challenging was like um I think it's really hard it's related to this stuff but I think that some people struggle with the fact that your success in your role as an engineering manager is not any longer just going to be your uh technical contributions right in this person's case there's still uh a technical manager they're calling it a tech lead a technical manager um they still have to contribute to the code base and

do technical things so that is going to be part of their success for sure and again this is why I said this is why I got kind of Trapped in that position where I'm like I don't know if I want to be a man like a fullon manager versus like still keeping my my technical technical contributions is like when you are a full manager or even just the manager portion of your role your success in that part is not just your individual contributions it's the success of the team right how are you enabling people on the team and it's a really weird thing because let's say that there's people on the team and they're their ones responsible for some project but you're managing them you're leading them you're helping them navigate challenges getting them on blocked and stuff but you're not like actually writing the

code when that project finishes I think for a lot of people like for me especially even to this day I still have this kind of feeling where I'm like yeah but I didn't do it like it was them like and it this is actually like a visibility problem too when I have to talk about myself and my accomplishments so like I'm 12 years into this and it's still kind of like a weird thing for me so you have other people doing the work but it's not like you didn't have a role to play so I think that sometimes people can struggle with this where it's like what what value am I actually adding but it's like if you're doing your job well and you're keeping people unblocked you're keeping them engaged you're keeping things moving like there's a lot of project coordination and stuff like

that you're aligning the work that people are doing not only with the business but their career goals like you are doing a lot it just isn't the same sort of metric that you're looking at that you're used to for individual contra contribution so I think for some people the reason I'm saying this is a weird challenge is that some people go oh well that clearly like that's not my normal success metric so I should focus on this other stuff so uh if you're ever feeling that way it's just this is hopefully a good reminder like success of your team is your success uh and make sure as always you'll hear me say this on nearly every video have conversations with your manager about expectations okay so please do that um I already kind of mentioned that like a common thing that some people don't realize

is like just how much time is spent with like people things so for example if you're leading Pro and I think sometimes people that are senior Engineers or have been tech leads moving into a manager position they have some exposure to this but uh I I always kind it's like half joking but like you know the biggest problems in software engineering are people not technical problems and it's because software Engineers are very good at solving extremely complicated problems but we have a lot of challenges with getting alignment agreeing on things taking different perspectives and bringing them together so it's like a superpower when you're able to do that but you will notice if you haven't already that a lot of this stuff will stand out more it's like why can't we make progress on this project whether that's internally on the team or with other

teams and a lot of the time it's just like people challenges communication challenges like so this stuff will become more and more apparent um I talked about spending time with helping others to grow in their career so um one of my biggest missteps early in my career was like I I got very lucky that I had like really strong Engineers on my team so in my head I was like well they're already doing awesome like what the hell am I supposed to say to them hey man keep doing a good job like you're like you're already doing good what do you want me to tell you and um that's a huge Miss so just a reminder right if you're new to this kind of thing and you're going from an IC into a manager role like even when you have really good people you still

want to find ways to make sure that they're engaged in their work that they're finding challenges that they're able to learn things that they have a career uh path forward they understand that right because just because they're doing awesome doesn't mean that they also don't want to grow or they don't want to have challenges or that their work life balance or the focus of the work they're doing couldn't be more optimal so like figure that out I think a lot of people when they go into management they they kind of fear this like oh man like there's going to be someone that's a low performer or something and I'm going to have to have a difficult conversation and don't get me wrong those conversations suck they suck but the reality is like it's way more understandable it's way more straightforward to navigate for example someone

has they're very motivated but they have a skill issue okay like the the sort of issue has been identified so now let's come up with the plan and this will be situational but let's come up with a plan for them to work on it right or you have someone that has uh some interpersonal challenges okay like the challenge been identified if it's a communication thing let's talk through that come up with the plan you work on that but my point with all of this is to say when the challenges identified you you can probably come up with the plan and at least make progress forward when you have people that are just doing awesome what's the challenge it's not it doesn't feel obvious I think to many people certainly not to me in the beginning so my my meta point there is just to say

like even with really good um engineer on your team like you still want to make sure you're spending time to help them grow keep them engaged um this is uh I kind of said it a little bit throughout this but um definitely it's worth repeating like situational leadership is like your best friend trying to take a cookie cutter and like use the same approach for everyone on the team and this isn't about being like unfair or like treating people differently and you know picking favorites and stuff but I mean like everyone's motivated by different things has different strengths weaknesses challenges like you have to go approach leading people with the expectation that everyone is an individual they will have different needs different challenges and if you try to take the exact same thing and go well it worked for Timmy it's got to work for

Susan no it doesn't like Susan is different than Timmy so it may not work um so drop the idea of cookie cutters you might use your like a common framework or something but having you know having the impression that something that worked for one person must work on another and then when it doesn't you get like frustrated by it or now now it's this other person's problem because they're not fitting into it no like it's situational all of it so keep that in mind um meetings uh I think some people freak out about this because I know as software developers you're probably pulled into tons of meetings anyway and then you can't code and then it's un effective um as a manager you're going to be in a lot of meetings and that's sort of a reality when I say meetings I'm I'm talking about

like all like basically all flavors of meetings like if you think about it the very simple one that you're going to be spending more time doing is 101s you probably had 101's with your manager right on a regular basis maybe you had one-on ones with your skip level manager like infrequently but still often and then perhaps a couple of people on the team or across different teams just to make sure you're in sync you know the stuff you're working on is important because it's like for both of you to to have Insight on what's going on maybe you're kind of helping out with some Juniors on the team and then giving them that opportunity like some mentorship but now you have 101's with every team member and up to you and them to decide on a Cadence but like when you have weekly one-on ones

with 11 people and they're half an hour each and you need some buffer in between how much time is that just in one-on ones it's a lot of time so the amount of time you spend in meetings has greatly increased the the fact that you're going to be helping individuals on your team lead projects there's going to be multiple projects going on that means there's probably going to be different syncup meetings for those projects to talk through different stuff like the number of meetings explodes now that's not to say that we can't do better or like this is the end of the world what this means is that your time management needs to get better so that means if you're being pulled into meetings and Like There's No Agenda you better ask what the agenda is if you don't know why you're supposed to be

there ask for clarification because if you don't need to be there get out because your time is going to be extremely limited extremely you're going to find that you're in these situations where like the only time slot that isn't triple booked is like over here but like that spot is like where you have a oneon-one with someone and now you're like okay this critical project has to get done we got to have this meeting but like I have to cancel my one one with Sarah and what does that mean to Sarah what what kind of message is that giving Sarah that she's not important so by the way in that situation what I would probably do is have a conversation with Sarah and say hey can we move this either earlier or to the next day right to the next time slot that's available because

if this is the only slot that could ever work for everyone on this project we don't really have much of a choice but I don't want to miss our oneon-one so there's ways to do this but the point is that when you keep doing this to people they're kind of like I guess someone doesn't care about me got to be careful about this stuff um and again situational leadership some people might not give a at all they're like whatever it's it's our 101 we do this every week it's cool move it to tomorrow cancel it this week fine other people will go my manager hates me they don't care about anything I have to do I don't even know why I'm here people will go all sorts of different directions on it so it's uh it's it's just weird because sometimes I don't think people

have to think about this stuff a lot and now it's going to be a lot of what you're doing um one of the final things I wrote down here was like um and obviously for this person and probably many people that find themselves going from like a an individual contributor promoted into like a manager position I wrote down lead by example but you're probably already doing it right the fact is that if you're operating at that level where people want to promote you into a manager position you're probably doing a very good job that way so this is a two-parter it was like kind of like hey just a reminder like leading by example is extremely important good news is you probably do it well but just a reminder second part though is like because it's so important what would be especially helpful is now

you are teaching other people to lead by example cuz it worked for you right you able to demonstrate your abilities that's why you are promoted into this position you want to make sure that other really strong Engineers on the team are leading by example so that other people on the team especially the Juniors can emulate that behavior I don't think people realize sort of the influence that has on more junior members of the team because they are constantly looking up to the more senior Engineers because they're saying like though that they're senior they're in that position for a reason if I want to be there someday what behaviors are they doing sometimes it's not consciously either sometimes it's totally subconsciously so you want to be making sure that you're helping influence the culture in a very positive way we don't get to dictate the culture

of our teams just because the you're the manager doesn't mean you get a piece of paper out and you say our culture is and you list a bunch of points culture doesn't work that way culture is the byproduct it's like the the symptom of what's going on in the team so if you can help the strong Engineers on your team demonstrate really good qualities lead by example so that other people are emulating those behaviors the byproduct of that is hopefully moving the ulture in the direction you'd like to see it go right so just a really simple example and just kind of making this up it's whatever um code review culture right like okay we got these code reviews up but no one's they sit open for like a week no one's reviewing them cool okay like let's try to make sure that you have

you have someone on the team that's really proactive with them great like get them to demonstrate that talk about it celebrate it when it's happening right make these things visible to people on the team encourage the other SE the people that you're now leading like hey encourage them like hey such a good job you did that you should do it more right like you're really helping the team by doing that and like um when you're coaching some of the other people on the team maybe you should bring that up with them too kind of show to them like how that's helping the whole team be more productive again I'm just making this up as a quick one on the spot but my point is like this is part of what you do now maybe not specifically with this example but I hope you get what

I mean where it's like you're trying to help Empower like the strong Engineers on the team to be demonstrating this stuff okay so that's what I would recommend um I kind of wanted to just like finish this part off by saying like I think this is like a I did a YouTube video on this on dev leader I'll probably forget to link it above but if you want to watch it it's a pretty recent one on my Dev leader Channel and it's basically like Engineering Management is not for everyone I think I based it on a code commute entry already so you might have seen that on code commute but um Engineering Management is definitely not for everyone that's not a gatekeeping statement that's like you just may not enjoy it at all and that's totally fine that's why I said earlier being a manager

is not like better than being a product manager project manager tester programmer it's a different role so it's not about being better or worse it just might not be something that you love doing especially when you go from Individual computer individual computer individual contributor to a technical manager you're going to start to feel that your time in the code is less that may not be something you like when you move to being a non-tech like a non-technical manager as in you're just not you know responsible for individual contributions what's that going to feel like right like how how much do you love that part of your job for me I love that part a lot but I don't need to do it at work so I do it outside of work and that's a good balance for me if someone said to me Nick you

aren't allowed to code anything outside of work I don't know how that would ever happen but like your computer doesn't work for code outside of work and they say could you be a manager I don't know because I love to code so I think these are things that you need to figure out for yourself but um I did want to say like if you like so for this person which I'll be sending this video to I wanted to say congratulations on the opportunity if you're finding yourself in this sort of transition phase congratulations it's a it's a journey for sure um this is sounds kind of funny but like this is the journey that I have been on for the past 12 years and um it's hard but like I don't I don't know I don't think I would trade like that opportunity because I

got to feel very fulfilled from doing it so um I feel very fortunate so anyway congratulations to folks that are on that path if you're if you kind of heard what I was saying you're like that sounds like I don't want to do that don't worry don't do it it's not for everyone you may not like and that's totally cool if you can double down on the technical side you want to focus on like architecture and stuff that's a super cool path to go down there's lots of options management is not the only one but it's definitely an interesting one so I hope that you found that perspective helpful and uh just a reminder if you have any questions you want answered comments or send a message to Dev leader on social media and I'll see you next time