Why You’re Not Progressing As A Senior Engineer!

Transcript is auto-generated and may contain errors.

Hey folks, we are going to LinkedIn for a message that I got. So, this will be kept anonymous. I think it's a great question though. It's going to be interesting to answer. So, I'll try my best. Um, this goes on to say, I'd like to understand how I can develop the skill set of a principal engineer, not just the title. So, I want to make sure we come back to this as we go through it. Currently working at a company as a senior engineer, but I don't feel like I'm progressing. Most of my work is front end focused on feature development, bug fixing, and code maintenance. I want to make a bigger impact either on a global scale or at least internally. But my manager wants me to keep focusing on these repetitive tasks. He does give me the freedom to explore backend work for new challenges, which is great, but I still feel like a void at work.

It's very strong phrasing to use. So everything I do, I have to learn on my own. No one is really anyone's mentor though everyone is willing to help if you ask. Um just a quick note on that. I would say like I don't know this might sound like kind of bad but like get used to that I guess. Um I think it's great if you can find mentors and stuff like that. Personally, like in my career, I never really had like I I always go back to saying my HR leader from like a management perspective, like she would have been closest thing that I had to like a mentor, but I you found like I had to carve my own path, right? And I'm not saying that that means never look for a mentor, but I would say like take the attitude where like you will need to be someone who's driving.

You might have to be kind of pushing into areas that you're not comfortable in. So kind of get used to that. And I don't mean that in like a crappy way. I'm just saying like you are doing that and that's good. So like make sure that you continue that. If you can find people for mentorship and stuff, that's great. I hold the senior engineer title and I think my skills are on par, but I'm not sure my contributions are. So interesting. Okay. I recently interviewed with a company and didn't make it. I'm not going to name the company. Uh the behavioral feedback was I'm expecting his projects to be more complex than this. set me back because now I'm rethinking the complexity of my work and honestly I don't feel very accomplished. So do you have any advice on what someone in my position could do?

Um so again this is a interesting question. I think one of the challenges with trying to answer this is that I feel like what's being asked and um sort of like what what advice is helpful might not be aligned. So I want to do my best to try and and kind of navigate this. So, um, interesting thing that was at the beginning of this is not just the title. Okay. And one of the things when I was first reading through this was like that was coming to mind was like when we talk about career progression like one of the things that is stand out is like your manager has to be like is ultimately going to be the person that promotes you. Okay. So there's really like two people that promote you. One is your manager and the other one is, you know, a hiring manager when you're switching to another company because that could be a promotion, but otherwise doesn't doesn't really happen, right?

So it sounds like this person's not necessarily interested in the title though because my the way that I was originally thinking about structuring sort of the the response to this was like sort of the typical like have the conversation with your manager kind of thing. Um again because if we're talking about titles like principal somewhere might mean principal or different somewhere else staff versus you know some places senior engineer might be the equivalent to a principal somewhere else. It's hard to know. So like if you're thinking about this from the perspective of where you're working have the conversation with your manager about it. But I'm going to try and steer away a little bit from that path because of what they called out in the beginning was it's less about the title more about the type of work. I will still mention conversations with your manager, but I'll come back to that.

The sort of the idea that I think about when it comes to like sort of principal level and I'm going to model this after like my understanding of principle at Microsoft. Um, again, I'm adding the caveat in there because that's the bias that I'm presenting from my side and this could look different in other places. So the the idea that I have around this is that when we talk about principal level versus senior is that especially at senior level you're able to deliver on big impact. You can do you know lead projects and things like that and you are generally able to excel at this sort of like within the capacity of your team. It's not to say that you don't do anything cross team but the expectation is that you're performing this at your team level right so you're doing work on behalf of

your team delivering on that leading things right the more mid-level engineers or junior engineers are looking to you for guidance you're the one generally who's you know that might be leading designs um and then having uh you know more junior or mid-level engineers kind of working alongside you on certain larger projects things like I'm not saying for every project by the way I'm generalizing but when we get into principle the the concepts are similar but the scale is different and that means that you're delivering work at an organizational level and I don't mean to say like you know at Microsoft or something that means it's got to be like impacting like all of Microsoft no like I for an example I work in office 365 5 and it work the platform is called substrate. So the substrate platform I am one of the teams inside of the substrate platform.

