Part of the transition to a software engineering manager is the realization that it’s a different job — and there’s a set of skills you left behind. Likely as one of the better software engineers on your team.
This means you’ll need to consider how to let go of parts of your past job — if not be rid of it entirely.
For me, I learned that I can’t effectively juggle high-quality programming and high-quality team management. They require two very different modes of thinking that I personally find difficult to hold at the same time.
Given the rise of engineering managers who are expected to be player-coaches or tech leads with a splash of people management responsibilities, this can seem out of touch.
But these hybrid roles exist because managing people is such a different skill from day-to-day coding that it’s hard to find individual contributors who want to do it at all. Businesses have reacted by expecting less from their people managers — especially in engineering orgs — allowing them to do the people management part time.
For a person in one of these roles, the whiplash can be jarring.
As an individual contributor, you’re responsible for your own output. You have a direct hand on the work. You can block off large chunks of time, throw on headphones, and lose yourself in code and problem solving.
People management is the opposite. It’s done in chunks and bits and pieces, and it explicitly requires interacting with other people who are hard to predict and don’t adhere to your schedule.
You have to leave space for them — temporal space, yes, but mostly mental bandwidth. Space that used to be filled with code.
Without boundaries, this mixing of deep work and the scattered nature of managing human beings accelerates burnout. The default is to do a suboptimal job of both halves.
Others have framed this as the difference between the maker and manager schedule — the shift from large blocks of deep work to a calendar pockmarked with meetings. But it’s more than the calendar.
It’s your brain space.
Holding not just one or many code bases, but the hopes, dreams, careers, and foibles of even a handful of people can tax anyone — especially someone who’s never done it before.
Draw a line
To combat this, I set a rule for myself: I don’t do any production-dependent coding. Bug fixes, proof of concepts, small experiments — fine. But nothing on the roadmap. Nothing the business depends on lasting. Sometimes I’d phrase it as “I will only code in the GitHub web interface.”
I decided that people and team management take priority over code production.
Your line might be different — based on how you work, or the demands of the role at your current company. But there needs to be a line.
If you’re managing a team and still responsible for primary coding work, you risk creating a culture that relies on you to save the day or shoulder the load.
Or you grab all the difficult or exciting work before your team gets a chance. This is especially common if you were an early or founding engineer. You have all the context. You know where the metaphorical bodies are buried — because you did the digging. You can leap to the exact right spot in code to fix or build the thing that excites you.
I’m not saying “don’t.” I’m saying “think before you act.”
Because each time you hurry off to the warm embrace of the job you just left — each time you disappear into code — you’re robbing your team of an opportunity to grow. And you’re sending a signal that you don’t trust them.
I’ve seen this behavior drive engineers and product folks away from otherwise solid startups. Founding engineers who don’t let go impede team and company growth more than any feature or bug taking slightly longer to ship.
In basketball, this is everybody standing around watching the star player dribble out the clock before chucking up a deep three.
The cabin in the woods
A MarTech company I know of had a VP in the engineering department who was described as “brilliant.” This is a secondhand story, but it’s illustrative.
When a portion of their application was running slow, my product friend seemed in awe when he described this brilliant VP running off to a cabin in the woods for a week and dramatically improving the performance of that corner of the app.
Having done similar things in my own career, I found myself frowning at the story. Sometimes it feels easier and quicker to go fix the damn thing yourself rather than explaining how to do it to somebody else.
But here’s what you’re actually communicating when you do this:
You don’t trust your team to do this work. They are less important than this work. And whatever your actual job entails is less valuable — but that’s a meta discussion for another time.
No matter how brilliant you are, you cannot be more brilliant than every other engineer combined. Your job is not to make the application faster. It’s to unlock the brilliance of the rest of your team.
You can’t do that if you hog the ball.
The dopamine problem
This transition is tough because you were likely really good at your engineering job — it’s why you got “promoted” in the first place.
Diving back into a familiar code base feels good. It feels valuable. It feels familiar. It’s hard to talk yourself out of anything that checks all three boxes.
But this isn’t your job anymore, and it’s not what you’re going to be measured by — not by the business, and not by the team.
When you transition to managing people, you’re measured by the team’s output, not yours. Your work is part of it, but if you were enough, they wouldn’t need a team.
So where does the dopamine come from?
It has to come from different wins. Watching someone on your team nail a problem they couldn’t have solved three months ago. Shipping a feature where you didn’t write a single line of code. Having a one-on-one where an engineer tells you they finally feel like they know what they’re doing.
These wins are quieter than a green CI build or a deploy to production. But they compound in ways that your individual output never could.
The cost of not letting go
If you’re grabbing all the exciting or difficult work, you’ll drive off the engineers who want those things for themselves. You’ll bottleneck your team’s progress to what you can personally accomplish. And the business won’t see the velocity they expect from your team.
Eventually, your team will notice. They’ll start to complain or leave. Software engineers are among the angstiest populations of employees — like emo kids, they are.
And when your team starts leaving or complaining loudly enough, the business will act. If your coding skills are high enough, they might just ask if you want to go back to IC. Or it might be additional oversight, or training, or a book someone bought you.
Doing this juggle too long can also wear you out — I know it did for me. Code requires deep focus, but managing people involves rapid context switching and a calendar full of interruptions.
More than that, this new job requires a mindset shift. When you were an engineer, you were responsible for code and an application or two. Now your responsibility is people and a team. Your work is no longer in the growth of a codebase — it’s in the growth of those people.
Practical boundaries
If you’re better at juggling these mindsets than I am, keep coding. But draw a line between what you code and what your team codes.
Maybe you handle bugs, or one-off reports, or that one corner of the app nobody wants (and you feel guilty about leaving in such poor shape).
And to save your sanity, time-box your coding. Maybe it’s one day a week. Maybe it’s specific blocks carved out for deep-thinking time. Whatever it is, make it intentional — not reactive.
The goal isn’t to never touch code again. It’s to stop defaulting to code when the real work — the harder, less familiar, more important work — is sitting in your one-on-one agenda.