If You Write 80% Less Code as Tech Lead

I’ve Got News for You

Linus Torvalds hasn't written a device driver in years. The creator of Linux, who once coded every line of his kernel, now describes his role differently:

"My own personal contribution is mostly merging code written by others, with little programming."

Now, you're not maintaining Linux with thousands of contributors. You're probably leading 5-10 engineers at a regular company, dealing with sprint deadlines and product managers. But here's what Torvalds discovered that applies to every tech lead:

Sometimes your biggest contribution isn't the code you write, but the code you enable others to write better.

Finding Your Technical Leadership Style

Some tech leads thrive while maintaining 70% coding time. Others find their sweet spot closer to 30%. The key is being intentional about where you spend your technical energy.

Here's the promise I make to engineers becoming tech leads: You'll write less code, and that's exactly what your team needs.

The trick is to swap "lines written" for "impact created." That freed-up time? Use it to:

• Unblock others fast - A 15-minute conversation can save someone two days

• Review code for clarity, not just correctness - Will a new hire understand this in six months?

• Map dependencies before they bite - See the collision coming three sprints away

• Coach someone through their first tricky feature - Their growth multiplies your impact

And you don't have to lose your technical edge. Here are approaches that have worked for different leaders I know:

System 1: Own One Critical Component

Pick ONE system your team relies on. Not three, not "the backend"—one specific, critical component. Maybe it's:

• The authentication service

• The API gateway

• The data pipeline

• The deployment system

For this one component, you:

• Know every line of code

• Review every PR that touches it

• Write the specs

• Own the roadmap

• Make the architectural decisions

This is your technical anchor. When big decisions need to be made, you have real context. When team members need deep technical guidance, you're not hand-waving—you're speaking from current, hands-on experience.

System 2: Friday Afternoon Prototypes

Block 2 hours every Friday. Non-negotiable. This is when you prototype something risky or untested your team needs.

Not production code. Not features. But rather:

• That new framework everyone's curious about but scared to try

• The architectural change you've been debating for weeks

• The automation that would save everyone 30 minutes daily

• The proof-of-concept that shows whether that "impossible" feature is actually doable

You stay sharp, they get de-risked solutions, everyone wins.

System 3: Turn Code Reviews Into Teaching Moments

Transform code reviews from bug hunts into learning opportunities. Instead of just catching errors, look for moments to share knowledge:

When you see clever code: "This works, but how would you explain this to someone joining next month?"

When you spot a pattern: "This reminds me of how we solved the rate limiting issue. Here's why we chose that approach..."

When you notice potential issues: "What happens when this gets called 10,000 times per second? Let's think through the implications together."

When someone's doing something interesting: "I love this approach. Could you share it in our team slack? Others could learn from this."

Every review becomes a mini-lesson. Your team levels up without formal training sessions.

The Hard Truth About Impact

Some days you'll write zero code. You'll have six hours of meetings, review a dozen PRs, answer fifty Slack messages, and feel completely useless.

On those exact days:

• Your junior engineer shipped their first major feature because you spent an hour helping them think through edge cases

• Your team avoided a month-long wrong direction because you asked one good question in a design review

• Your senior engineer felt heard and stayed at the company because you took their concerns seriously

Your IDE might be quieter on some days, but your impact shows up in the architecture decisions that scaled, the bugs prevented in review, the developers who grew, and the features that shipped without major issues.

And if Linus Torvalds—arguably one of the best programmers alive—can accept that his value lies in enabling others rather than coding everything himself, then so can you.

The algorithm you're optimizing now isn't quicksort or binary search.

It's human potential. And unlike most algorithms, there's no single optimal solution.

---

Read next: I’ve Reviewed Over 100 CVs

(Most of Them Made The Same Mistake)