What The Heck Does a Principal Engineering Manager Do?

Transcript is auto-generated and may contain errors.

Hey folks, my eyes all screwed up, so I'm going to wear this stupid patch while I record this video and all the videos today. Hopefully, it's better tomorrow. Um, it just looks gross. So, I'm going to go to LinkedIn for a question. This one's kind of interesting. I I don't don't think I realized that people had questions about this. So, um, this person had said, um, that I I mentioned in my videos here on Code Commute that uh, my goal is to be a manager of managers. Um but also I mentioned that my role is a principal engineering manager. So they were like hold on um what does this all mean? Um because they said they haven't heard of a place uh with a principal engineering manager and their assumption based on like the the role and the level sounds like it would be a manager of managers.

So they just said it might be kind of interesting to talk through that and like um they said might also be interesting just to talk about your role and what it means etc. So happy to to talk through this. I think it's a cool idea. Um, buckle up. No, I'll keep it I think relatively quick, but um, yeah, let's let's start, I guess. Right. So, um, I work at Microsoft as a principal engineering manager in the Office 365 or Microsoft 365 side of the organization. So, I don't work in Azure. Uh, I work literally like in the um the platform teams that support all of the services for the the Microsoft 365 suite of products like all of the the cloud products, right?

you wanted to go access Outlook online to go check your mail at work or whatever you're using um you know office products online and your information's stored you know a Microsoft you have mailboxes at Microsoft that's all flowing through our our platform um so there is there are many teams that make up uh the platform side of things for that and then there's all of these service teams that build products and services on top of that as well. So what I'm trying to explain in this and you know the rest of the video is that I can't actually comment on the Azure side of things because I don't work there and I wanted to to explain that like even the titling and stuff can be super confusing out or like within Microsoft. Here's what I mean. If you went to levels FYI, I'm pointing at my my monitor behind me because I have it pulled up.

Levels FYI, if you're not familiar with that website, if you're trying to compare salaries for different places, they give you uh I feel like a pretty accurate representation of what the stuff looks like. If you look at the engineering manager role and then you look at Microsoft and compare it with other companies, um they have like level 64 and Microsoft uh role or like level numbers like are kind of weird, but uh level 64 is the first level of engineering manager that it shows at Microsoft, but that's not even true in the Office 365 side of the organization. It's just not. and it's called senior manager is level 64. Senior manager at many other places refers to a senior of managers if that makes sense. It's not like you are a senior person and you are a manager. It is your senior within the manager role.

So a senior manager is usually like an L2 manager which means that you are a manager of managers. That's literally not the case here because senior manager at level 64 is the very first level of manager apparently. So I'm assuming that's more of an Azure concept. Principal engineering manager um is level 65. So to answer this person's question very directly, principal in this case literally just refers to the level the numeric level. So 65 is principal band at Microsoft. So 59 would be when you join Microsoft as a you know junior developer new hireer kind of thing fresh out of school that kind of idea like you're junior 59 59 and 60 are that band then 61 um 62 are sort of midle 63 64 senior 65 um through to 67 is principal and then there's partner after that I think partner is either 68 or 69, I can't remember, but I'm not there.

So, I'm not not looking at that part yet. But, um, principal is 65. So, I am a currently, this thing's falling off my face now. I'm currently a level 66 principal engineering manager. But the principal part just refers to the numeric value of the level. So, if you read on level, back to why this is confusing. If you read on levels FYI, it says principal engineering manager at level 65. And then the subtitle says principal director of engineering. Again, director at many places is at least an L2 manager. Sometimes it's even uh like L2 or above. So sometimes it's even above like a senior manager that might have like director above that. Like I'm looking at Amazon. They have software dev manager, software dev manager, senior soft uh software dev manager, then director. Like they have it level broken out. Um at I just have Salesforce pulled up here.

