What Is The Most Effective Way To Get To Senior, Staff, and Beyond?

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the Experience Devs subreddit. And this one is from a person asking about my squeaky windshield wipers. No, it's uh from Man, it's going to be super noisy. Sorry. The uh questions about getting promoted to senior staff principal and the most effective way to do it. Um it seems like this person was just being genuinely curious, right? Um, I don't think they're necessarily expecting a step by step, you know, three secrets doctors don't want you to know about for getting to senior staff principal level or looking for advice for how others have navigated it. I've talked about that a lot on this channel. Um, my perspective at least on what it looks like to go, you know, from junior, midle, senior, beyond. And, um, I figured maybe make another video. will talk about some of these things. And I'm kind of mentioning that because if you're new to the channel, there's a lot of videos on this channel.

Uh maybe have a look through. There might be some other, you know, uh takes that I've done on this kind of thing that might be helpful. So, uh and a reminder as I start talking about this. Um you know, if you have questions about software engineering or career development, leave them below in the comments. I'm happy to try making a video response for you. Um, and then you can go to codecommute.com if you want to submit stuff anonymously. So, first thing I think that's worth mentioning when we start talking about levels and roles and things like that, it's going to look different everywhere, right? Um, so if we start saying things like staff and principal, like the titles, it's kind of like, you know, depending where you are, they might be different things, but in general, let's get through this light.

Um, if we're talking about progressing in these levels, one of the things that's common, regardless of the label, is that you are going to be going from a spot when you're junior that is, say, less ambiguous, less complexity in the work you're doing, a lot more pointed, specific work, a lot more well understood. Um, you go from this to things that are broader in scope, more ambiguous. um and larger surface area. And so that's a you know obviously a super generalization of this kind of thing. But if you think about that from junior to midle, senior and then beyond like staff, principal kind of thing, the the idea is that these things continue to scale with the level. So that doesn't mean that someone say at a principal level is just doing you know 100x more bug fixes of the same sort of scope that you might have been doing when you were more junior.

It means that they're working on larger scale problems. It means they're working on larger scale problems with more ambiguity. There's more complexity to those. There's a larger surface area of impact that they're having. they have to work with more people across perhaps multiple teams across organizations even so the scope and impact is greater. Okay, so that's the first thing I kind of want to get out of the way um to kind of set the stage here. So if we start thinking about this right, I think that a lot of the time this conversation leans into maybe two paths of like well we got our technical skills like how good I am at programming and software engineering and then I got um maybe like soft skills, right? Like is it just a political thing? Do I just have to talk to the right people and that can happen?

And like I think depending on who you are and your experiences and things you've seen and you know that have happened in your career the answer might be a little bit of column A and a little bit of column B. But um I think it's worth teasing this apart. So we will be talking about technical stuff. We'll talk about um on the soft skill side of things throughout this. And uh I think the next thing I want to kind of introduce is like this uh I don't know like challenging reality that like you could be someone who is very uh technically talented. You could be someone with great you know soft skills, interpersonal skills. At the end of the day, when it comes to promotions, the um sort of the reality is that a lot of the time your manager is the one who is going to be the one putting you up for promotion, right?

I'm making this video and obviously I have to generalize the things I say, but I would say more often than not that's how that works is that you have a manager and they are the ones who are going to, you know, put you up for promotion based on the work you're doing, that kind of thing. And I say that because this is something that's like partially outside of your control and and partially in your control. And uh what I mean by that is that your what you can't can do is what you can't do is control what your manager does, right? You can give them if you have a great manager, I would say you can give them the information, the ammunition to be able to support you for a promotion, but like they're the ones who sort of need to back it, need to push for you to have that promotion.

And if they're not bought into doing it at a minimum, then it's going to be uh a difficult road, right? The other thing that I have to mention here is that it's more than just your manager wanting to promote you. I mean depending on where you work, how things are structured, I would argue that is the minimum requirement, but it's not um like sufficient on its own. If you're more junior, it might be that if your manager puts you up for promotion, you know, someone's like, I'm not going to I'm not going to disagree with that. Like if the manager says this person's ready, then they're probably ready. As long as there's budget and stuff for it, great. In other cases, as you become more senior, you do actually need, you know, more buy in beyond just your manager, right?

