Promoted To Principal Engineer: Here's What Actually Changes

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experienced dev subreddit and this topic was about being promoted into principal and the question was around like you know can people share specifics around what that looked like? Uh because I guess maybe from their experience they've kind of heard different things or it's very general and I don't know like kind of not obvious or too many too many random thing. I don't know like they're not getting a consistent message I guess which is which is fair. Um I think that's good criticism of of what I I think that looks like in general. So I feel like that would be a good topic to go through. I think that it's uh definitely worth clarifying in the beginning of this like I work at Microsoft. I have a perspective on this because of where I work and so I need to acknowledge like this is one place, right?

This is my my lived experience with this and other places may be very different. And so with that said, if you're listening to this, if you have a different experience and want to share thoughts or uh you know, further questions or anything like that, just add them in the comments cuz I think that your perspective is uh is also helpful for other people to hear if you're willing to share it. Okay. So maybe to to take a step back when we say like going into a principal level position, what what does it mean? Right? And so again, even this can vary from place to place. in terms of uh like the leveling structure, but generally speaking like a principal level is going to be uh beyond a senior engineer. And so at some places you'll have uh senior into principal. At other places you might have senior staff principal.

Some places the principal and staff is rever like there's there's all sorts of different flavors of this. At Microsoft at least at the time I'm talking about this and as long as I'm aware um the principal level follows the senior band. So on a numeric scale, Microsoft levels are, you know, kind of interesting in the numbering because you would have a senior engineer that is within that band. You could be a level 63 and a level 64. So there's two levels within the band. And then level 65 is the first uh sort of level that you can be in the principal band. So when I joined Microsoft, I joined at a level 65. uh so at the principal band and so to answer part of this right at least from from my perspective like I did not go through the steps uh at Microsoft directly

of what this person's asking which is to be promoted into a principal band like what did you have to do for me it was I worked somewhere else and I actually think that you know to to answer part of this uh like holistically I think that's an important factor and that's why I wanted to mention it is that you know one way to be at principal level is to be hired in at principal level right that's kind of maybe wishy-washy but like that is something we see in general uh maybe it's more challenging now but when people are going between jobs you know they talk about you know having a uh you know salary stock bonus whatever at some level then you even go to the exact same level at a different company and you're up leveling those things or um people that were on

the cusp of like getting a you know promo into the next level and didn't have it they switch jobs or they switch companies right and then they they switch and at that level above so that could be one such option uh am I saying that I feel like I was you know sort of cheating the system to get promote or hired in at senior or my goodness to get hired in at principal no like we literally only had a couple of levels of separation at the startup I worked at. So for me I actually had to not say for example oh I worked at Amazon at this level for x number of years therefore there's you know uh some more concrete evidence right or I was at Google and Amazon and these big tech companies to make a comparison I didn't have that so um

that's I mean that is one way where you can demonstrate based on your uh prior experience and obviously you have to interview well to be able to do it but that can be part of it For me, I did not have sort of like the comparable big tech experience. In fact, I actually didn't have any comparable experience in the domain, which I think is a very uh interesting and worthwhile point to mention. Uh I should also mention that I'm an engineering manager, which has um some nuance to it as well, right? So for example, I came in as a principal level engineering manager in the deployment space for you know deploying software into data centers across the planet. I have never worked with deployment like at that kind of scale. Um I have done CI/CD pipelines. I've never done deployment into data centers. In fact I've never worked with a distributed service in data centers.

So to be able to demonstrate operating at a principal level um I was able to do that by talking about the teams that I led right so the the different initiatives different teams and that is a balance of talking about the scope of my impact and I I realize that I'm already kind of making it very fluffy and generic scope of impact and visibility uh but like what is like what does that mean for scope of impact Right? Like so one such example was being able to take a uh a product idea that was outsourced uh and basically building it completely in-house to to save the money on that outsourcing project and then have it proprietary tech built in-house and then staff the team around it, right? And then lead that team for several years successfully.