This is what it did for me. Uh manager, senior manager, director, senior director. Right. So they put director usually above senior manager. That's what levels FYI shows for Microsoft is a senior manager, principal, director of engineering, then senior director. But but that's not like in the Office 365 side of things, that's not how the titles work at all. Um so the earliest level that you can be an engineering manager in the Office 365 side of things is a principal. So 65, not 64. So on levels FYI that's why I said I'm assuming this is Azure I don't know but 65 is the first level that you are allowed to be an engineering manager in office 365. So it's kind of confusing because if I say I am principal level 65 engineering manager that is the function that I have I am at the the sort of entry level of engineering manager in the org.

Now I'm level 66, so I'm, you know, sort of one level above that. But, um, yeah, that that's probably confusing, but hopefully explains a little bit about the the naming and the the leveling and and all of that stuff. So, um, yeah, my my role currently is not to manage other managers. It is to manage IC's. I don't know. I I suspect level 66 Uh maybe 67 is the first level for it. Uh at Microsoft, I'm not sure if it's 66 or 67. I might technically be able to manage managers at 66. Um or I don't know if they've restrict like if they restricted at 65 that you can't. I don't I don't know. But there's no um there's no like requirement in my org for that. I'm saying that backwards. There's no need for it. Requirement I don't know. But there's no need like I don't we're not hiring another manager to put under me kind of thing.

Like it just wouldn't make sense. So I don't have such an opportunity to go do that because there is no need in our org to go do that. So it's kind of like maybe at 66 now I I'm c like capable or qualified from Microsoft's perspective to be able to do it, but there's no there's no need um set a different way. There might I'm just making this up. I actually don't know. Um maybe if there was another team in Office 365 that was looking for um a manager of managers, maybe I would be qualified based on my level 66. I I don't know. Um I just know that that opportunity has not even come up for me. So um I don't know if I I think that's kind of answering what's going on. So in terms of like like what am I what do I actually do?

What's my responsibility? Um there are there are some managers especially ones that have been uh that were software developers especially in the team that they were on who went from um say principal engineer to principal engineering manager. Again that might sound like a promotion. That's that's a role change. You're if you were 65 as a principal engineer and you're 65 as an engineering manager. That's not that's not a promotion. That's that's literally a role change. Um I don't know if some people have gone from senior engineer like a level 64 into a 65 principal engineering manager. I don't want to say that's never happened, but like that would be kind of confusing cuz it's a promotion and a role change. Like that feels a little weird. You're promoting someone into something that they haven't done before. Kind of awkward, but I can't say it's never happened.

I don't know. But um my my role as an engineering manager currently is not to manage other managers. It is to manage individual contributors. Um again just to reiterate the principal part of my title just comes from my level. So currently it's 66. Um and 65 is the the first level where you can be principal. So I manage individual contributors. So what are my responsibilities when I say that's what I do? So, I should back up because I went on a slight tangent. The some like some of the managers that have been promoted as from developers on the team, they might find that they're still writing some code and if they have smaller teams, it probably makes a lot of sense, right?

If you have a team of three, four, five people and you were an engineer on the team and you're you're sort of put into an engineering manager role, the the likelihood that you um you know don't have time to write code anymore is probably uh probably pretty low because you were probably already doing it. It's just that like you're taking on that new sort of responsibility. So um I don't know. I I would say like if your if your team is rapidly growing, maybe not because you have to go spend more time hiring and and that kind of thing. So you're put into an engineering manager role and that's like the new responsibilities are consuming a lot of your time. But I would say for really small teams, um you probably still have time to code. Um I manage over uh different points in time like between 10 to not more than 15 people right now, but 10 to 15.

So I manage like basically within one team but like three call them feature crews. So it's like three sub teams. So um I don't have time to code. There's like there's seemingly not enough time in the day to do the other things. Uh but I don't have time to to code in my role without giving up other things that I am responsible for. So if that changed if you know if my manager my skip or whoever um was like hey new expectations of managers are you need to be delivering code I would be having a conversation around well what else is not going to get done and like that's what it would need to be because there isn't sufficient time for it. So for just as an example, uh I have a responsibility to work with my product managers for planning around this time of year.

