Why Developers Lose Their Edge When They Get Promoted

Transcript is auto-generated and may contain errors.

Hey folks, we are going to the experienced dev subreddit for this topic and this one is how do you stay technically sharp when your role becomes more strategic? And I thought this would be a good one because I can speak a little bit from my own career experience uh going from a software developer to an engineering manager. But also I figured this would be good um like we can try to change the context not just from that kind of transition but just even from you know being a junior mid-level into senior developer and then as you're going into senior and beyond where you start finding that you're doing more uh a little bit more strategy versus just a little bit more focus on the tactical kind of stuff. So hoping that kind of context will be useful and let's dive into it.

So for a little bit of background for me, I when I graduated from university and I was working at a startup sort like literally just out of necessity moved into a engineering manager role pretty quick. Um in hindsight like that's kind of a I don't want to say it was silly for them to do cuz we were a startup and we just kind of did what we had to do. But uh I I worked as an engineering manager, you know, uh about a year into my my full-time employment. But as a startup, as a you know, smaller teams and stuff like that, I certainly still operated like directly in the code base. And I did that for for 8 years. And I think in that kind of experience, I struggled the entire time not with uh purely how to stay technical while being more strategic because I was kind of forced into the code.

I I worked all the time like I just had like unhealthily long uh work days and work weeks um to sustain like that kind of time. Uh so I didn't have the issue of like how to stay technical but certainly my time balance uh could absolutely feel like was pulled more towards strategy. there was no no way out of that like you needed to be able to do that uh in that kind of role and then especially as the company was growing um I felt you know every every year that went past like more strategic kind of involvement and the side effect of that is that as you're pulled into more things like that inevitably you're spending less and less time with your hands in the codebase the only the only way out of that is to add more hours into your That's just kind of what it is, right?

Like at some point your time is more valuable doing strategy if that's the sort of direction you're on. And that's totally fine. It's not wrong. It's just that you have a time balance. And if you're spending more time doing strategy and less time hands in the code, what does that mean for everything in between? Because you could argue those are sort of like two opposite ends of the spectrum. So this person's question about like how do you how do you stay technically sharp? I think the first thing to consider is like what is uh expected of you in your role. Okay. So uh I I would say that for myself as an engineering manager the expectation in my role is that I not that I can like just not be technical anymore. That's not the case.

But the the the very specific details, it's it's uh it's expected less and less of me that I need to know the specific details because the scale of what we're doing in terms of like or I should say the scope of what we're doing, not scale, the scope of what we're doing in our roles just means that you can't possibly know every single technical detail. And that's fine because you have engineers on your teams that are literally living and breathing some of those areas and that's that's their focus. But if you're kind of in between and you're so I'm realizing, you know, not not everyone is talking about going from developer to engineering manager. You're a you're a tech lead, you're a team lead, you're just you're someone who is in a senior role or going beyond senior and you're having more strategic conversations, right? How do you stay technically sharp?

And so when I say you have to understand what's expected of you in your role, I mean literally like think about even the strategic conversations you're having, right? If if you're having these strategic conversations and you're like, I don't actually know what technology we're talking about here. I don't understand it or um you know part of your strategic conversation is regarding a technology that you do understand but you have literally no concept of like what your product or service state is in with its tech stack. Like if you're in these strategic conversations and realizing like I don't actually know what I'm talking about and uh if you're thinking about those situations and you're like every single time you need to have one of those conversations it's always like well I can't say anything about it. I I need to go pull someone else in. That's probably a sign that you're there's like a bit of a technical gap that you got to start closing.

And I'm not saying that it's wrong or bad. If there is a uh conversation happening and there is something technical that comes up and you're like, "Hey, for this I have to defer to so- and so because just genuinely they will be able to speak much better in this context because that's something they've been either focused on recently or something that they've worked really in depth on. It's not wrong to say that, but I would say if every time you're having a conversation that involves something technical and you just don't feel confident to be able to speak to it, it's probably a good litmus test that you need to go brush up on some things, right? So, I don't think this is uh from my perspective not a a black and white thing like you know, you can set a a firm rule for everyone. Here's how much time to spend.

Here's what that looks like. But I think depending on what you're doing, the expectations of you in your role and how often you find yourself in this position where you're like, you know, I need to have this strategic conversation that involves technology and I just don't feel confident about anything I'm saying. Like to me, that is a good litmus test that probably need to go figure some things out. So like what what does that look like, right? I think a bunch of things. And again, this will depend a ton on different circumstances. Uh I'll even share just like one very recently that's kind of in my mind right now. I had um I had a a team member uh switch to another team very recently and uh so he he has with him a ton of deep technical expertise, a lot of history in the