So like that's sort of like a a direct impact on the business right while you know growing my scope of management from at different points in time right but you know at from one team up to several teams so growing the surface area in which I'm managing people and then also growing the surface area in terms of products and technology that I'm responsible for. So being able to to demonstrate that I'm doing that and operating at the level that's across all of engineering for the company that I used to work at. Now all of engineering is very subjective. And I need one sec cuz I got to switch lanes here. Kind of a crappy spot. Oh, come on, buddy. Nice. Someone had the exact same idea as me but the other way. So they were trying to speed up and they were like, "Oh I got to get over." And I was like, "Oh I got to get over." So we got over.

Um, but yeah, you know, all of engineering is very subjective because where like where I worked, all of engineering was a lot smaller than Microsoft's all of engineering. So anyway, point is that I was able to demonstrate that for, you know, multiple years I had organizationalwide impact consistently and then had lots of concrete stories to talk about that. From the engineering manager side of things, what's helpful is that a lot of and this is very applicable for software engineers as well, but being able to manage teams is something that uh can absolutely transition across different domains of software engineering, right? If it was in finance, like I was in digital forensics, right? So, what does that have to do with deployment? Um, about nothing, right? It's basically nothing. So the point is that I can take that skill set and apply it to different areas of software engineering and as a software engineer you can do the same thing.

So if you are you know taking the route of like I'm going to uh switch switch companies and then work to get you know uh hired in at the principal band. The I think for a software engineer for like some expectations I would say like on the technical side be ready to like uh like be very comfortable with uh you know if especially at big tech companies be very comfortable with like your lead code style questions right this when I say be very comfortable I mean like you're probably going to get asked lead code questions I've talked about this before. I don't agree with them, but you're probably going to get them. And the expectation is going to be that like it should be a breeze, right? That's the bar is set very high for a principal level engineer. So like if you are you might be a very good programmer, but if you're like fumbling through one of these questions and by the way like I fumble through them.

I think that I'm a I think I'm a good software developer. I fumble through them like crazy because I don't practice them. Point is, you're going to want to practice those. They should be, you know, very simple for you. You should be comfortable navigating them because I would say that's going to be the least of your concern, right? Like the expectation is that that's so simple for you and then the other parts are where it's really going to matter. So like your system design question is going to be very very important. You'll probably have at least one probably two of those for interviews and then uh you'll have like one or two rounds. It's really around like uh more of like the people soft skills kind of thing. And I think there you'll want to talk like I always think that it's important to to make sure you're ready to talk about difficult things, right?

Because if you're well practiced at navigating difficult things, I would say probably the, you know, that the happy path kind of questions are are going to come easy for you. So if someone was like, you know, walk me through a project that you led, like that probably comes easy to you if you're ready to talk about things that didn't go well and how you navigated them. And I usually think that those are the types of standout questions where especially at like a principal level. Cool. You're tell me about a project that you were working on that had like organizationalwide impact. Um tell me about like when it wasn't going to plan, right? How did you navigate that? How did you work with the other teams to get them bought in? How did you communicate things with stakeholders? Right? And you're going to want to have a project that is not like I had a pull request that people had to review.

like no I had to lead this initiative across the organization with multiple teams and you know here's here's how that looked. So I think I think it's a very you know plausible path. I think you just have to be ready to to demonstrate that kind of uh that kind of impact, right? Organizational level impact. Um and ideally something that you were able to kind of sustain. The reason why this might be beneficial for you if you're if you're ready for a job change is like um you where you are there might be this notion of like I don't know like it's it's difficult depending on the state of the organization and like how people are growing their teams and stuff like that.

Like if you're on a team already that has principal engineers and they're like okay well like we can't just have a team of all principal engineers like naturally the growth might start to feel like it's stagnating which is kind of crabby because like that shouldn't be a reflection of whether or not you are capable of achieving that but that might be how it is in practice is that like those opportunities are already often taken by other principal engineers. you're just genuinely not being, you know, uh, given the opportunity for that kind of work on a on a regular basis. So, there might be a lot of reasons for you to to pursue that outside of just like getting promoted into it and then exploring getting hired into it.