There's a lot of planning that's going on. So that might be a conversation if they were like, hey, engineering managers are all expected to be delivering code now, new expectations. What I would say is, okay, you know, here's the other things I'm responsible for. Um, so if you genuinely don't think that I should be spending time with people on their careers or side conversations to make sure that they're being effective at work, like if you don't think that that's where I should be spending time, I think it is, but if you don't agree, then I can carve some time out from that. If you don't think I should be spending as much time on planning and I can sort of defer more to the product managers to, you know, organize that, like, okay, I'll spend less time on that, but something has to give, right? I have on call shifts since June.

I've been on call for 3 months which is more than should be. Um so okay like you know that's a huge chunk of my time should I not be doing that right so something would have to give my current role I do not have time uh during the workday to be coding uh for my day job so I don't um I do planning work so that works in a couple ways that's regular planning so uh week-by-eek basis when we're doing our feature crew syncs what does that look like So people are reporting progress on things. We're talking about what's blocked, what's not. Um there's always a ton of moving parts in software. So we might have partners that are behind on things. We might have priority changes. So I'm working with the team to be able to navigate that. And basically there's a lot of time spent rep prioritizing things.

In an ideal world, that priority list is not changing that often. Uh ideally it would just be like you know new exciting opportunities and then we can say like great like let's let's get through what we're doing now and then like the next thing coming up maybe that becomes a new exciting opportunity to go tackle. Um but things aren't not always ideal. So sometimes it's like oh there's a critical bug that has to be fixed or we work in security so there might be something related to security that comes up. So, um there's always priority changes and one of my goals is to make sure that we're focused on the most important thing while uh reducing randomization for the team which is really difficult to do if things are always changing and then making sure that people can focus on the work that they find engaging.

Um in my opinion, that's a really big part about being an engineering manager and probably one of the least talked about. And um I think that that can really separate you from doing a good job as an engineering manager versus just being someone who assigns work, right? That's it's easy to go um who who who has the next free capacity and just like you know who's the best at this and who has the next free capacity like go do it. But uh people are people, right? They're going to have um different interests, different things that get them engaged or challenged. So trying to understand that and align things so that they feel like they're growing. Um they feel like they're focused on things that are interesting challenges for them and they're engaged in that work. Um so there's time spent on that. I do a lot of cross team meetings.

So trying to make sure that for the projects of of the scale we're at and like the variety of different things that we're doing, there's a lot of interactions across teams. Um, so it's not just like I have, you know, 10 to 15 people that report to me and we work in isolation from other teams and we just deliver stuff and, you know, check the boxes. It's really like um, at any given point in time, we might have like a handful, you know, up to five sort of different uh, interactions with teams that we're actively working on. And then on top of that, there might be like new requests and requirements coming in where we're having those conversations with people too. Not to mention we have things like on call. It's a live service, right? So these are all the things we plan for, but then we have stuff on top of that that's we didn't plan for that.

We have to make progress with that. Um what else? Designing, right? So there's some things where I have to put specs together for things. Um a lot of the time my my goal with that is to is to not be the person that's doing it, which sounds kind of funny. Um, I'm happy to work with my I'm happy to kind of be the in between. So, if it's like this is a goal that we have, I'm happy to um try getting that articulated into a document, working with uh partners andor product andor engineers to come up with a high level. But when it comes to architecting a design, like this is one of the the weird sort of things to balance, right? If If you're a newer engineering manager and you've already been doing this kind of stuff because you have the technical background, you're not managing a lot of people like it would feel very artificial to say, "Oh, no, no, no, like you don't you don't design things now.

