The Management Trap in Software Engineering

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the experienced dev subreddit today for a topic. This one was titled the management trap. And uh I guess this engineering manager was talking about some of their progression in their career and uh how they've kind of arrived at this point or this realization where they're missing a lot of like the I guess like call it the joy of of doing like of the type of work or the type of like hyperfocus that they feel like they used to get as a uh more of an individual contributor. here. And uh I guess total disclaimer, right? Um you know, there's going to be all sorts of different thoughts uh perspectives and experiences that will come up uh of course like obviously in Reddit threads and uh that I will try to make sure that we we focus on on this channel. So in this case, it sounds like there's it's not like a tiny organization.

um it's not like say a startup with 10 people uh you know like one single team or something like that. It sounds like there's a at least a bigger organization here. So uh some of the stuff that they're talking about how they're spending their time sounds like the side effect of being in a larger scale organization and having to to do work across uh teams and headcount planning and stuff like that. All this kind of stuff is like it's applicable even in small companies um for sure. It's just the the amount of time, effort, and focus that goes into those things I would say varies uh dramatically based on the scale of a company. Um probably the uh I don't know the the the lifetime or like where where a company is at in their uh their existence probably has a huge factor here. Um, yeah.

So, anyway, this this person's point was kind of like most of their time and energy is spent on on things that are kind of more spread out, kind of more sporadic. Uh, little bit more chaos. Oh, these people. You're blocking the intersection. Too bad. We'll go around you. Um, and I do think that's super interesting because they I think sometimes when we're kind of looking at situations like this, it's like it's almost easy to say uh like see like would have would have been better off as like a technical person as an IC doing individual contributions but they do say like they really do get enjoyment out of like you know helping people uh in career progression. promotions and stuff like that, like that actually gets them very excited and they're happy to see that. So, like I think that's goodness.

Um, but interestingly overall, um, kind of when they're reflecting on their time allocation and what what things look like on a day-to-day basis, it's like uh really it seems like a more I I would just call it chaotic. And uh I don't I know chaotic probably sounds like a a negative term and I guess it's not necessarily positive here, but I don't mean it like either this person's doing something bad or the organization's bad. I genuinely just mean like your context switching and focus can change a lot. Um, and it's also worth mentioning because I think this is a factor too that uh this person is a frontline manager. So they are talking about how like their senior manager promotion is uh something that's been talked about but never really seems to to happen, right? And so this is something for me personally that resonates a lot.

Not not that my senior manager promotions like uh been talked about especially like at Microsoft that's not the case. Before Microsoft basically uh was at a smaller company so director position was you know being discussed. Uh but that's like 5 and 1/2 years ago. So I I've been a frontline manager for 13 and a half years. So uh I can I can get what this person's saying for sure. And I think one of the the other things that I if I had to make an assumption about this person is that um if they find that they are context switching a lot, there's probably this like it's a pretty typical frontline manager um situation to be in like you are kind of shielding two directions or like uh people will say like you're you're taking from both sides kind of thing where you are trying to uh provide some kind of isolation to your team so that they can stay focused on priorities, they can stay effective, right?

So that means that you know random asks or random disruptions and stuff like you try to get in the way of that so that your team is not completely randomized so that they can genuinely focus on priorities as much as possible. And the other way is like obviously if you're trying to stay in touch with your team, understand them, listen to them, that means there's going to be parts of uh you know operations organization that they have feedback on that probably should find ways to bubble up and and you represent your team. So you have things coming from both directions, right? Even if you were to simplify it just to product roadmap, right? you're going to have pressure coming in from from one side and you're going going to want to be working with your team to make you know that product roadmap a reality

and then the other way you're going to have push back from your team on some things and and again rightfully so I don't think that this is it's not like a negative I'm not saying like therefore management sucks or it's the hardest or it's terrible I just mean these are these are normal types of interaction actions, but the reality is yeah, you get you kind of get friction from multiple angles. So I just I thought it was very interesting that this person's reflection was kind of like hey there are parts to management that yes I do like but overall kind of missing this ability to or like the opportunity to to hyperfocus on something and just like uh I don't know like get into it and feel like I'm delivering and making progress on it. and I scanned the the comments a little bit and um yeah, I don't know.

I think I think something that was coming up for me thinking about that was like some people that were like, "Hey, like can appreciate that you actually uh like understand some of the things that go into management and like you do those things because I guess uh some of the developers on the thread were saying like it's very seems very common to them that managers just aren't doing those things." Um, someone was jokingly saying like, you know, uh, wipes tears away with uh, $100 bills because this person was like, "Hey, I get paid well, but like the the joy isn't really there." Um, but I when I was reading through this, like one of the things that came to mind for me was like like part part of me also does kind of miss that too. The other day I was kind of talking about like uh almost like some ADHD type stuff and I I don't know.