I've talked about this a lot in other videos where, you know, it could be a matter of, I know, for say getting to principal level at Microsoft, your manager obviously has to be supporting you for that. Your skip level manager has to be supporting you for that. And then it's also like your skit manager's peers. They have to be aware of what you're doing. They have to know the impact that you're having because if they don't, it's sort of indicative that the the impact you're having is not at the scale that's required for principle. And sorry, I'm trying to have this conversation with all of you and like uh it's raining in Seattle. big surprise, but it's actually like the visibility is pretty crappy. Um, so just trying to be a little bit more cautious here.

So, these things are important to call out because regardless of what advice I'm going to put in front of you, I think like, you know, whether or not you agree or disagree with the advice that follows, say you do quote unquote the right thing the whole way, if like if your manager is not supporting you for promotion and depending on your level, getting the buy in from others, it's ultimately just not going to work. So the part that's in your control is if you're not in a good environment where you have a manager that supports you, that part's in your control. That might be time to um to explore other opportunities. But I think the important thing is to have some awareness of this. So okay, with that said, um anything more on that? I don't I don't think so. Maybe something else will come to mind.

But um oh yeah, I guess there there was one more thing I wanted to say that uh you know the the sort of ongoing joke on this channel is that I always come back to saying like you know level set expectations with your manager. So what I mean when I say that is if you take what I was just saying about your manager has to support you. If you have a good manager, they're trying to set you up in the right direction so that you're working on things that are important to the business and important to your career growth. And so if you are aligned with your manager on what those important things are, then hopefully if they are a good manager and you are delivering on those things, that's creating the evidence that they need to be able to back you for promotion. If you are not aligned with your manager, it might be that you are doing things, those things arguably could be important and impactful.

And if you're not aligned with your manager, they may not be seeing the significance of that work. They might be saying, "Sure, you did that, but like you didn't do the things we talked about, which I said were the important things." And like that puts them in a weird spot. My point is that having alignment with your manager and having a manager that supports you, it's pretty critical for this. So do have conversations with your manager about getting alignment on what's expected. Okay. Um now when I think about the technical side versus the soft skills side and and things like that, um I I think of course the technical skills are going to be super important. We're talking about software engineering, right? Um, this is a technical field. And so when I talk about this stuff a lot of the time, I don't want people to get the impression that I'm saying that uh technical stuff's not important.

This guy's trying to prevent a zipper merge, which is very funny. Um, is cutting me off so that I don't zipper merge when it's uh supposed to be my turn to zipper merge. But that's okay. Drives a BMW. We'll see if he can use a signal. Um, I talk about soft skills and stuff a lot because I I think that people overindex on the technical side of things. Like you were doing software engineering work, odds are that you were going to be regularly practicing a lot of the technical things. And I think that uh there's a more natural tendency for people to hyperfocus on that. So a lot of the time when I talk about these things, you'll hear me overindex the other way on soft skills and things because I think that a lot of you are already doing the technical side and you get more exposure to that naturally by writing code.

So when I think about going, you know, let's say this this person in the in the Reddit post was talking about 6 years of experience. So, let's assume they're, you know, mid-level towards senior. Obviously, your mileage may vary uh on time horizons for this stuff. Let's assume somewhere in that neighborhood and they're working towards, you know, staff, principal kind of level. Um what I would say is that there's probably some expectation already that you are um working on initiatives that are broader than just you know your direct feature work. You're not just working on a feature sort of in isolation that's small scope. You've probably been participating andor leading features that are involving other people. Maybe that's mostly within your team still, which is not a problem, but like you're probably leading some of these things andor participating in some bigger um feature work at this point, right?

