The Management Trap in Software Engineering

Dev Leader Weekly 143

Jun 08, 2026

TL; DR:

Management is a different job, not a promotion
Not all context switching drains you equally
Absorb your team’s chaos -- but keep it temporary
Join me for the live stream (or watch the recording) on Monday, June 8 at 7:00 PM Pacific!

The Management Trap in Software Engineering

This week’s topic comes from a post on the ExperiencedDevs subreddit titled “the management trap.” An engineering manager was reflecting on their career progression and how they’d arrived at a particular realization: they’re missing a lot of the joy -- that deep, hyperfocused, heads-down work they used to get as an individual contributor. As someone who has been a frontline engineering manager for over thirteen years, this one hit close to home, and I want to walk through my honest take on it.

You can check out my full thoughts on this in the video below:

Where This One Is Coming From

I want to set the stage a bit, because context matters here. This isn’t a tiny startup with ten people on a single team -- it sounds like this person is in a larger organization. A lot of what they describe about how their time gets spent is the side effect of scale: cross-team coordination, headcount planning, all of that. That stuff exists in small companies too, but the amount of time, effort, and focus it demands varies dramatically based on the size and the stage of the company.

The other detail that stood out to me is that this person is a frontline manager. They mentioned that a senior manager promotion has been talked about but never quite materializes. That resonates with me, because I’ve been a frontline manager for about thirteen and a half years now. Before Microsoft, I was at a smaller company where a director role was on the table -- but that was five and a half years ago. So when someone says they’ve been sitting in the frontline manager seat for a long stretch, watching the “next step” stay perpetually one conversation away, I get it.

And here’s the honest tension in their post: it’s not that they hate management. They explicitly said they get genuine enjoyment out of helping people with career progression, promotions, and growth. That part lights them up. But when they zoom out and look at their day-to-day, it feels chaotic -- scattered, sporadic, a lot of context switching -- and they miss the ability to just sink into one hard problem and feel like they’re making real progress on it.

Management Is a Different Job -- Not a Better or Worse One

If there’s one thing I want you to take from this issue, it’s this: a management role is not the same as an IC role, and that difference does not make it better or worse. It’s just different.

That sounds obvious written down, but I don’t think it actually lands for most people until they’ve lived both sides. Engineering management is its own discipline within software engineering -- the same way a product manager or a project manager is something distinct within software engineering. It’s not “senior engineer, but with more authority.” The work itself changes shape.

A lot of people hit a point in their career where the promotion that’s offered to them is a management position. And that can be fantastic -- you might love it, it might fit you perfectly. But I’d urge you to understand what managers should actually be spending their time and focus on before you assume it’s just the natural next rung on the ladder. I went deep on this in I Wish I Knew THESE Before Becoming A Manager, and a lot of it comes down to expectations nobody sets for you up front.

Not All Context Switching Costs the Same

Here’s a nuance I don’t think gets talked about enough. The Reddit thread frames the chaos as the problem -- too much context switching, not enough hyperfocus. And I get that. But when I reflect on my own experience, it’s not the context switching itself that wrecks me. It’s context switching into work that doesn’t engage me.

Let me give you a concrete contrast. When I’m working on security-related problems, there’s often a ton of context switching, and it can get genuinely chaotic. But I don’t walk away from it feeling burnt out, because that work excites me. Jumping in to help one of my engineers work through a gnarly technical challenge? That can be energizing, even though it’s an interruption. On the flip side, sitting down with focused, prepared time to work through interpersonal challenges or career progression with someone -- that feels good. But being rapidly context-switched into that same kind of work, with no runway, is incredibly taxing for me.

So it’s often not even the nature of the task that determines the cost. It’s how much context and preparation I have going into it. I talked about a closely related version of this in last week’s issue on ADHD, burnout, and building a career that fits your wiring, and the mechanics of why switching is so expensive in the first place in The Context Switching Problem Every Dev Faces.

Actionable Tip -- If you feel perpetually drained by your week, don’t just count your context switches. Audit what you’re switching into:

Which interruptions leave you energized, and which leave you hollow?
How much of the draining stuff is draining because of the task itself vs because you had zero preparation for it?
Can you batch the low-context, high-cost work into a window where you’re actually braced for it, instead of letting it ambush your focus blocks?

The Part of Management I Actually Believe In

This is the piece of the conversation I have the most conviction about. I genuinely believe that to be effective as an engineering manager, my job is to enable my team to do their best possible work.

In the short-to-medium term, that often means I have to be the one who gets randomized so that they don’t. When chaos comes in -- an urgent org-wide ask, an incident, a security fire -- I’d rather absorb the initial hit myself than yank three engineers out of their flow. I sometimes describe this as shielding or sheltering the team, and I want to be clear about what I mean: not hiding things from them, but removing distractions so they can stay locked on the work that actually moves us forward.

But absorbing chaos is only a good strategy if it’s accruing to something. Here’s my litmus test: from a pure operations standpoint, I feel successful in my role if I could walk away and my team could keep running entirely on their own. That sounds almost paradoxical -- like I’m saying my goal is to not be needed. From a career-growth standpoint that’s obviously not the whole picture, because I’m here to help every one of them grow. But operationally, the target is a team that doesn’t depend on me to function. I dug into this idea of self-sufficient, autonomous teams in Effective Software Teams: Islands and Autonomy.