Um, this could be a thing, too, like if you've been told several times like, "Hey, we're trying for your principal promotion." and like you know you're you feel like your manager was trying to support you but you're always like for some reason falling a little bit short um from those conversations you might have lots of evidence you can take from that and then use that as like you know I'm going to go apply here and when they interview me I'm ready to talk about these types of things. Um, okay. So, spent way too long talking about being hired into it. Uh, in terms of being promoted into it, um, it's similar types of things, right? So, I was already talking about like scope of impact, being like organizational, that kind of stuff. Uh I think like I want to think of some it's tricky to think of examples without like talking about the specific details cuz they're say proprietary.

Um so let's come up with something. So it's also tricky too cuz I work on platform teams and then like partnered with platform teams as well. So, uh I don't know like we could think about if you if you're on a platform team and you have some type of functionality or like partner teams that you support that onboard to your platform. Um is there some project that you can lead that basically allows your platform to be accessible by entirely new groups of partners? Right. So, you support uh partners of type A, B, C today, but uh you're going to lead a project that unlocks access for partners D, E, and F. Like that type of partner, that could be huge. Um like super super generically like we the team I'm on like we run a reverse proxy for Microsoft 365.

So if you could say like hey look our proxy supports these types of services and you end up leading a project that is like uh we're going to support this whole other class of services that means that you know you're expanding the footprint of you take all the awesome stuff your team already does and bridge that over to to other areas. Why is this guy driving so close to me? Holy That's so weird. Anyway, um you can't see cuz he was on the other side of the camera, but I swear he was there. And so it's it's really like doing work like that with that example is like again taking something that's already the awesome work your entire team does and just like completely expanding that offering to more groups which is which is hugely beneficial. And so it's not just a matter of like I proposed the idea and it's not just a matter of like I I worked on the thing uh you know I did a couple of code changes for it.

It's like taking it from perhaps the beginning of that idea. Maybe it wasn't your idea like you didn't invent it but you know you were there when it was being put together and then maybe it was assigned to you and you kind of took that initiative at the beginning and ran with it. And so you were, you know, the lead developer on it. Um, you were interacting with other people on your team, likely across teams, right? So the usually these projects at this scale, they're not just something that you do on your own. They often require that you're working across several teams and then uh sort of leading the design architecture on that kind of stuff. So like think about projects at that scale. And I've been like I don't know I still get kind of bent out of shape when people talk about like impact and visibility because like this person was asking about on Reddit.

I'm like it feels too like handwavy like oh impact oh visibility. But I'm probably not going to do a good job of explaining it. But I I had um I had a VP at Microsoft. I think he found a really good way to explain it and it was like what you'll often see and when people talk about visibility um is that you'll see people trying to and there's nothing wrong with this but they lean into like well let me tell you more about the thing I'm doing right so like let me communicate this to stakeholders and I think that is important right I think that can go a long way I the projects you're doing, trying to communicate that out, whether that's, you know, updates to stakeholders, whether that's going out of your way to say like, I think that people in this part of the org might benefit from it.

Maybe I'll reach out to them and see if they have interest in following along with what's going on. Just like lots of communication, right? And I think you can ideally work with your manager to figure out what that looks like, but we've seen people do like uh you know, weekly project updates, newsletters, things like that, lots of different things. But what this VP was telling me was like when people talk about visibility and impact um the the way to think about it is that the if you want to know if the impact is is sort of great enough, right, for this to be a consideration. It's almost like he didn't say it this way, but my interpretation is almost like you shouldn't have to go out of your way to overcommunicate it because the impact is like should be great enough that the other people

in parts of the org that would be in those conversations around in regarding your promotion are able to say yes like that work that person's doing I actually have visibility into what's happening. Maybe not all the details, but I have visibility into what's happening because that impact is so great. Right? It's the work itself is actually on a large enough surface area that other parts of the org don't have a choice but to know about it. And so, again, I I'm not going to do as good of a job as as he did. Um, but I thought that was like interesting framing cuz I was like very frustrated that it felt like so for me like I got hired in at 65 and and was promoted to 66, but I had I had two different times in my my time at Microsoft so far or I was put up for promotion and didn't get it.

