Just promoted from engineer to manager? Here are the 7 leadership pain points first-time technical leaders face — and how to navigate the shift from doing the work to leading the people who do.
You were the best engineer on the team. You shipped the hardest features, untangled the worst bugs, and became the person everyone went to when something broke. So they did what most companies do with their strongest technical people: they promoted you to manage the team.
And almost overnight, the skills that got you here stopped being the skills the job requires.
This is one of the most underestimated transitions in any growing company. We promote people for technical excellence and then ask them to succeed at something entirely different — leading people — with little to no support. It’s no wonder so many brilliant engineers feel like they’re suddenly bad at their jobs. They’re not. They’ve just been handed a new job that happens to share an office with the old one.
If you’ve recently made the leap from individual contributor to people leader, here are the pain points you’re most likely feeling right now — and what to do about each one.
1. The identity crisis: you’re no longer the one who builds
For years, your value was measurable and visible. You wrote the code. You closed the tickets. You could point to exactly what you produced each week. Now your hands are off the keyboard, and the thing that made you feel competent and respected is the thing you’re supposed to stop doing.
This is the hardest shift, and almost no one names it out loud. The discomfort you feel isn’t weakness — it’s grief for a version of your work that genuinely was rewarding.
What to do: Redefine what “a good day” looks like. Your output is now your team’s output. A day where you unblocked three people, gave one a piece of feedback that changed their approach, and protected the team from a pointless fire drill is a productive day — even if you wrote zero lines of code. Track that. Make the invisible work visible to yourself.
2. You can’t stop trying to fix everything yourself
When a junior engineer struggles for two hours with something you could solve in ten minutes, every instinct screams just do it yourself. And sometimes you do — which feels efficient in the moment and quietly sabotages your team over time.
Every time you take the work back, you send two messages: I don’t trust you to do this, and the way to get unstuck is to wait for me. You become the bottleneck the whole team routes around, and you wonder why you have no time.
What to do: Treat delegation as teaching, not offloading. Let people struggle productively. Ask “what have you tried?” before you offer the answer. Your job is no longer to solve the problem — it’s to build people who can solve it without you. That trade-off is slower this week and dramatically faster this quarter.
3. Difficult conversations are now part of the job
Engineering rewards precision, logic, and the right answer. People don’t run on logic. You’ll now have to tell someone their performance isn’t good enough, mediate a clash between two strong personalities, or deliver news you didn’t decide and don’t fully agree with. There’s no compiler to tell you if you got it right.
Most new technical leaders avoid these conversations until they explode — because avoidance feels safer than a messy, emotional exchange with an uncertain outcome.
What to do: Have the small conversation early so you never have to have the big one. Feedback delivered quickly, specifically, and kindly is a gift, not an attack. A simple structure helps: name the specific behavior, describe its impact, and align on what changes. Done routinely, these stop feeling like confrontations and start feeling like coaching.
4. Managing people who used to be your peers
Last month you complained about management together at lunch. This week you are management. The awkwardness is real — for you and for them. Friendships shift. People wonder if they can still be candid with you. You wonder how to hold someone accountable when you were equals on Friday.
What to do: Address it directly rather than pretending nothing changed. A short, honest conversation — “our relationship is shifting and I want to be upfront about how I’ll handle it” — earns far more respect than awkward avoidance. Be consistent and fair with everyone; perceived favoritism toward old friends will erode the team faster than anything else.
5. Your calendar is no longer your own
As an engineer, you guarded long blocks of focus time. Deep work was the job. Now your day is shredded into fifteen-minute fragments — one-on-ones, stand-ups, cross-team syncs, the interruption from someone who’s “just got a quick question.” The maker’s schedule you loved has been replaced by a manager’s schedule, and it feels like you got nothing done.
What to do: Accept that interruption is part of the work now, and design around it. Batch your one-on-ones, protect a small amount of focus time deliberately, and stop measuring your days by maker-schedule standards. Being interruptible for your team is a feature of the role, not a bug.
6. You’re translating in three directions at once
You now sit in the middle. You translate executive strategy down into work your team can act on, translate technical reality up to leaders who may not be technical, and translate across to product, sales, and other functions who speak a different language. Communication — not code — is suddenly your core competency, and it’s the one you’ve trained for the least.
What to do: Over-communicate the why, not just the what. Engineers execute better when they understand the reasoning, and executives trust you more when you frame technical decisions in terms of business impact, risk, and timelines rather than implementation detail. This skill compounds: the leaders who scale are almost always the ones who communicate with clarity.
7. Ambiguity, with no right answer to check against
Code either works or it doesn’t. Leadership offers no such certainty. Did you handle that situation well? You may never know. Should you have hired that person, had that conversation sooner, pushed back harder? There’s rarely a clean answer, and for a mind trained to find the correct solution, that ambiguity is genuinely uncomfortable.
What to do: Get comfortable making good decisions with incomplete information and adjusting as you learn — the same way you’d iterate on a system in production. Find peers or a coach who lead people too; talking through real situations with someone outside your reporting line is one of the fastest ways to build judgment and confidence.
The bigger truth
None of these pain points mean you were the wrong choice for the role. They mean you’re doing a genuinely different job — one that takes deliberate practice, not just time. The best engineers don’t automatically become the best leaders, and they’re not supposed to. Leadership is a craft you learn, the same way you once learned to write good code.
The companies that scale well know this. They don’t just hand strong engineers a team and hope for the best — they invest in turning technical talent into confident leaders before the gap costs them their best people.
Make the transition with support, not by trial and error
At PowerUp Leadership, we help newly-promoted technical leaders build the people-leadership skills the job actually demands — delegation, feedback, difficult conversations, and leading with clarity and confidence. Our Leadership for Managers programs and one-on-one coaching are built for exactly this moment.
[ Explore Leadership for Managers → ] ( https://powerupleadership.ca/manager-coaching/manager-leadership-development-program/)
Promoting your best engineers into management? Join our webinar, The Accidental Manager— and How to Fix It Before It Costs You Your Best People (June 17, 2026 at 12pm AT). [ Register → ] (https://forms.gle/WCd8cedX3hst8mmi9)
PowerUp Leadership — Building Leaders Who Scale