The further you get from the code, the harder it is to lead engineers well. Here’s how I’ve tried to stay grounded.
The drift is real
Most engineering leaders I know didn’t intend to stop coding. It happened gradually — more meetings, more strategy documents, more people to manage. One day you realize your last meaningful pull request was eight months ago.
This matters more than people admit. Technical credibility isn’t just about being able to read code in a review. It’s about having current intuitions: what is hard, what is fast, what is fragile, what is a reasonable estimate.
When those intuitions go stale, you make worse decisions — and engineers sense it immediately.
What I do about it
I keep a personal project running at all times. Not a side business or something with external pressure — just a codebase I care about, where I’m writing real code against real constraints. Currently that’s a small AI tooling project I use myself.
I also make a habit of pairing with engineers on problems that are genuinely hard, not just reviewing solutions after the fact. Being in the room when a problem is being worked through is different from reading the PR afterward.
The diminishing returns argument
Some leaders argue that staying technical is a bad use of time — that at a certain seniority level, your leverage is in strategy and people, not code.
I think this is mostly wrong. The best technical leaders I’ve worked with were all actively engaged with the technical work, even at VP and CTO level. The ones who checked out technically became less effective over time, not more.
The question isn’t whether to stay technical. It’s how to do it without becoming a bottleneck.