And the feedback both times was like not enough visibility. And I'm like, I'm so frustrated by this. Like, what do you mean it's not visible? And so, you know, I I guess maybe a couple of things. Maybe the work I was doing was simply not impactful at the scale that the other people would have visibility into it. And I think that was helpful framing once he put that in front of me cuz I didn't want to I didn't want to change like how much work I'm doing and the type of work I'm doing to be like let me just write a bunch of newsletters like that shouldn't replace it is what I'm saying. I think it's a good augmentation. It's a good supplement but it shouldn't replace the work you're doing. Right? Then it just feels kind of fake to me. So, other things I've seen people do, let's see.

A lot of the time, a lot of the time there's some really big project involved. Um, but it's usually not that, you know, I'm just going to give an example, right? It's not like, from what I've seen at least, it's not a lot where someone's hired or they're at a senior level. So, they're promoted into senior and then they just do one really big project for a year and they become principal. It's not like that. It's more like this person's been operating at a really high level as a senior routinely work like being part of big impactful projects. Maybe not necessarily one they've led on their own start to finish, but they've been demonstrating this already and then they were able to do like one or two of these really big projects where it's like, hey, look, like this person, it's not like like they're a good participant in projects like they're actually able to take on this responsibility and uh and and lead entire projects.

So I think you know the word that comes to mind for me is like accountability where you are an ownership I guess is the other word like accountability and ownership really stand out for people like this because there is a lot of confidence put into this person like this is the project that you are leading you are taking accountability people aren't chasing you down to be like is anything getting done on this right you're driving it so I think that's what I've seen most in most cases, right, is there's regular demonstration of contributions to large projects and then um you know, in in these conversations that I've been part of at least when someone's getting promoted into principal is that there's almost always like this person, you know, was just had just delivered something that was really big and impactful and uh their manager is

able to kind talk about that impact in a way that the the group that's kind of going to be giving their blessing to it is able to say like I maybe I don't need to know the specific details cuz I don't work exactly on that team, but I can tell based on what I'm hearing like how impactful that is. I don't know if any of that's making sense, but um this is why it's kind of tricky to talk about because as I'm trying to do my best job, I like definitely agree with what this person wrote on Reddit, which is like it always feels like it's uh I don't know, kind of this like nebulous moving target. And maybe that's like the last thing I want to talk about. Um, is that I think that is a big part of it in all honesty. Um, which I don't really think is fair.

Um, but yeah, I don't I don't think there's a ton of consistency. I think that you can get put into situations where maybe you are doing awesome work and for whatever reason that doesn't get represented adequately. Um, you know, maybe, you know, maybe you're on the the cusp of promotion and it's like, well, I don't know, like didn't just needed to see a little bit more this time and like people weren't really confident with pushing that over the edge. And then you you know you get the feedback where it's like well okay like you know close but you know for next time and like here's some areas to focus on. I've seen seen it where people are like the the feedback that they're not getting it is almost like unfortunately demotivates them where it's like they don't realize that in the conversation because they're not part of it like truly how close it was to being a reality.

and then and then just like not quite making it. And the reality is like if they probably continued on the same trajectory, it would have just uh you know come in maybe another 6 months or so. But it's very disheartening, right? Like I I'm saying that as someone like I I get it. um when I you know I'll use myself as an example hearing like oh like didn't have enough visibility and I'm like I'm literally doing what my what my manager told me my skip level manager wanted to see out of me so why why should I do that if that's not going to be the thing that helps right it feels weird um so I I I I know what it feels like to be like very disappointed and it's disengaging so I've I've definitely seen that with folks. Um but it's hard, right? It's hard and you might not know that in that conversation genuinely things were very close.