The real trap -- and in my opinion this is the actual trap, more than the “I miss being an IC” framing -- is when the chaos I’m absorbing isn’t moving us toward that self-sufficiency. If I’m just perpetually soaking up randomization with no end state where the team gets more autonomous, that’s not sustainable. It’s supposed to be temporary. Take the chaos, let the team build the processes, services, and tools that make us stronger, and then we don’t need me in that spot anymore -- and we move on to the next frontier together. The flip side of this is a real risk worth naming: if you become the only person who ever absorbs the chaos, you’ve built a fragile system around your own bandwidth, which is exactly the failure mode I broke down in The Hidden Cost of Being the Team Hero.

Fan-Out Work Is the Most Unscalable Thing I’ve Seen

Let me give you the specific pattern that’s been on my mind, because it’s the clearest example of chaos that doesn’t accrue to anything good. I’ve been trying to make more noise about it lately: fan-out work.

We’re a platform team in a large organization. Because the surface area is enormous, what happens constantly is that some team owns a thing, a change lands, and the message goes out: “everyone needs to go make this change.” The work fans out to dozens of teams. And it’s not one team doing this -- it’s multiple teams all fanning work out to each other simultaneously.

In my opinion, this is one of the most inefficient, productivity-destroying patterns you can possibly have. And I want to be careful here -- I’m not saying the work isn’t important. I’m not saying we shouldn’t help. I’m saying it is, by a wide margin, the most disruptive kind of work I’ve encountered in my software engineering career. The randomization it injects across an entire org is brutal.

This is where being a manager means more than just personally absorbing hits. If I notice that fan-out work is a recurring theme, I owe it to my team to push back to the broader organization and say, “something has to change here.” That doesn’t mean I’ll have the solution in hand. But if I’m going to make noise about a problem, I need to volunteer to be part of building the fix -- not just complain about it.

Systematize the Interruptions Instead of Just Absorbing Them

There’s an older example I come back to a lot. Back in my startup days, the CTO and founder would come by and say, “this is urgent, we have to do it now.” Especially in the early days, we’d drop everything and get completely randomized. I’d try to step in and shelter the team from it, but over time we landed on something better -- a kind of unwritten contract.

When we got approached that way, the new default became: we don’t just drop everything. We talk about it. We’d explain what we were currently working on, give visibility into the tradeoff, and then if the answer was still “yes, I genuinely think you should drop that other thing,” at least it was a conscious decision made with full context -- not a reflex.

That shift, from reflexive interruption to a deliberate, systematized filter, was hugely important. The team was almost always working on things that made us more effective in the long run, so being able to push back and force the interruption to justify itself protected the work that mattered.

Actionable Tip -- If your team is constantly randomized by “urgent” asks, build a lightweight filter instead of absorbing each one in the moment:

Make the current priorities visible, so any new ask has to be weighed against something concrete.
Push the interruption to be an explicit decision: “we can do that, but it displaces X -- is that the call you want to make?”
Capture recurring interruption types (like fan-out work) and treat the pattern itself as a problem to solve, not just each instance.

Firefighting vs Getting Ahead of the Fire

The other balance I’m constantly trying to strike: how much energy goes into firefighting for the team, versus getting ahead of the fires so they don’t start? When I’m spending all my time absorbing the chaos of the moment, I have nothing left to invest in preventing the next wave of it. And the fires my team isn’t directly working to put out -- those are exactly the ones I need to find capacity to address myself.

I’ll be honest about a compounding factor here, too. When I’m running multiple teams and I don’t feel like I have enough capacity on each one, that’s a huge contributor to exactly the scattered, randomized feeling the Reddit poster described. Fewer people to rely on means I have to context-switch even more. I have genuinely amazing people on my teams -- just fewer of them than I’d want to sustain everything without me jumping into the gaps. That’s nobody’s fault. It’s mostly the side effect of organizational growth, and it’s something I covered from the IC angle in More Experience, More Overwhelmed.

If Management Is the Promotion In Front of You

So let me bring this back to where the Reddit poster started. They framed it as a trap for managers -- losing the ability to hyperfocus the way they could as an IC. And honestly? I do miss some of that. But I’ve also found that I get a lot of that deep-focus satisfaction outside of work, and I genuinely enjoy it there.

The answer is going to be different for everyone, and that’s exactly the point. As you move up, the hands-on, heads-down portion of the job tends to shrink -- I talked about that reality in Senior Engineers Spend Less Time Coding. Management accelerates that shift even further. So if a management promotion is the thing being offered to you, don’t take it just because it’s labeled “the next level.” Understand that you’re signing up for a fundamentally different job -- one with friction coming at you from multiple directions, where success looks less like “I shipped this” and more like “my team shipped this without needing me.”

If that trade excites you, management can be incredibly rewarding. If the thing you love most is the deep technical flow, go in with your eyes open that you’re trading away a lot of it -- and know that there may be other ways to grow that keep you closer to it.

Final Thought

I’ll admit this one is a bit all over the place, because the topic genuinely is. The “management trap” isn’t really a trap in the sense of a mistake you fall into. It’s just the reality that management is a different role, with different rewards and different costs, and a lot of people step into it without anyone being honest with them about that tradeoff.

If you’re weighing this in your own career -- or you’re already in the seat and feeling the scatter -- I hope this gave you a more useful frame than “management good” or “management bad.”

And if you’ve got a specific situation you’re navigating, you can submit it anonymously over at codecommute.com, and I’ll try to make a video response.

Dev Leader Weekly

Discussion about this post

Ready for more?