If you're a manager who still thinks your coding skills are your safety net, you're not leading—you're escaping.

The Problem

Temporarily returning to an individual contributor role to help your team during tough times might feel noble or efficient. But it erodes trust, stunts growth, and sends the wrong message about your role as a leader. It's not a solution—it's a systemic failure disguised as personal commitment.

What Happened

I once stepped into a new team as their manager, bringing my usual servant leadership approach: support, empower, and protect the team. It's a philosophy I believe modern software teams need to thrive.

But this team was junior, and I didn't have the budget to bring in experienced hires. We were also under intense pressure to ship a complex project on a tight deadline.

Delivery was slow. Frustration crept in. And eventually, I made the call: I would start coding again to help accelerate progress.

I didn't step out of management—I tried to do both roles. I was still leading the team, still responsible for their performance, while also diving back into the codebase.

We did ship the project on time. But I wasn't prepared for the cost.

The Consequences

• The team felt micromanaged, even if that wasn't my intent.
• Trust in me decreased.
• I removed learning and ownership opportunities from the team.
• I became exhausted—doing two jobs meant I wasn't doing either well.
• Worst of all: I was disillusioned. I was doing everything, and still failing at the one thing I was hired to do—lead.

What I Learned

• I lost sight of what mattered—my role, my values, and my boundaries.
• Regardless of pressure or deadlines, you can't save the day alone.
• Returning to IC work might feel faster, but it's a short-term patch with long-term consequences.
• Real leadership is about finding ways to ship faster with your team, not in place of your team.

By doing the work myself, I sent the unspoken message that I didn't believe in my team—or in myself as a leader.

How I Apply It Now

I'm explicit about the boundaries of my role.

I lead hands-off by default. I don't code at work, not because I can't—but because it's not my job. I still code in my free time to stay sharp and understand my team's world, but I no longer treat my IC skills as a fallback.

I support. I coach. I remove blockers. That's where I bring the most value now.

What I Could Have Done Instead

• Challenged the deadline or scope to better match team capacity.
• Used more structured methods to listen and align.
• Removed “doing it myself” as an option entirely.
• Focused on system improvements, not individual heroics.
• Doubled down on removing blockers and enabling deep focus.

Remain focused. Empower. Multiply. Don't try to be the hero who saves the day.

Are you stepping in because your team needs help—or because it makes you feel useful?

What are you afraid will happen if you truly step back and let go?

What systemic issue are you trying to fix with personal effort?