Some initiatives that are are larger. And part of that, and the reason I say this is like those types of initiatives are often going to involve what, right? like more complexity, there's more moving parts, more ambiguity because there's more moving parts and the problem is a bigger one to solve. And so with that comes this expectation that you have the technical chops to be able to solve those types of problems and navigate them, but also the soft skills because you're going to have to work with other people, right? So if we think about this, if you are, you know, very excellent at your technical skills and you have a really difficult time working with other people, you're not going to be able to amplify and scale the work and impact that you're having to degree because it's almost like you have to do it on your own because you're not great at working with others.

Jesus, there's literally nothing in front of me. These sensors are going off on their own and it just tightened the seat belt on me. But the rain is pretty bad. I might have to cut this video short, unfortunately. Um, cuz now the visibility is becoming pretty rough. We'll see. We'll see. Maybe I'll keep it on. We'll recover. It's a lot of rain. Feels like it's not even raining hard. It's just like a lot of it. There's a lot of water accumulation. I'm mostly worried about hydroplaning right now. It's a thing I'm looking for cuz there's so much water on the road and all that it's going to take. Like I can't drive from the left lane cuz I'm pretty sure I'm going to hydroplane.

And then driving in this lane means that anyone who wants to to come over into the fast lane, who's going to be going slower than me to start with, if they just pop over, they might cut me off and I won't be able to hit the brakes when it's this slick. Um, or swerve because if I swerve, I'm probably going to get into some hydroplaning territory. So, we'll see. It's getting a little better. Um, okay. So, for leading projects like this at a senior level, I I would say like when it goes towards principle, it's a lot of the same thing. It's just scaling up. And I mean like I I started this conversation talking about this in the general sense and apologies that it's still more general like this, but it's true.

I think you have to get good at being able to, you know, lead these smaller projects, understand where you're having challenges, whether it's like, you know, you're you're crossing team boundaries and you don't seem to have enough uh technical understanding of what's going on maybe for the other parts of the other team has to do like that's probably a good indicator for you to get better at, you know, getting more comfortable with some other technical areas. How do you get better at ramping up in those areas faster? What's actually helpful? Like do you have to go know all of their code base? Like probably not, but maybe for you like understanding more of their code is more beneficial, right? Like I think you have to kind of figure that out for yourself. Um so pay attention when you're leading projects at a senior level or participating in projects where other principal engineers are are leading them and what that looks like.

ones that work really well, right? Where you're like, "Wow, this project's going pretty smooth or it seems like this person has a good handle on what's going on. What is it that they're doing that's helping them with that, right?" And the inverse when you're like, "Wow, I'm on this project and this seems like it's always off the rails. Is it something that this the person leading it could be doing better? Are there challenges that are happening with the dependencies that are maybe outside of their control? Is it is it off the rails, but people understand why versus not, right? Like, so that's the difference between being disorganized and um and just like, you know, unexpected things come up because it's it's real life, right? Maybe there's an external dependency that's not even uh you know, across teams or organizations. It's literally outside of the the company.

something that happens derails a project, people understand that it happened. They have visibility and like, okay, now we have to pivot, right? So, like I think it's really important to be paying attention to these types of things because when you're leading big projects at larger scale to deliver on bigger impact, are you aware of these types of things? Right? So, you can be paying attention to them, understanding how to navigate them early on. I got to move lanes now. Okay, let's go. Hydroplane territory. Um, you understand how to navigate them before you're responsible for them. I think that's uh sort of a piece of advice I would like to give you. So, yes, if you're working on a project, you're not leading it and it's larger scale, it might be easier for you to say, "Let me just sit back and focus on just my piece of the puzzle.

And there's nothing wrong with that. But I think if you're trying to, you know, grow in your in your level in your role is as much as you can pay attention to these situations outside of just the work you're doing so that you can, you know, better prepare yourself when you need to do it. um when you are leading projects, right? I think that a lot of this is going to come back to like soft skills and things like that. I think one of the things that people get wrong a lot is that when you're leading projects, um no one no one likes sharing if a project's off course, right? So, I think something that people mess up a lot is they'll say like, "Oh, everything's fine. Everything's fine. It's okay. It's okay." Um, but really what they should be doing is, you know, putting up their hand and drawing awareness to say, "No, it's offc course." That's also like a very normal thing for things to be off course.