There are many many teams but when we're talking about having impact at the principal level it should be something that impacts substrate. It impacts teams across substrate not just your team. And this is for my example right? So when we're thinking about this at the principal level, the type of work that you need to be doing is not and this person's they're kind of identifying this is not opportunity they're getting, but this is the type of thing that I would expect at principal level. The other thing to mention, just to tie it back to that first part that I said I wasn't going to come back to, but um when it comes to being promoted into such a position, it's extremely rare that people have a chance taken on them where it's like, oh, I don't think they're quite at principal, but if we give them the title, we can see if they can do it.

It's overwhelmingly the case the other way which is like this person is operating at principal level already. Therefore, you know, the title just makes sense. It's much more common for that pattern to happen versus let's take a chance on someone. It's a lot crappier of a situation to take a chance on someone and it doesn't work and you're having a really difficult conversation the other way versus someone is absolutely demonstrating they operate at that level. But the big difference in my opinion between senior and principal is sort of the scale of the impact. And this person's kind of called that out. So when I'm thinking about advice for a situation like this one is to try and clarify that, right? make sure that we have a common understanding of what that looks like because without that it makes it kind of tricky to to navigate the rest of the conversation.

So if if we're okay with that definition that it's similar in terms of you know leading projects having you know leading designs that kind of thing the impact that you want to be having is felt sort of at the broader level across multiple teams across the organization. um framing for this uh I want to tie this to visibility and I bring this up because I struggle with this working in big tech full transparency um when we talk about visibility for this kind of stuff the work that you're doing should be so impactful that sort of like your depending on the hierarchy where you're working but like conceptually for me it would be like my skip levels peers should feel the impact of work I'm doing it's Not just like you'll hear this like kind of framing a lot like you know if you want to get promoted like make your manager's life easier.

Nope. And it's not even make your skip level's life easier. Nope. It's it should be impacting like at skip level and their peers because in in my case that would be sort of organizationally filled. So that's some framing. Now, this person goes on to say the style of work they're doing is like some front-end development. It sounds like they're and and I don't mean to say you can't be like a principal engineer and only focused on like front-end development, but it sounds like in terms of the scope of work they're getting to do, it's already being constrained like mostly to front end and like being able to work in the back end is like is nice to have. Um they're getting some of that opportunity. um like he he wrote freedom to explore backend work for new challenges and then he said that's great. So I assume they enjoy doing that.

That's so that is nice but ultimately it seems like the environment that this person's in is not conducive for this kind of thing. So couple of thoughts come to mind. It's like one do you continue to operate this way and you create those opportunities? this will depend on a, you know, many different factors. Like how much effort are you going to put into this? And I don't think there's like I I kind of want to, I don't know, like remind people that there's going to be points in your career where like you got to really be the driver. Okay. So, if you like where you're at and this is something that's kind of holding back progression, like how how much are you going to step up to the occasion and and try to look for such opportunities within the organization to be able to push on?

And I'm not saying that as in it's simple to do. I'm I'm actually saying it quite the opposite. It's probably very challenging, right? if if these opportunities aren't things that you're coming across regularly because I would assume just you know to clear this up I would assume that if there were such opportunities that this person would already be saying to their manager because they're already asking for like some work in the back end it would be like hey there's this opportunity for something really big and interesting can I go tackle that I I feel like that's not happening so does that mean that the opportunities are being taken by everyone else is this person not even looking. Are they actually just fewer and further between? So if you want to have such impact and it's not just showing up, you have to go creating it. Again, I'm not saying that that's a trivial thing.