I find that I find doing a lot of context switching for me can be okay, but when I'm context switching to a lot of things that I don't love, like if the overwhelming majority of things is like context switching to uh types of problems that don't get me excited, then that context switching like feels very very very uh taxing. Right. Context switching obviously has overhead, don't get me wrong, but um there uh just to give you an example, like when I'm working on on security related things, sometimes there's a lot of context switching and that that can be chaotic. But in terms of like a a burnout kind of feeling or like being exhausted, I don't have that as much even if there's a lot of context switching. And it's because to me that's exciting work, right? Um the context switching to say like jump in and and help some of my my employees on some of the technical uh challenges they're working through like that can be exciting.

I think you know having having focused Oh, let me uh give you a counter example. having focus time to sit down and be mindful and thoughtful of working through like interpersonal challenges or career progression with employees like that feels good. But doing uh like uh rapid context switching for that kind of stuff does not feel good to me. Like that is a very taxing very much like don't like doing that. Um, so it's it's kind of interesting that it's sometimes not even the the nature of the the challenge or the scenario, uh, but it's almost like how much how much context or preparation I have that can that can really dramatically change that for me personally. So, one of the related to what this person was talking about though, like one of the reflections that's been kind of top of mind for me, and I

don't have like answers on it, but just like something that I've been thinking about is the I I genuinely believe that I think I said this in one of the recent videos I made, but uh I I genuinely believe that for me to be effective as an engineering manager means that I need to enable my team to do their best work possible. And so I do believe that in in a short to medium term that if that means that I have to be more randomized so that I can sort of shield the team and allow them to focus on delivering things. To me that makes a ton of sense. What doesn't make a ton of sense is that if that work is not acrewing to uh you know to sort of unblocking me from having to do that that's not a good strategy because it

means that like just to give you an example if I were to step away from my team right I would uh at least from an operations perspective I I feel successful in in my role from an operations perspective if I can walk away and my team can completely operate on their own which sounds kind of funny. Um my my goal is obviously to help them all grow in their careers. So that's if I walk away like I'm not fulfilling that part. But from strictly from an operations perspective, they shouldn't need me, right? That's a it sounds like a bit of a stretch because it's like a little bit uh unrealistic, I guess, cuz it almost implies like I'm not doing anything. But the point is that I like if you if I strive towards that direction, right? It means that we are doing things that allow the team to be entirely self-sufficient.

That is my goal. So if I basically what I'm saying is like if I can in a short to medium term you know uh take the take the chaos for the team and allow them to focus on you know building whatever we need whether it's process services tools you name it. If they can focus on that, then um then they're they're part of sort of creating uh a team that doesn't like need me to be in that position doing that. So, it's all about that being like hopefully, you know, short to medium-term kind of thing. And then we become more self-sufficient in in some area. And uh and then perhaps as we expand and grow, we move on to the next thing where it's like, hey, look, like this is more manual. This is more painful. This is new for us. And it's like, cool. Again, let me let me shield you from the so that you can focus on on doing truly the important work.

Right? That that's sort of my goal, my mentality. Um and the the side effect of that though is that if if I am trying to do that for my team and it's it's being circumvented in whatever fashion right so whether that's because uh I don't know like there are organizational asks that are you know critically urgent whether there's some incident whether there's uh security stuff like you name it, right? If there's other things where I genuinely cannot uh I'm using the word like shield or shelter. Um I don't mean that to like suggest like hiding things from my team. I mean like removing distractions for them. Um, if there are things like that that I just truly cannot do, then what's ultimately happening is that it kind of perpetuates this time of like how much can I take for the team so that they can operate uh effectively.

And so the longer that drags out, the long or like you know, the longer and more difficult it is for me to sustain that. It's supposed to be it's supposed to be ideally temporary, right? um and then the team can focus on the important things to move us forward. So, I've been thinking about that a lot recently like um you know it's not just a matter of like let me let me shield the team, let them focus on things. I think sometimes there's more to it that I have to do. And like just to give you like one example, right? Like one of the things that I've been trying to make a little bit more noise about just uh like in a in a general sense is this like concept of fan out work. And so like we're in a large organization and because like we're a platform team there are other sort of platforms and stuff that that we use other services use.

And so what happens a lot of the time is like because the surface area of these things is so big uh you know a team that owns something will say like hey there is a change and like we need all of you to go make a change. So, like the work fans out to different teams. And I've been starting to try and make more noise about this because in my opinion, this is one of the most unscalable things that you could possibly ever do. Ever. And I think that uh it's not that it like cannot work. Like yes, we've I've literally lived through it many times where it has air quotes worked, but I think it's one of the most inefficient things that you could possibly do. And I say that because it's not that it's one team that fans out work to other teams. It's multiple teams fanning out work to other teams.