It's really about raising awareness to those types of things and then coming up with mitigations, alternative strategies, trying to unblock things, right? There's literally people's roles are dedicated to this type of thing, right? I would say a lot of the time project managers do this, right? Not always, not in every team, not in every or company, but a lot of the time when I've worked with project managers, they're very skilled at this or what I would say the effective project managers or the ones that I think are doing a good job in my experience, they're very good at this type of thing. And it's not an easy thing to do, right? It's not an easy thing to do. Well, it's easy maybe for someone to sit back and say, "Hey, shit's off the rails here." Yeah.

I mean, if you had a deadline and some targets and you're not hitting them, that might be for you as an uh maybe the person who's responsible for the project, it might feel like that's a hard thing to say, but the act of saying something's off the rails is not very difficult. What you do with that is more difficult, right? And I think that's that's where um you know we can say raising awareness is critical not hiding from it. So letting stakeholders know yes this is off track and then following. So not just that right that's a critical step to be able to do that and then following up with like well what are we doing about it? the more experience you have with different types of projects, the more examples of like ways you can mitigate these types of challenges will come up. Um, you know, some of these things you could try preparing for ahead of time, right?

If this type of, you know, scenario comes up, here's how we might approach it. Um, from the onset of a project, you might try having some of these mitigation plans. Um, there's going to be lots of scenarios that you didn't prepare for, and that's that's also life. And so I would say realistically don't expect to prepare for everything. But what you can expect to do is you know uh how do you improve your agility I I like the word agility but I hate that like if I say agile then it's like automatically some type of specific software development process. It's not what I mean. But having agility in your plan so that when does go sideways, you don't go, "Well, I guess the whole project's screwed. Like, we better give up." No. Um, you know, are there ways that you can deliver parts of it? Are there ways that you can uh move dependencies around?

Are there ways that you can um instead of shipping uh what was initially planned, you take a step back and you take you do an alternative implementation that will get you closer to your ship date and then you have follow-up work, right? Are there are there creative strategies that you can look at, right? And I would say that especially on the engineering side like I mean we can talk about different ways where we're moving people as resources and and teams and stuff around for priorities. That's one thing. But I think as an engineer where you can really shine is coming up with creative technical solutions that are alternatives. Like we can we can sit down as engineers and debate, you know, what is the best way to go implement something because we're looking at sort of the the end state of what we're trying to implement, right?

So if we were to sit down and try designing a system, you know, we might have slightly different opinions or very different opinions on like the best way, best technology to use, how things integrate, but like I would bet you that if we sat down and debated back and forth in a group, we could come up with a plan that we'd all agree on and say like this this architecture feels like it's maybe the the best compromise of all these things we've talked about. And that would be the goal, right? We want to get on the same page, come together. But a lot of the time what ends up getting missed in those conversations and not always, but I would say a lot of the time is that we're talking about some ideal end state, right? This is the architecture. This is the solution that we want to have.

And so I think it's really good that we move in that direction. But I think one of the things that saves asses a lot in projects that are big and complicated and involve lots of people is that you have strategies that allow you to not have to land the full final thing, the perfect architecture in the end that you can still work towards that, but you can say, "Hey, look, like if we, you know, if we pivot here, we can deliver part of that, right? It's still good. It's still getting us to shipping what we want. It might have uh a bit of a tradeoff right now. The perfect architecture we talked about would be you know half the latency and twice the throughput but like you know based on circumstances ABC that's if we need that that's going to push us past this deadline by you know 3 months outside of our control.