codebase and his departure uh like obviously very bittersweet cuz I'm very excited for him but at the same time like that's going to be challenging for us uh because he does have a lot of that expertise uh and and history in this codebase. So, what's going through my head is like at least in the immediate term, I I think that I probably need to go start stepping into the code base. It doesn't mean that I have to go, you know, I'm going to queue up features for myself necessarily or bug fixes, but but maybe, right, I haven't had to do that on on my teams at Microsoft. uh I manage currently uh sort of three sub teams across across our routing plane but in three uh very sort of different areas. And so for me like from a strategic perspective, from a management perspective, it to me it makes no sense um to be focusing my time on feature development.

there's far like there I already don't have enough time in the day to go do what I feel like is expected of me in my role but given this team change I I also think that I almost won't have a choice in the immediate term that I need to have more familiarity and that comes from the fact that in a lot of these deeply technical conversations um I had someone who was facilitating that Right. So I for the way that we've been operating I knew enough in the strategic conversations I was having and then when it got beyond my technical understanding I could say like no problem I have a tech lead in this position and not only do I think like he will know and could answer but I also think he is the right person to answer because in some of these conversations I don't think it's a matter of me just giving the other person or the group an answer.

I think it's important for this person to be involved because it's not just information one way. If he hears the context, he might say, "Oh, you know, you're asking for this, but I actually think you mean that instead and that here's why this will be a better option." That kind of thing. So, having someone in a role like that is very valuable for me as an engineering manager when I'm spread across multiple teams. But you might be this person right like you might be this person that is uh or working towards this kind of role where um you are pulled into more strategic things and like how do you stay technical so I think in those cases um will depend a lot on how your teams and stuff are structured but I do think that if you guys do design reviews um even if they're

outside of your direct area so to give you an example I was mentioning I have uh three sub teams and in my broader team there's a couple of additional sub teams that I don't manage. So when they do design reviews, yeah, it's good for us to get pulled in. It's good for me to go see like even things that I don't manage that I'm not directly responsible for so that I can have a better technical understanding like by being exposed to different areas more regularly. That's minimum kind of surface area that I recommend for getting uh a better understanding right it doesn't make you an expert in the area but it means that at least in some conversations you can start to go oh like I have heard you know this topic come up I have heard about this technology being used I do know

where it's being used or where we plan to use it uh and at a minimum it's like I know the other people involved that I can go pull in right so I think that's what I recommend like purely as a minimum is just more exposure to being part of design reviews. And again, that can look like, you know, depending on how you do them with your team or organization, are you part of designing with them? Are you part of uh like a review panel or like are you part of just listening to uh or following up on designs that have already been, you know, signed off on? Can look like a million things, but that's one. Another is uh depending on your uh code review and pull request kind of structures you can do a similar thing right so how do you make sure that

you're not gating everyone's reviews but you're getting more exposure to uh to code changes around you okay more it's like my general recommendation that is like the minimum is like the surface area to expose yourself to these types of changes because if you remove that surface area like just to give you an example imagine from an engineering manager perspective imagine they never put engineering managers on any code review or pull request right it would mean that in order for you to even be aware that that stuff is happening as an engineering manager you'd either have to go manually go look it up and hope that you come across changes or ask people But instead, if you're automatically on them, not necessarily to gate every single one of them, but if you're at least automatically exposed to them, the surface area of like opportunity for you to follow up on these things is much greater.

So, those are two very highle things that I recommend. Um, I do think too that I think about some of these conversations that I've had over years of being in in a manager role where um, you know, you'll be talking like it's pretty common in software engineering that most I want to say like most people are pretty technical. even um I know there's going to be some people like oh I had a manager that didn't know anything or a you know a product or project manager that didn't know anything technical and I get it or even developers that weren't technical but statistically most people are probably going to be pretty technical like I I would feel safe to make that generalization and the side effect of that is that when you're having conversations even around strategy is that say you're having a a strategy conversation or you're brainstorming uh with a couple of people that are not, you know, maybe they're not even software engineers as their their role and they are technical.

They do have a technical background. Maybe they were software engineers at one point uh as their, you know, their full role. When you start having these conversations, inevitably it gets into like some type of design. It might be wrong, it might be super high level, but it's it's probably happening. So, what I would recommend is if you find yourself in these types of positions where uh you aren't, you know, if you're honest with yourself, you're like, I'm not the expert on this and you're sitting there, it's like because you don't have the technical expertise, um try to get the other engineers that are the technical experts pulled in early and work with them, right? Because you can do a couple of different things here. And one is like you don't pull them in early. You try to, you know, design things because you're going, well, I need to have some responsibility here, but like you don't have the technical expertise and it's probably not a great idea for you to design it because of that.

So, you can flip the entire opposite way and go, okay, well, let me just fully delegate it to someone else and I'll go move on to something else. But then that perpetuates this problem of you never really getting that technical exposure. So I do recommend early you identify, hey, this isn't my area of expertise. I do want to know more about it because I feel uncomfortable being able to, you know, represent this technology choice or, you know, factor in things for this design. Let me pull in Bob. You know, Bob happens to be uh what I would consider an expert here or our closest expert to it. Let me pull in Bob early and Bob is going to work with us on this, right? Or I am going to work with Bob on this, not I'll just give it to Bob and disappear. Because the next time you find yourself in this exact situation, you're just going to say, well, I need Bob or I need whoever, right?