And so that kind of I don't know like randomization or interruption is like to me one of the most negatively impacting things from a productivity perspective that I've I've ever experienced in my software engineering career like by far. That's not to say the work's not important, right? Like don't please don't confuse what I'm saying. It's not that it's not important. It's not that we don't want to help. It's not that whatever. It's it's that it's the most disruptive work that could possibly happen. I shouldn't say exactly that way because I'm sure someone could say, "Well, what about this?" and prove me wrong. But, uh, from my experience, that's the most disruptive kind of work that comes up. And so, not only is it a matter of like me trying to, you know, provide some kind of insulation for my team, but I need to look at the patterns that are coming up, right?

If like if I'm like, okay, this has been going on for too long where I'm like fan out work is like the like one of the big things like I owe it to my team to to push back and say like to the rest of the organization, something has to change here. And that doesn't mean that I'm going to necessarily have the solution, but if I'm going to make noise about it, then I need to be part of coming up with the solution or at least volunteer myself to be coming up with part of it. So that's like that's one example, right? So um the other thing in general like if we sorry the other thing to think about is generalizing that which is essentially if I'm repeatedly doing this kind of thing for a team I need to be thinking like wait a second

like my team is trying to do work to help make us self sustainable but if the work they're doing is not going to uh impact that like I need a different strategy to to try and reduce like sort of that storm that's coming in. I'll give you another example I've talked about before when I go back to my my days like at a at a startup and very uh you know similar kind of thing where the the CTO would and founder would would come by and be like hey like this is urgent this is urgent we have to do it um especially in the early days we would drop everything we're doing and you know it would just be kind of randomizing and then I would try to kind of step in and shelter the team and over time we kind of came up with

this sort of I don't know like unwritten like contract I guess where when we were being approached this way it was like look like we're not going to drop everything we're doing let's talk about it let's let's explain what we're doing right now let's give you visibility into that and then ultimately if you're like no I like I disagree that those things are the top priority. I do think you should drop this other thing. Then at least it's a conscious decision. So like you know having interruptions like that as part of our uh like feature development and and sort of software development process like being able to push back on that and kind of make that more systemized I think was was really important because the team would have been working on other things in general that help us make us more effective but ultimately we need something to be able to uh to sort of filter those interruptions.

So, being able to push back on that for my team and establish something like that would be really helpful. So, yeah, it's it's just interesting because the when you're spending so much time trying to uh sort of firefight for your team so that they can focus on things. the there's another balance to be struck which is like how much can I get ahead of preventing such fires from coming in the first place. The ones that my my team are not directly you know actively working on trying to solve I need to find uh capacity to be able to to come up with solutions for those things. Anyway, that was a bit of a tangent from what I guess the original post was about. They were talking more about it being a trap for managers like where like now they're not able to focus on like hyperfocus on things like they could as an IC.

I don't know. I think it's going to be different for everyone. I do I do definitely miss some of that kind of stuff, but I I also think that I get a lot of that outside of work for me and I enjoy that in my outside of work time. Um yeah, I don't know. I think that maybe one one last kind of thought is that I I do think that uh at least in a role like mine right now when I have multiple teams and I don't feel like I have enough um sort of capacity on each of my teams. That to me contributes a lot to um sort of what this person's talking about more on the Reddit thread. And that's because it requires me to be even more um even more like I'm gonna use the word randomized, but I mean like it causes me to have to context switch a lot more um because I have fewer people to rely on.

I have amazing people on my teams, but I have fewer of them than than what I would like uh to be able to like effectively sustain uh effectively sustain without me needing to jump into various things. And that's no fault of anyone's. That's mostly just like the side effect of I don't know like org growth. Um so yeah makes it challenging but I do think that um you know if there's any any takeaway from this is like it's just this consideration that like yeah a management role is not the same as an IC role. It does not make it better does not make it worse. It is it's a different role. It's in it's in software engineering very much like how a product manager or a project manager is also something in software engineering. um it's it's just different. So something to think about especially if like if you're thinking about your career where you want to go like uh things that you're trying to focus on.

Um I think there's some people in their careers where they the promotion that they are offered is a management position and that sounds attractive and it very well might be and you might love it and it might be a great fit for you. But I would I would kind of uh urge you to to understand um more about the differences in in what managers in my opinion what managers should be doing and focus on versus as an IC what that looks like because it is different. So hope that helps. I realize it's maybe all over the place but some different perspective. So thanks for watching. If you got if you got can't speak. If you got questions about software engineering or career development, you can leave them below in the comments. Otherwise, go to codec commute.com. You can submit stuff anonymously that way and I'm happy to try making a video response for you and hopefully it helps.

See you in the next video. Take care.