Should CTOs still do code reviews?
This is a debate I keep returning to. It started when a colleague argued that CTOs should stay close to the code, even in a 200-person org. The idea being that reading PRs helps them make better decisions, hire smarter, and stay relevant.
I understand the instinct. But I see it differently.
At that scale, a CTO's real leverage is in strategy, business alignment, culture, and engineering excellence. That work doesn't require weekly PR reviews, showing up to every architecture discussion or any hands-on technical work, for that matter.
And while the right level of involvement always depends on the company’s stage, spending too much time in the trenches usually means you're not operating at the right level.
I was once offered a role managing 70 people across engineering and product. The headhunter insisted I had to be "hands-on in Java." My answer was simple: if I'm coding while managing 70 people, either I'm not doing my job or my people aren't.
This kind of expectation doesn't come out of nowhere. Tech leaders naturally gravitate toward code: it's where they built their confidence, earned their credibility, and learned to trust their judgment. Letting go of that feels like losing ground.
CEOs don't want a CTO buried in pull requests. They want a strategic partner who can translate between the business and the engineering org.
And the market reinforces it. "Hands-on" appears in senior engineering job descriptions more often than it should. The implicit message is that staying close to the code signals competence and commitment.
But CEOs don't actually want a CTO buried in pull requests. They want a strategic partner who understands the technical reality deeply enough to make sound decisions, challenge assumptions, and translate between the business and the engineering org.
Those are fundamentally different jobs, and confusing them is how good CTOs become irrelevant .
Here's why the code-review instinct leads you astray at scale:
- Spending hours in code reviews pulls your focus away from macro-level decisions. It's easy to miss the forest for the trees.
- Reviewing engineers' PRs risks looking like micromanagement and quietly undermines the leadership layers beneath you.
- Hiring and retention depend on clarity and culture, not whether the CTO reads pull requests.
Staying technical is crucial. But it has to happen at the right altitude: architecture reviews, design discussions, system tradeoffs. Not hands-on deep coding.
If I'm coding while managing 70 people, either I'm not doing my job or my people aren't.
But there's a real risk on the other side
When you lead from a distance, the connection between what's actually happening and what reaches you gets distorted. Your technical knowledge, your gut feel for complexity, your intuition about where the org really stands - all of it gets filtered through presentations, reports, and dashboards.
You can have all the data in the world and still miss the real story behind it.
Over time, technical knowledge and intuition weaken. That affects how you evaluate complexity and timelines, how you assess what's truly difficult versus what's being overstated, and ultimately how clearly you see reality. The picture that reaches you can be delayed, over-polished, and subtly wrong. And often, you'll feel that something is off but won't be able to name it.
At Intel, I once managed a large, complex program with teams across nine different sites worldwide. I couldn't be on top of every detail. So once a week, I'd sit with the engineer responsible for the product build. He knew not just the state of the release, but which teams were moving, where there was friction, and what was going on with the infrastructure. That was where I got the real picture. Not from the presentations.
Leading at the right altitude doesn't mean being detached. It means knowing when to pull back to see further, and when to move closer to understand more deeply.
Staying close to reality without diving into the weeds
Over the years, a few habits have proven consistently useful:
Walk the floor
Talk to the people doing the work: developers, QA, DevOps, product managers, support. Ask what's working, what hurts, what's missing. One hallway conversation sometimes tells you more than ten dashboards, especially when you're genuinely listening.
Build a sensor network
Find people with good intuition, real information, and genuine investment in what's happening. A sharp DevOps engineer, a thorough tester, a customer-facing rep who feels the product in her bones. Keep those channels open. They'll detect early signals before anything shows up in your metrics.
Keep the door open and the ego out
Encourage direct, honest conversation across all levels. Have lunch with different teams. Be open about your own knowledge gaps. Ask people to explain things to you, even if it feels uncomfortable. Make regular time for anyone who wants to share feedback or surface a problem. That builds real trust and lowers the walls that hide bad news.
Stay genuinely curious
Easier said than done - the higher you climb, the less you're naturally exposed to new things.
Play with new technologies. Read. Go to conferences and meetups. Use AI tools to keep learning. Let your own people teach you. Staying intellectually active keeps your technical intuition sharp even when you're no longer in the code daily.
Maintain an objective picture
You still need data, metrics, and quality KPIs. But don't stop there. If the numbers don't match what you're hearing on the ground, dig until you understand why. The gap between the two is usually where the real insight lives.
Leading at the right altitude doesn't mean being detached. It means knowing when to pull back to see further, and when to move closer to understand more deeply.
The real question for any senior engineering leader isn't "Should I still do code reviews?"
It's "What mechanisms am I building to stay connected to reality without getting pulled into the weeds?"
That's the discipline. And it's harder than writing code.