Like I don't have the technical exposure. So that's one of the ways that personally I find that uh you know when I catch myself in these situations where conversations heading down a path and we're starting to design it's like wait a second like if we're already going down this path maybe uh let's consider if we need to start pulling in engineering and work with them. So that's a pretty common one that I've experienced in my career. And I'll switch things up a little bit because some of the things I've been talking about are like specifically um I don't know like things at work and that might vary dramatically from like I was saying place to place your team structure whatever it is. Um, so hopefully so far a couple of those things seem like they make sense.

But the other thing might be like, okay, like most of your workday, let's say, is shifting from uh a majority of coding time like it used to be to to more and more strategy, different meetings, conversations across teams and stuff like that. And you're going, I'm just making this up, right? Like if my workday was 8 hours and uh I feel like I used to code six of those 8 hours uh and now it's only like feeling like two to three uh or even less depending on you know the week and stuff like that. Um and you're going oh crap like am I staying technical enough? there is the opportunity for uh you know if you have time outside of work what are the areas uh that you are feeling like you're falling behind on and you could at least try doing like I will

always recommend side projects to people and people freak out about side projects because they're like oh well I shouldn't have to do that because you know come up with any reason I'm just saying like if you feel like there's a gap and you don't have time for it at work or there's no opportunity um I would at least try building something related to it. Doesn't have to be something you ship. Doesn't have to be even something that you know fully works in the end, but just getting some exposure working with the technology in some capacity, right? You never use Kubernetes. Cool. Deploy something with Kubernetes. Go like try something with it. doesn't hap like you've never used blazer, never used Maui, never used uh I used uh Vite the other day like have a just did a website with Astro over the weekend. Um you if you don't know these things like try doing something with it, right?

That's always an opportunity. I realize people don't like that because it's outside of work, but uh we have it. There's one more thing I thought of that was at work while I was rambling and I was like, "Don't forget it." And I forgot it. So, let me have a sip of water and see if it comes comes back once the caffeine hits the lips. No, you failed me. Caffeine. Um, staying technical, I had a good idea and it's escape me, but whatever. That's a side effect of filming these things live in a car. Um, was it specific to code? Anyway, I forget. But yeah, I think it's a challenging thing that a lot of developers are going to go through, especially as they're finding that they're uh gaining experience, their roles are evolving, and they're pulled into more different conversations. So, I guess don't panic about it.

It's kind of a natural thing. Oh, this is what it was. I wanted to talk about trust very briefly. I think the other thing too is like people can panic about this kind of stuff because, oh, I'm not technical enough or I'm losing it or whatever. And there's going to be pieces of this in your career that genuinely you have to start trusting other people to be able to have the more deep knowledge and experience. It's not wrong or bad. So I I wanted to talk about trust because I think that it's important to recognize that it is literally impossible from a scaling perspective. Say you're deeply technical in an area. Okay, you are the go-to person. You know all about it. You've been doing this and then you're you're early in on your team. You're building all this stuff and like you are the go-to person for more and more things and more and more things over time as you're gaining experience and responsibility.

It becomes literally impossible. Whoa, popped my mic off. I lost the fuzzy buddy on top. Becomes impossible to maintain the um sort of that level of deep knowledge and expertise across everything and scale yourself. It simply just does not work. And so my thought on this is that you need to be able to trust that other people do have that. Okay. So it's kind of a counter point to what this person was asking like how do you stay technical? Um I tried to give you a couple of examples of things you can do to increase the service area for uh being engaged in technical discussions. But the other thing I want to remind people is like it will be a natural thing that as your scope increases, you simply cannot be as deeply technical in every single thing you're doing. And you'll drive yourself nuts if you try to do that.

And you may turn into one of those people that tries to gatekeep everything to block things cuz you need like force yourself to be involved so that you can be you know deeply responsible and understand all these things. At some point it doesn't scale. Okay. So just try to keep that in mind. Uh especially if uh you are someone kind of moving into management or more leadership positions like you have to be able to trust and let go a little bit. It doesn't mean that all of a sudden everything technical gets erased from your brain, but understanding how much technical depth you need to have and what that looks like and what's most effective for you and your team and your organization, I think makes a big difference.

And if you don't pay attention to that, I think that you'll find yourself on like weird sides of this where you're like, I have no technical expertise or you're the opposite being like, you know, like you're you're not doing the rest of your job effectively as a manager or like a strategic leader because you're trying to be so technically involved that you miss all the other pieces. So, hope that helps. That's my thoughts on that. If you got questions, comments, leave them below. Otherwise, you can go to code.com. You can submit your questions about software engineering career development anonymously and I will see you in the next video. Take care.