So that will mean, you know, starting to talk with other stakeholders, other partner teams, trying to understand how things are going across the organization, understanding the pain points there, looking for commonality, right? You might be building something, your team is responsible for some product, service, some type of technology, and you're looking for advancing that and going, "Hey, how do our advancements in our tech stack, in our product, in our service, and our processes, how do they apply to the other teams? Can I champion this across other teams?" to give you a very quick example without going into details. I actually have something from my perspective like in in my own career where there is a process change that came up within our team which sounds kind of boring. it's a process change, whatever, but like it needs to be standardized because it's very important.

And I had feedback on this from my skip levels peer and when they were kind of like signing off on it, they went, "Wait a second, like this this seems important and it seems so important that we should be doing this across the organization, right?" So very interesting because the way that we were tackling it was like we're trying to be transparent. We need to document this process, make it official. And I actually had, you know, encouragement from a skip level's peer to say like not only like yes, does this make sense, but they almost didn't want to like sign off because they're going like we got to do this bigger like we got to go the full way.

So that's actually something I'm trying to lead right now and that will be across the organization to adopt such a process and that way other teams that don't have the exact same technology and have to follow the exact same process we can say we have a framework for this now this is the framework for these types of things for these types of processes that we're adopting and that will become across the whole organization. So in terms of impact it's for me at least as a software engineering manager I wasn't sitting there going I'm going to architect the newest greatest thing but there's even something in my work with some some things related to process that are going to be organizational and fortunately this was an example where someone else thanks to the visibility of it someone else went wait a second this should like my team will feel the benefit if we do something like So if you don't have those opportunities coming up, you need to go start creating them.

That's one way. Another way is you put yourself in a different environment. The reason I don't like jumping to this part, which is just put yourself in a different environment, is that that doesn't solve the problem because you might move to another environment that's similar and another one after that that's similar. I think it's good to try and build up the skills and sort of I don't know um the networking like all of these different things that go into how do I look at solving problems across the organization. It's going to mean like finding partners or like stakeholders, partnering with them, understanding their challenges, understanding their tech stack enough to see like where solutions for your team will fit in. But that like one of the challenges with doing this is that you need to start doing that on top of your normal work. Because if you start doing what I just talked about and you start slacking on your deliverables because the other stuff's taking time, that's not going to be good.

Right? This is one of the challenges when we talk about trying to break into the next role like the next level. When we're more junior, it is sort of the complexity of the things that you need to juggle is much smaller. Right? So when you're brand new as a junior developer, a lot of the time it's like, hey, we just want to make sure that you can become self-sufficient, right? We want to make sure that you're more comfortable pushing code. you're not breaking stuff every time you do it. We don't need to, you know, to to hold your hand the entire time. Ask questions, obviously, of course, but, you know, we want to get you to the point where you're starting to feel like self-sufficient. And then at mid level, you build on top of that. You start adding in more complexity, right? Slightly more ambiguity.

You might have a small project that you get to own end to end, right? Like that's cool. You start to become more autonomous. And then senior, you're stacking in more of this. Now you're getting to lead some of the things because you've demonstrated that you've been able to do it. But at principle, you have to do all of that and now start looking outside. How can you take these things and apply them to the organization? So I like encouraging people to try and focus on this. I I don't mean to make it sound like it's a trivial thing because it's not, but focus on this. Try looking for these types of things, but keep in mind you don't want to drop the ball on everything else that you're sort of committed to doing already. It changing environments may make that easier. When I say changing environments, that might be a different team, that might be a different company.

It might make it easier, but it's not a guarantee. So, it feels like a crappy thing for me to say, "Oh, just switch teams." Like, there's no guarantee it's going to be easier. But depending on the environment that you're in, just to give you an example, I'm not saying this is a rule or anything like that. I'm just using this literally as a talking point. If this person is saying, I'm basically only getting front-end work, and based on that, I find it very challenging to have organizational impact. You may want to change the environment that you're in so that you can be doing other types of work more naturally. And that way when you're trying to reach beyond your normal work that you're focused on to look for organizational impact, it's less of a stretch. So definitely want to build the the muscle and the skill to be able to go do that crossf functional cross organizational work.

