The Technical Leader's Dilemma: When to Code and When to Delegate¶

Two years into my first leadership role, I was still writing production code every day. I convinced myself this was necessary — how could I lead a technical team if I wasn't in the code?

I was wrong.

I was also the bottleneck. Every decision waited for my review. Every critical project needed my hands on the keyboard. I was working 60-hour weeks and my team was waiting on me to finish my tasks before they could start theirs.

The transition from individual contributor to technical leader isn't about learning new skills. It's about unlearning the behaviors that made you successful as an IC. The very habits that got you promoted — diving deep into code, solving hard problems yourself, being the person who ships — become liabilities when you're leading a team.

The Technical Leader's Identity Crisis¶

As an IC, your value is obvious: you write code, you ship features, you fix bugs. The connection between effort and output is direct and measurable.

As a technical leader, your value becomes indirect. You enable others to write code. You unblock teams. You create the conditions for others to be productive.

This is harder to measure. It's also harder to internalize.

I spent my first year in leadership feeling like I wasn't doing real work unless I was writing code. Planning a technical strategy? Not real work. Running 1-on-1s with team members? Not real work. Reviewing architectural proposals? Not real work.

This mindset was destructive. I was optimizing for the wrong metric — my personal contribution — when I should have been optimizing for team output.

The Coding Trap¶

There's a specific trap technical leaders fall into: using coding as escapism.

Leadership is hard. Meetings are draining. Difficult conversations are uncomfortable. Strategic planning is ambiguous.

Coding is easy. The feedback loop is immediate. The problems are well-defined. You know you're making progress because the tests pass.

So when the day gets hard, you retreat to the code. You tell yourself you're "staying technical" or "leading by example." But you're actually avoiding the work only you can do.

I've been guilty of this. I'd spend three hours writing a script that automated some internal process, feeling productive the whole time. Then I'd realize I'd skipped two 1-on-1s and hadn't responded to the architecture proposal that three engineers were waiting on.

The question isn't "Can I code this faster myself?" The question is "Is this the highest-leverage use of my time?"

When You Should Still Code¶

I'm not arguing that technical leaders should never code. I'm arguing that you need to be strategic about when and how you code.

Good Reasons to Code¶

1. Proof of Concepts for Major Technical Decisions

When your team is evaluating a new technology or architectural pattern, building a quick proof of concept yourself ensures you understand the trade-offs deeply.

This isn't production code. It's throwaway code that informs a decision. Timebox it to a few hours.

2. Critical Path Work with No Other Option

Sometimes you're the only person who can solve a specific problem — specialized domain knowledge, unique access, or genuinely no one else available.

This should be rare. If it happens often, you have a hiring problem or a knowledge-sharing problem.

3. Keeping Your Skills Sharp

Building small side projects, contributing to internal tools, or working on low-risk features helps maintain technical credibility and keeps you current with the stack.

The key: don't make these projects block anyone else. They should be genuinely optional work.

Bad Reasons to Code¶

1. "I Can Do It Faster Myself"

Maybe true today. Definitely false tomorrow. Every time you solve a problem yourself, you've robbed someone else of the opportunity to learn and grow.

The team doesn't scale if only you can solve hard problems.

2. "I Need to Stay Technical"

You can stay technical by reviewing code, discussing architecture, and mentoring engineers through tough problems. You don't need to be the one writing every line.

Your technical judgment improves faster through breadth (reviewing many approaches) than depth (implementing one approach).

3. "I Don't Trust Anyone Else to Do This Right"

This is a failure of hiring, training, or delegation — not a reason for you to write the code.

If you genuinely don't trust anyone on your team with important work, you need to either mentor them until you do or hire people you can trust.

4. "This Is My Zone of Genius / I Love This Problem"

Your zone of genius is a luxury you can't always afford as a leader. The work needs to be done by whoever can do it while allowing the team to move fastest.

Save your genius for problems that genuinely require your unique expertise.

The Delegation Framework¶

When a piece of work lands on your plate, run it through this framework:

1. Does this require my unique expertise?¶

Yes: This is a good candidate for you to do (or at least heavily influence).

No: Delegate it.

2. Would this be a growth opportunity for someone else?¶

Yes: Delegate it and invest time in mentoring them through it.

No (too easy): Delegate it anyway. Free up your time.

No (too hard): Break it down into smaller pieces. Delegate what you can. Mentor through the hard parts.

3. Is this on the critical path?¶

Yes + only I can do it: Do it quickly.

Yes + someone else can do it: Delegate it and remove blockers so it moves fast.

No: Delegate it or defer it.

4. Is this strategic or tactical?¶

Strategic (impacts direction): You should be involved, at least in the decision-making.

Tactical (execution): Delegate unless there's a specific reason you need to do it.

Maintaining Technical Credibility Without Writing All the Code¶

The fear every technical leader has: "If I'm not writing code, will I lose my technical credibility?"

Valid concern. But coding isn't the only way to demonstrate technical expertise.

What Actually Builds Credibility¶

1. Making Good Technical Decisions

