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)
Great article, Danil
Thanks for sharing.
Great article Danil! So helpful!