3 Things I Wish I Knew Before Becoming An Engineering Manager

at this point in my career I've been managing engineering teams for about 12 years now and I wanted to share with you three things that I wish I knew before becoming an engineering manager hi my name is Nick centino and I'm a principal software engineering manager at Microsoft shortly after graduating from University I ended up starting work at a software company as a software engineer but not long after I was sort of tossed into managing engineering teams now at that point in time I had absolutely no idea what I was doing and of course 12 years later I'm still learning all sort s of things about software engineering management I'm hopeful that sharing these three things with you will give you some insights for things to think about if you're thinking about this kind of career path if that sounds interesting just a reminder to subscribe to the channel and check out that pin comment for my courses on dome train which include Career Development the first thing that I wish I knew was just how much peopling is involved with being a manager of course in a technical space like software engineering we think about code and software development and architecture and deploying changes and fixing bugs everything we're thinking about is super technical but becoming an engineering manager is so much more about people truly I think a lot of people underestimate this because I've seen many software Engineers that have gone into software engineering management and they end up struggling with this right there's a lot of these situations where someone has done well as a software engineer and the company that they're working at or the team that they're in the promotion path seems to be to put them as an engineering manager and then they end up struggling with it and it's because there's sets of skills and interests that don't really align with what they're into and one of those things is being involved with people heavily one of the reasons that this is so important for a software engineering manager is that we need to build a ton of trust and respect with our teams we do this because as we're trying to grow people in their careers if we don't have those two things it's really hard to have people be transparent with you it's hard to have difficult conversations and it's really just hard to get Effectiveness out of anyone now in order to build trust and respect that really means that you need to be listening to people you have to understand them you have to spend time with them you need to be able to demonstrate that you get what's going on and the things that they're going through if you're someone like me who is very introverted this takes a ton of energy and don't get me wrong I love talking with my team I love spending time with them I think it's one of the most important things that I can do with my job but it does take a lot of energy out of me and if I have days that are filled with conversations even with the people that I love working with I feel completely drained at the end of the day again that's not to say that I don't enjoy it or I don't see the value in it it's just how I am as a person it takes a ton of energy for me to do some people that are extroverted actually feel like they get energy out of doing this it's exciting for them and again I'm not saying that I don't like it but it's exciting for them in the sense that they feel energized by doing it for me that's just not the case so I need to make sure that I'm paying attention to this when I'm working with my team cuz I want to make sure that I'm giving them the opportunity to talk through things I want to build a Rel relationships with them but I need to keep that in mind that it is going to take a lot of energy for me I'm not exaggerating when I say this but if I have a full day of 101s with teammates there are times where I wrap up work and I literally need to go lie down and take a nap like that's how much energy it takes from me but ultimately I think that it's critical that I do this as an engineering manager because I've seen it done the complete opposite way where people end up not focusing on the people side of things from a management perspective and they strictly focus on the business don't get me wrong again cuz the business part is important but what I want to be able to share with you here is that when people hyperfocus on the business and not the people that are involved they end up optimizing for the short term so they end up finding ways to get Effectiveness and efficiency out of people in a short term but what happens is a lot of these people burn out they end up resenting their manager they find that they're not trusting them they don't have a lot of respect and it's because no one's really listening to them they're not being challenged to grow they're being sort of challenged in all of the wrong ways it's like how much you know output can you have ultimately that's going to lead people to want to leave cuz they don't feel valued instead if you focus on getting people engaged demonstrating to them that they are being effective that they have career growth all of these things that help an individual they are very motivated to do good work and that means that as an engineering manager if I need to get my team to Rally behind something they have built up that trust and respect for me and they'll say yep we understand that this isn't all the time we're happy to go make that happen and I would much rather that situation where everyone's growing everyone's getting what they need and when it comes down to it if the business needs a little bit more for a given time people will deliver and speaking of delivering I want to talk about Point number two that I wish I knew about before becoming an engineering manager and that's going to be your sense of accomplishment and what do I mean by sense of accomplishment well let's take for example as a softare engineer we're Building Systems you might be developing a feature deploying a service whatever it happens to be you're working through this project you get your code compiling you see it running in production or you have users using it and you get this sense of fulfillment like yes I did the thing I solved the problem I have shipped the software people are using it you get this fulfillment through the things that you're building as an engineering manager it looks a little bit different and that's because you are not the one building the things you are helping Empower others to build the things more effectively so you really need to think about things differently and I think that again this is a struggle for a lot of new engineering managers because what ends up happening is they're transitioning from this phase of their career where they are the ones handson building the things getting the stuff delivered they feel the sense of accomplishment through what they're doing and then when things change and they're managing a team that's doing this and a spoiler alert my third point that I want to bring up is a little bit more detail about this but because you're empowering your team to go build things it overall just looks different for what your goals are what does it feel like to go from I'm shipping all these features as part of my product or service to now all of a sudden I'm not shipping anything on my own and I'm trying to make sure that people on my team are shipping things effectively I'm trying to make sure that people on my team are growing I'm trying to make sure that people on my team are engaged it takes a little bit of time and for me it took many years and that's because I was doing software engineering and management in parallel for many years it took me a long time to realize not only do I get a sense of fillment out of helping people be effective helping people grow but it took me a long time to realize that that is truly the standard that I need to live up to in terms of being effective it's enabling other people that's what my goal is as an engineering manager it's no longer my goal to be the one shipping things personally this was around the 6 to 8 year mark that I started noticing this and my situation is a little bit unique there are some companies that are also like this but in my situation as an engineering manager I was writing code every day still for 8 years but towards the end of that period I was writing code less and less and that's because I was managing teams from the beginning of that 8year period and then the scope of influence and impact I was having towards the end of that was growing to a point where I just really didn't have time to go write code as much anymore and because this was a startup I was working a ton anyway like for 8 years I was sometimes working between like 8 to 16 hour days right like I was was just a workaholic around the clock but even then towards the end of that period I was so occupied with trying to do other things that weren't just writing code so that I could build influence across teams so that I could have larger impact that really I just couldn't write code anymore but fortunately for me around that time period I was also feeling a sense of fulfillment from doing this kind of work and it meant that taking a step back from writing the code and trying to help influence other things I was spending time trying to help people switch their career paths trying to teach them about being a software engineer if they were a tester or another role like this other type of impact I was having in other people's growth I started to realize that felt good and I started to realize that that was part of my job was enabling other people so it did take me a long time to really realize this and the third thing that I want to talk about because I've already hinted at it so far in this video is that as an engineering manager you don't get time to code I know that you've probably heard conflicting things on this you might even be at a company right now where you know your engineering manager coding you might even be an engineering manager saying Nick I code all the time that's bull crap but hear me out for a moment I say you don't get time to code and that's going to be based on the size of your team if you are an engineering manager with a very small team so this is possible at startups or startup like situations maybe you're at a big company but working on a small team that's very new working on a green field project odds are that you do have time to be coding and contributing and that's good because you want to be part of the group of people that's helping building up the base of the product or the service that you have so if you haven't built up a team of experienced Engineers yet guess what you're probably part of that group of experienced Engineers that has to go build that stuff but once you reach about five or six people you really will notice that you don't have time to code and if you feel like you do it's probably one of two things happening one is that you're working lots of extra hours and the second is that you're not actually spending enough time with your team both of these are tricky lessons so if you love to work and you're happy to work extra hours great as long as they spending time with your team but for a lot of new engineering managers they don't realize just how much time it takes to be spending with your team you need to consider that you should be doing weekly one-on ones with your team members if that's not enough to talk about career conversations and other growth opportunities you need to factor that in as well you need to factor in that there's going to be situations that come up and you need to navigate those on top of everything else things that you don't really plan for that you need to have conversations about there's so much extra coordination and conversations that happen on top of just the day-to-day writing code that truthfully you don't have a ton of time to be writing soft forare yourself please don't get it wrong I'm not trying to say that you don't have to know anything about code I I actually think that it's very beneficial that if you can remain technical as an engineering manager you'll have more success at least with your team and building respect or being able to jump in and help if you need to I think that it is helpful to be technical so don't misunderstand that but what I am saying is that people very much misunderstand how much time needs to be spent working with people and that means that you end up sacrificing how much time you spend writing code so those are the three things that I wish I learned before becoming an engineering manager at this point in my career at the time of recording this video I am a principal software engineering manager at Microsoft I don't write any code at work but I do work with my teams they write code in C which I am very happy to review with them because I code in C all of the time outside of work I still have a passion for coding that passion is totally revitalized because I don't feel like it's work anymore I can code the things that I want to be coding which is great it carries over very nicely into my day job I have to review and work with C++ code as well not my favorite but at least because I've remained technical I can still work through it and understand it and we have team members working in Rust as well that one's extra tricky for me and I think that I would need a lot more time to spend working with rust especially Hands-On to be able to do a better job with it so I am finding ways outside of work to try and remain technical and that's actually very exciting for me and at work it's very much still people Centric and coordinating on projects I hope that you found this helpful if you are considering a career as a software engineering manager it's extremely fulfilling to be able to help others grow in their career so thanks for watching and I'll see you next time