🧠 Decide, Then Delegate: The Pitfalls of Playing Engineer as a Manager

I’ve seen it more times than I can count: an engineer switches to management and can’t quite let go of the code. They keep their old mindset, hold on to their technical comfort zone, and before long, they’re doing the team’s job instead of their own.

I’ve told manager+ more than once: pick a lane. If you’re doing your team’s job, you’re likely not doing yours. And your team? They feel it.

So what exactly goes wrong when managers can’t stop coding? Let’s break down some common traps.

🔧 1. Doing the Work Instead of Enabling It

The trap: Rewriting pull requests, jumping in to fix bugs, or designing systems solo.

Why it’s a problem: This kills autonomy. It undermines ownership. It signals you don’t trust your team to figure it out. You think you’re helping, but you’re actually blocking growth.

Try instead: Guide with questions. Provide guardrails. Create the space for your team to deliver their own solutions—even if they do it differently than you would.

🧮 2. Getting Stuck in the Technical Weeds

The trap: Bikeshedding implementation details in planning meetings. Micromanaging Jira tickets.

Why it’s a problem: It shifts the focus from outcomes to methods. Everything slows down. And your team starts tuning out.

Try instead: Focus on outcomes, priorities, and constraints. Let the engineers own the how. That’s why you hired them.

🚧 3. Acting Like the Tech Lead Instead of Building One

The trap: Becoming the sole source of technical truth on your team.

Why it’s a problem: You become a bottleneck. Your team becomes dependent. Leadership doesn’t scale if it’s always coming from you.

Try instead: Distribute your knowledge. Mentor others into tech lead roles. If your team can’t function without you, you haven’t built a team—you’ve built a fan club.

🧍‍♂️ 4. Neglecting Actual Manager Work

The trap: Avoiding performance reviews, career conversations, and hard feedback because “that’s not real work.”

Why it’s a problem: Without support, guidance, or accountability, your team will stagnate—or worse, walk.

Try instead: Embrace the multiplier effect. Help each person grow. Think long-term. Engineering managers build people, not products.

🗺️ 5. Confusing Vision with Control

The trap: Dictating detailed roadmaps, deciding how tasks should be broken down, estimating effort yourself.

Why it’s a problem: This kills team thinking and breeds learned helplessness. You get obedience instead of creativity.

Try instead: Share the why. Align on the what. Let your team co-own the how and when. Be the guardrails, not the GPS.

🔄 6. Cloning Your Former Self

The trap: Expecting everyone to work the way you did as an IC.

Why it’s a problem: You overlook different thinking styles, skill levels, and motivations. You turn diversity into uniformity.

Try instead: Lead with empathy. Meet people where they are. Help them become better versions of themselves, not mini-yous.

🛑 7. Holding On to Old Metrics

The trap: Judging yourself by how much you’re producing—commits, fixes, lines of code.

Why it’s a problem: Your job now is to amplify others’ output. If you're still measuring your success by your own throughput, you’re missing the bigger picture.

Try instead: Measure impact by team growth, delivery velocity, and overall health. If your team thrives without you, that’s a win.

🧠 Final Thought: Stay in Your Lane to Help Others Drive

If you made the decision, let someone else implement it.
If you're doing the implementation, let the team make the decision.

If you’re doing both, you’re probably holding the team back.

The best managers are force multipliers. They don’t just lead—they lift.