We've tried you know working with these other teams they can't get to it. So okay do we miss the whole deadline or is it a possibility we could accept you know this for latency this for throughput and we can ship that and then how we how we actually code that we design for it um when the final proper thing is ready to be integrated you know it's only a little bit of extra work at that point to get us back on track so maybe we miss the target release date um by 3 months for that that perfect thing we talked about, but we can hit the target date with a slightly less perfect thing and then follow up in the 3 months to get the proper thing integrated, right? Like can you come up with creative strategies like that on the technical side to help? Um so I think when I think about people leading projects, being responsible for things like that, that's like a big part that comes up.

So, I mean, I kind of went into specifics around leading projects, but the reason I'm doing that is because I would say that, you know, one of the the really big things that's going to take you from this mid senior level to principal staff kind of territory is that you can do this type of thing really well. Okay, it's not the only thing. I would say that when it comes to design documents, designing systems, architecture, um you want to be able to show to stakeholders that are involved that you've done your due diligence, that you've put together something that is representative of the solving the problem space, right? You've done your homework for it. But also, I would say a lot of the time too, like a I'm going to call it a mistake or something that could be improved is that you don't need to do that stuff in isolation.

In fact, uh I would say if you were designing something for, I don't know, like a larger impact across multiple teams. If you try to do that whole design on your own in isolation and then you bring in everyone at the end to like just sign off on it, I would say that's probably the last thing I would recommend. Maybe not the last thing, but it's it's lower on the list of things I would recommend. And I say that because if we it I don't know depending on your level of experience and companies you've worked at. Um I would say that that's asking for people to like to basically have opposing views and to have resistance when they're reviewing your dock. And there's nothing wrong with that, right? Like that's a natural thing that people are going to have different opinions on how things should integrate, be built, all those kind of things.

But um if you leave it all to the end, now you've done all of this work for a design completely in isolation. Now you're going to try to get everyone else brought in and debate this until you know you're blue in the face. I would say like why not just do your do like a sufficient amount of homework. This will depend on what the actual topic is, how big the the problem space is, who's involved, but do a sufficient amount, come up with some type of initial proposal and be working with other people to come up with the rest of the proposal. Right? So, my point is don't do it on your own and don't go the exact opposite, which is just make everyone else do it, you do nothing. but it's somewhere in the middle where you're leading it. You're the one driving it, but you're not designing it fully in isolation.

Get people involved early. I think getting input early, it's not a stop sign. Come on. Come on. Jeez. You'd have to see this intersection. And it's really funny, but it's basically uh at the lights on in the right lane. There's no stop sign and it's like a you have your own dedicated lane. So, you just come off the highway and you keep driving and people like to stop there cuz they think that there's oncoming traffic into it. There isn't. Um anyway, so you get people brought into part of the design process early. um helps you see things that you weren't aware of, right? You have these experts from other areas that are able to come in, offer their insights, and you do it early so you're not wasting as much time for everyone. Um what else? What else?

I I would say I have an expectation that people at you know even even senior for sure like you're you're mentoring other people right like that should be coming up when I say mentoring other people I don't necessarily mean like you must have formal mentorship relationships with other people that's not what I'm saying uh I'm saying that there's people on the team that like you're not just sitting in a silo coding away on things and then ignoring the team like you are helping other people on the team be better at being on the team. So that means understanding like um say there's I'm just going to make up some examples, right? There's parts of the code base that are problematic and everyone's got a difficult time working there. Like you're hearing these things, you're you know suggesting initiatives for improving them. That might be things that uh you're helping other people on the team lead those initiatives.

It might be that you're helping people on board and debug things. Like there's so many different ways to look at this. But my point is that uh at least like even to get to senior I would have this expectation that this is something that happens. If you were like avoiding people on the team just so that you can work in a silo, I would say like I I don't want people in senior positions even doing that. I expect that seniors are demonstrating some type of leadership in that regard. And then I would expect even more from principles. Um, and I say that because we work on teams and if you're not demonstrating that you are working with the team at that level, I don't want other people modeling that behavior. I don't want a team of individuals working in silos. I think that is not a good recipe for getting done personally.