Um yeah, I don't know. I think like overall I know like I I work in big tech and I work at Microsoft and have been there for just under six years now. I I I get why people are very focused on on titles and levels and stuff like that because that's, you know, how that's like the way that we gauge our career progression, right? That is the numeric way. It's a quantitative way that we gauge it. But at the same time, like like I don't love it. It's uh Yeah, I don't know. It feels weird. I don't I don't have a good other alternative for how you gauge career progression because I acknowledge that like, you know, having some type of quantitative system is like super helpful. I don't know. I just I feel like it it adds so much more into the conversation around like people being focused on I've talked about this before, right?

Like people being focused on like what is the what's the work I need to do to get promoted? It's it's about a group of individuals or an organization of individuals. What do I need to do to get promoted? It centers everything around that versus like what do we need to do as an organization to deliver on our mission better? Like I think to me that's what you want to incentivize. How do we all work together on a common mission more effectively? And what ends up happening is that we end up structuring things in a way that's like as a group of individuals, how do I get ahead in my career where the side effect is like something good for the business that it feels backwards to me. Um, and to be clear, I don't think that I don't think it's set that way on purpose, but I feel like that's kind of what's happening.

So yeah, principal promotions are are challenging. Um I also think that it can be a moving target. So if you imagine that in sort of the lifetime of a company or an organization, right, things won't always be consistently at the same ratios, I guess, right? So, as an organization's growing, they might hire in uh I'm just making this up, right? Like they're they're scaling. They're growing in size rapidly. So, they're bringing on more and more engineers. And the sort of the what's the word I want? Uh the distribution of like the levels of those engineers will look different at different times in the organization's lifetime. And so if uh if you start having more and more people depending like in terms of growth phases for organizations where people are getting more and more promoted um then what happens is like your distribution may change dramatically over time and I'm not saying that's right or wrong.

I'm just saying like I don't think the distribution stays consistent. And so what may happen is you genuinely may find an organization in a state where they're like, we think that we have too many people at this level. And so therefore, you know, the bar that we're trying to set for this level is not it's not what we want it to be or it's not it's not kind of meeting the same expectation now. And so if they start to adjust what it means to be at that level, I think you can absolutely run into these weird situations where someone's like, "Man, I've been close for a while apparently." So like, why isn't it why isn't it lining up? And it's like, maybe the goalpost literally did move. And it has nothing to do with you. It has everything to do with uh, you know, organizations evolving over time.

So those are my thoughts on that. uh for me to get promoted into the next level of principal. um kind of a similar example where I had it's not that I did one project but I had I had a larger project that was used as evidence as part of that um that had you know CVP level visibility was visible across the org was leading uh more than just my direct reports uh more than just my greater team and so that was a multimonth project um with sort of that scope of impact. So, it's just another example of that's not the only thing, but having something like that is a really good story for visibility and impact in those types of conversations. So, that seems to be a very common type of thing. Uh in my case, it wasn't like, oh, go add a new service or go add a new functionality.

It was resiliency and it was resiliency across the entire platform. Um, and you know, as as much as it's like, sure, that was a thing that I was leading, uh, I will never take like the credit for that kind of stuff, like I didn't do that work. Everyone who contributed did that work. So, um, I think there was a lot of great success stories that came out of that where people were able to say, "Sure, okay, like maybe that was a project that I was responsible for coordinating. Cool. But there were tons of engineers that were able to have really good success stories about them leading parts of that initiative and it was awesome. I could rely on them to go deliver on these things. So, um, impact like that is not taken by one person and personally I almost have the opposite problem where I like don't want to take any credit for things because I'm like I manage the team, they do all the awesome work.

Um, but impact is not just taken by one person to own. When there's big impactful projects, you know, people get to what's a good way to say this? It's it's like a it's not a oneplus 1 equals 2, it's like a 1 plus 1 equals 3 kind of scenario where like everyone gets not a slice of the impact, you actually get more than what adds up as a whole. If that makes sense. Anyway, that's the video. Um, if you got questions about software engineering, career development, leave them below in the comments. Otherwise, go to codecame.com, submit anonymously, and it's time for the live stream, which is Monday evening, 7 p.m. on the Dev Leader Podcast YouTube channel. So, check it out. See you later.