There’s a common narrative in technology leadership: as you advance, you should spend less time on technical details and more time on strategy, people, and business outcomes. The assumption is that technical depth becomes a liability, a distraction from the “real work” of leadership.
I think this is wrong, or at least incomplete.
The case for staying technical
The best technology advice I’ve received has always come from people who still practice the craft. Not people who practiced it a decade ago and now only read about trends, but people who regularly encounter the friction of real implementation.
This isn’t about ego or the inability to let go. It’s about maintaining the judgment required to make good decisions. When you stop doing technical work, you lose something important: the intuition that comes from recent, direct experience.
What staying technical looks like
I’m not suggesting CTOs should be reviewing pull requests or writing production code during business hours. But there’s a middle ground between “completely hands-off” and “in the weeds.”
For me, it looks like:
- Personal projects that use technologies I’m advising clients on
- Reading actual documentation and technical papers, not just summaries
- Occasionally pairing with engineers to understand their challenges firsthand
- Building small tools and prototypes to test ideas
The strategic value
Here’s the counterintuitive part: staying technical makes me better at the strategic work, not worse. I can spot when a vendor is overselling capabilities. I can ask the right questions during technical due diligence. I can distinguish between genuine complexity and accidental complexity when teams explain why something is hard.
This judgment is what organizations are paying for when they hire senior technology advisors. Lose the technical foundation, and the judgment goes with it.