You may need a environment change. And the other thing, and I always come back to this, and I said I was going to, is like conversations with your manager. So, I just want to pull this message back up to make sure my phone is like recent Android update just completely bricks my lock screen. Um, okay. Well, he said internally, but my manager wants to keep me focused on these repetitive tasks. it's probably because that's the need they have, right? So, like you got to have the conversation with the career opportunities and career growth, but if it's not there, if you're not able to do the repetitive stuff for your manager because that's what they need out of you and then on top of that do these other things, it's probably not a good spot for growth, right? And this person, I think, is kind of realizing that.

Not saying it's impossible, just might be challenging. The last thing I wanted to touch on was complexity. I was expecting his projects to be more complex than this was the feedback. Pardon my language. I think that's like a thing to say. I can understand perhaps where that's coming from. I don't know what types of projects were shared, but like complexity is the wrong measure. It's just we don't we don't want to build no one wants to build complex things. But I think where this might come from is like a lot of systems become complex. Is there a demonstration that this person can work in complex systems? Maybe that's where that's coming from. But like I'm not going to be wowed by someone building a project that's complex. Like it is the wrong thing to measure. So that feedback seems kind of funny.

But if we're trying to focus on like what what things can we extract that are valuable from this when this person's doing this reflection they said I don't feel very accomplished right they said um that set me back because I'm rethinking complexity in my work I don't feel very accomplished I just think complexity is the wrong measure so it might be the scale of systems that you built it might be the types of challenges or the types of problems you're solving aren't either novel, they're not at scale, they're not they're not sort of interesting for that level. They're not like level appropriate things to solve. I could see that it's like the I I'll frame it this way. The complexity of the problem that is an interesting measure, not the complexity of the projects though. So maybe maybe it's just the phrasing, but that's how I would say like if you change that the complexity of the the problem, sure.

But if you have a complex problem with a simple solution, that's like that's beautiful. So I I don't know. Maybe this like I I haven't, you know, had a one-on-one conversation with this person, which by the way, I think I may start offering that as a service. I'm just going to sprinkle that one in here. Um, I'll come back to that sometime. But I don't know if this person's now reflecting on this and thinking their their code, the systems they're building are not complex enough. That to me is not the right thing. Are you solving complicated problems and I will say again the problem itself may not have to be complicated. To give you back to my example, the problem I'm solving with a process change is not a complicated one. It's a pain and it's a pain across the organization in different ways, but the complexity, it's not that it's complex.

I just think it's the wrong measure. So, I wouldn't um panic too much about that for this individual, but I do think it might might be a reminder if they're reflecting on the types of problems they're solving. you know, I'm I'm gonna pick on this not just just because it was in here, not because I have this like mental belief of it. They were saying like they're very limited to front-end work, right? So maybe for them the types of front-end problems that they're solving that are repetitive, they're like that's not complex. It just isn't based on the nature of the work and they have a lot of experience doing that, right? So not only maybe the code and the implementation's not complex which we don't want anyway but the types of problems just aren't complex and that way you're not creating novel solutions to things and you're not having wider impact.

So I can I can see that but that just brings us back to the earlier conversation. So I won't repeat it but that's how I would interpret that feedback by the way. So for the person that sent this in, I don't think it's complexity of your code or your implementations. But I hope that helps. It's a challenge. Like I said at the beginning, it's a challenging thing to talk through because I find like that's the advice I would like to give here. And I realize it's pretty high level. You can't walk away from this being like cool, I have a, you know, three-step action plan to go become a principal. But that's how I would frame all that. So, I hope you found that helpful. Friendly reminder for folks if you watched all the way to this point that if you have questions that you'd like answered, please leave them in the comments below or send them into dev leader on social media or my LinkedIn is just Nick Constantino.

It's a premium profile. You can send me messages all you want as far as I know because I get them. Um, and I should have the code.com site up soon in terms of sending in questions. It's actually what I was working on this evening after the live stream on Dev Leader and then I said I should probably film this video because I want to get this out for this person. So, thank you so much for watching. I will see you in the next one. Take care.