And so I would want someone senior and above demonstrating that they work with other people. They bring other people along. They sort of you hear like the phrase like they're a multiplier, right? So not only are they doing, you know, the work that they're tasked with, their responsibilities, but part of that is that other people on the team by working with this person are are multiplied in terms of their impact that they can have. because I think if you have a team, the math checks out, right? If you have a team of people and the numbers all multiply together, you get more done um to oversimplify it. But I think having people that help other people on the team is uh tremendously beneficial. I think that's where soft skills and stuff come in, right? I think when I was reading this Reddit thread where this person was asking this question, the the top voted comment was something along the lines of like be likable.

And I think the person said like you'd be amazed how many idiots get promoted into um you know into these positions just from you know being likable kind of thing. Obviously they're being a little bit facitious there. Uh, and I'm not saying that that doesn't happen where people are just kind of their way into things, but I I do think there's uh aside from that some some important truth there which is like as I've been kind of hinting at, you are going to be working with other people because that is going to be how you have more impact is working with others. And so if you are difficult to work with or you avoid working with other people regardless of their level, um I think that's setting you up just to minimize your impact and that's going to make it hard. Um as I approach home here, I didn't talk much specifically about visibility.

A little bit earlier on I did, but I don't know if I even used the word visibility. Talked about impact. But one thing to touch on is like um I coming from like a startup where I was there since like right near the beginning um to having a you know I was there I think when it was like seven people and it was like 250 when I left. Um impact sorry visibility for me was never like a question. And I don't I don't say that like oh it's because I'm so good. I just mean that it was a small company and I think that I was fortunate that being there from the beginning meant that I had visibility in the work that I was doing as the company scaled. Like I kind of got that for free as the company was growing. Like when a company's like 10 people, there's a lot of visibility to what you're doing, even if it's not, you know, the most uh extravagant thing.

And then, you know, if you're doing more things as the company's growing, I just I felt like I didn't have to work hard for visibility. And I think that being at a large company like Microsoft now, visibility is a different story. Um, so I I kind of struggle with like, oh, like you need to be visible to get promoted. And I've said this in other videos, but uh there was a a VP that um I asked about this, like like what are your thoughts on visibility, how this works? And I I don't have his exact words, but essentially it was like, you know, it it's not a matter of like just artificially kind of like telling people what you do, like tapping people on the shoulder saying like, "Hey, I do this like now I have visibility and making sure you can tap everyone on

the shoulder." Um, sure there's parts of that like you know communicating kind of uh making sure that there's other parts of the organization aware of what you're doing because maybe it's helpful technology solving a common problem that kind of thing but um so like yes parts of that but I think more importantly he was kind of hinting at like maybe the work you're doing not not specific to me but like in a general sense maybe the work you're doing isn't having as much impact as you think if there isn't awareness of it almost implicitly, right? If you're genuinely doing impactful work, there should be some visibility associated with that naturally because the impact is so great. And I think that was a more helpful thing for me to hear.

Um cuz when I think about it, uh I would argue that some of the stuff I was doing in terms of why it wasn't visible, I was like, I'm doing the stuff my manager said, my skip level manager said, and like I don't know if I'm not getting promoted, like don't I literally have visibility to the people that that said, you know, these things and uh they did they did put me up for promotion, but I didn't get promoted because the impact of what I was doing was not visible to other parts of uh the org because arguably it wasn't that impactful, right? Not that it wasn't important, not that it wasn't a useful thing to do, but the scale of the impact was not actually being uh observed by others because it potentially wasn't that impactful across the org. And so I think hard to hear, but I think that was helpful framing.

It's like that's that's how visibility ends up working. Yes, you can do more promoting of things to get more visibility, but I think that framing helped me personally. So anyway, I'm at home. It's raining. These wipers sound like farts. We survived. Thanks for hanging in there. So, reminder, if you have questions about software engineering, career development, leave them below in the comments or go to codecommute.com and submit stuff there. I will see you in the next video. Take care.