Like that's someone else's responsibility as in like you're not capable of it or you don't have time to do it." Like that's not that doesn't really make sense. It's pretty artificial. Um for me coming into a team where there's already tech leads, there's already principal engineers in these different areas. They are the subject matter experts for years. I'm uh all things considered very new to it compared to them even though I've been on this team for two years now. Does it mean that I am not able to come up with uh architectural designs? No. uh would I be the most effective at it? Also, no. If my team was completely swamped doing other things and we needed to make progress on an architectural design, does that mean that I shouldn't do it or shouldn't start it? No. Um it's just that it doesn't make sense for me to do it as as the first step as in like the the ideal way is that I'm the one doing it.

It doesn't make sense. I have principal engineers that could do it significantly better than me because they have the background. I have senior engineers andor people that are more junior than that that are looking for such opportunities to do that. So if I am the one that's putting architectural designs together, I'm actually taking opportunities away from people. It it doesn't make a lot of sense for me to do that. If it's an urgent priority and there literally isn't another option, then of course I can go do it. But I would much rather that I'm trying to find an as an opportunity for someone to go do this. Now, does that mean that I just delegate it and walk away and then say I never have to look at an architectural design again? No. I literally participate in our like architectural review process across Substrate. Substrate is um the internal like the platform for Office 365.

So, I participate in that. Um, I have team members that are putting together designs where I'm reviewing them, participating in the feedback and and all of that. So, like I'm actively participating in them. I'm just not the one who's like generally specking them out from scratch. So, that takes up a bunch of time. There's stuff like on a you know regular basis where um fortunately because we do a lot of stuff in C and that's you know my preferred language uh to work in because I code a lot in C uh I can help people if they're stuck on C# things right I can do code reviews uh effectively in C at least there's going to be parts of um the domain where I don't have the depth of knowledge from not working in the codebase but at least I'm like there are some things

where I'm like as best patterns and practices, readability, uh did you cover things with tests, this kind of stuff like I can participate in code reviews and not be useless. Uh other languages make it more challenging, right? So if we have a C++ review, it's not that I cannot do it. It's just that um the the value ad from me is less and less. So I do spend time on reviews. Um there are times even like you know I'm just thinking about examples of one-on-one conversations where we're going through stuff and then someone will you know they'll bring up they were working on some code and it's like wait I got time you got time like we can kind of extend the oneonone just to like why don't we just walk through this code together. So almost like pair programming like pair debugging that kind of stuff.

So that comes up on a pretty regular basis. Um, but yeah, ultimately it's like there's a lot on the people side of things. I don't think people realize how much uh how much time goes into that. The the more people that you add into your um responsibility in terms of your direct reports, the more that your time is spent on that, and I don't mean that in a bad way. Uh this the reality from a scaling kind of point of view. Um, you know, I think and I I feel like an ideal number of direct reports if you wanted to like stay hands-on and technical is like, you know, three to to six, I would say somewhere in there is like you probably have some people to manage. You can still be pretty hands-on. I think once you're going past six though, um it also depends on the experience level, the domain expertise of not of of your your direct reports and yourself.

So you can get away with, you know, still being hands-on beyond that. Like I have literally done this before in the past. I've managed uh you know, 10 plus people and was still coding every day. But it's like in terms of your time constraints, you don't you're kind of you can't be effective at all of those something like there will be a trade-off or you're using more more time for work. So anyway, that's kind of high level different areas I focus on, but one of the the main questions with part of this uh this message that came in was like what does it mean to be a principal engineering manager? Principal is just the the level. 65 is the earliest you can be principal. I'm level 66 right now. And uh 65 is also the earliest engineering manager uh level allowed in Office 365 to the best of my knowledge.

Um levels FYI is confusing because they label a principal engineering manager um at Microsoft as a principal director of engineering. Maybe that is the case in Azure or other parts of Microsoft, but not in uh Office 365 at least. So, hope that helps. I realize it's probably a little all over the place, but that's what I got. I will see you folks later, and hopefully my eye is back to uh not needing a sleep mask over top of it because it's disgusting. But if you have questions, leave them below in the comments. Otherwise, go to codecame.com. You can submit questions anonymously or do as this person did. Find me on LinkedIn. Anywhere else you want, send me a message. I'll try my best to make you a video. Take care.