Your team will trust you if you consistently make sound technical judgments — choosing the right architecture, identifying risks early, understanding trade-offs deeply.

You build this judgment through reviewing code and designs, not just writing them.

2. Asking the Right Questions

The best technical leaders I've worked with didn't have all the answers. They asked the questions that surfaced hidden assumptions and forced the team to think through edge cases.

"What happens if this service is down?" "How will this scale to 10x traffic?" "What's our rollback plan if this goes wrong?"

You maintain credibility by demonstrating that you understand the problem space deeply — not by implementing every solution yourself.

3. Protecting the Team from Bad Decisions

Credibility comes from preventing disasters. When you recognize a technical decision that will cause problems six months from now and steer the team away from it, you've added immense value.

You don't need to write the code to provide this judgment.

4. Mentoring Through Hard Problems

Sitting with an engineer and talking through a gnarly debugging session or architectural challenge demonstrates technical depth. You're not writing the code, but you're directly contributing your expertise.

This also scales your impact — that engineer now knows how to tackle similar problems without you.

The "Architect" Escape Hatch¶

There's a career path that lets technical leaders stay close to code without being on the critical path: becoming an architect.

This works for some people. It's also a trap for others.

The Architect Trap:

You're still deeply technical. You design systems and evaluate technologies. But you're not responsible for execution, you're not managing people, and you're not on the hook for delivery.

This sounds perfect — all the interesting technical problems, none of the management overhead.

The problem: If you're not close to execution, your architectural decisions become theoretical. You design systems that look great on paper but are nightmares to implement.

The best architects I've worked with are deeply connected to execution — reviewing code, participating in on-call rotations, and closely collaborating with the engineers building their designs.

If you're considering the architect path, ask yourself:

• Do I still want to be close to production?
• Am I willing to be responsible when my designs don't work?
• Can I influence without authority?

If the answer to any of these is "no," you might be escaping into architecture rather than genuinely choosing it.

The Signs You're Coding Too Much¶

Here are the warning signs that you're spending too much time in the code:

1. Your team is waiting on you to finish tasks before they can start theirs

You're the bottleneck. Delegate.

2. You're consistently working nights and weekends to "catch up" on leadership work

Your IC work is overflowing into time that should be reserved for leadership. Cut back on coding.

3. Engineers are making decisions without your input because you're "too busy"

You've become unavailable for the strategic work only you can do. Your coding is crowding out leadership.

4. You're missing 1-on-1s or delaying them because "something urgent came up"

If the urgent thing is a coding task, you're prioritizing the wrong work.

5. You feel productive when you're coding and unproductive when you're not

This is the identity crisis. Your value as a leader isn't measured by your lines of code.

The Signs You're Not Coding Enough¶

Conversely, here are the signs you've drifted too far from the technical work:

1. You don't understand the technical decisions your team is making

You've lost context. Spend time reviewing code and designs.

2. Your team doesn't come to you for technical guidance

They've stopped seeing you as technically credible. Rebuild credibility by engaging with technical problems.

3. You're making technical commitments you can't deliver on

You've lost touch with what's actually hard. Get closer to the work.

4. You're bored and miss the satisfaction of building things

This is legitimate. Find small projects that don't block the team and scratch the creative itch.

Finding Your Equilibrium¶

The right balance between coding and leading is personal. It depends on your team size, the maturity of your engineers, and the phase of your product.

For me, the equilibrium is:

• ~10% of my time writing production code (small features, bug fixes, internal tools)
• ~30% of my time in technical reviews (code reviews, design reviews, architecture discussions)
• ~30% of my time on people work (1-on-1s, hiring, career development)
• ~30% of my time on strategy (roadmap planning, stakeholder management, cross-team coordination)

Your numbers will differ. The important thing is to be intentional about where your time goes.

The Question That Changed My Approach¶

A mentor once asked me: "If you spend four hours writing code, what work isn't getting done?"

That question reframed everything.

It's not "Should I write this code?" It's "What am I choosing not to do if I write this code?"

Every hour coding is an hour not spent: - Unblocking someone else - Mentoring an engineer through a hard problem - Reviewing an architectural decision - Having a difficult conversation that's been postponed - Planning the next quarter's technical strategy

Sometimes the code is still the right choice. But now I'm making that choice explicitly, with eyes open to the opportunity cost.

The Bottom Line¶

The hardest part of becoming a technical leader is accepting that your job is no longer to write the best code. Your job is to build the best team that writes the best code.

You'll still code. But you'll be strategic about when and why.

You'll still stay technical. But through breadth (understanding many systems) rather than depth (implementing one system).

You'll still solve hard problems. But often by asking the right questions and empowering others rather than implementing solutions yourself.

The transition is uncomfortable. You'll feel less productive. You'll miss the immediate feedback loop of shipping features.

But if you can let go of the keyboard — even just a little — you'll unlock an entirely different kind of leverage. The kind that scales beyond what you can personally build.

That's when you stop being a great engineer who manages people and start being a great leader who builds great engineering teams.