Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why Your CTO Should Not Code
Transcript
- Lucas: So here's a question that I think a lot of engineering leaders wrestle with — and it often stays in the dark because admitting the wrong answer feels like admitting you're not a real engineer anymore. Should your CTO be writing production code? Luna: Oof. That's a loaded one. I've seen this tear teams apart. Some CTOs hold on to code like a security blanket. Others never touch it and get called 'out of touch.' Lucas: Exactly. And there's a really specific case that I think frames the dilemma perfectly. There was a former Google VP of Engineering — I won't name him because the principle matters more than the person — who joined a mid-stage startup as CTO. He made a very public decision on day one: he would not write a single line of production code. Not one. Luna: That's bold. How did the engineering team react? Lucas: Mixed, the first few weeks. Some engineers loved it — they felt trusted. Others worried he wouldn't understand the technical debt they were drowning in. But within six months, engineering velocity actually went up. And the CTO's reason was simple: his job was to unblock the team, not to be another contributor. Luna: I can see the logic, but I also think about a counterexample. There's a CTO of a fintech unicorn — I do know them — who still reviews pull requests. Not every PR, but the critical ones. His team says it keeps him grounded in the system's actual pain points. Lucas: Right, and that's a different mode. He's not writing code, but he's reading it. There's a meaningful distinction between coding and code review. Let's be precise: when I say 'write production code,' I mean committing features, fixing bugs, shipping. Code review is a leadership act. Luna: That's fair. So what does the data say? There's a 2025 survey of 500 CTOs that I remember seeing — from a16z or maybe a consultancy? Lucas: It was from a leadership development firm called Refactor. They surveyed 500 CTOs at companies between 50 and 500 engineers. The finding that jumped out: CTOs who reported coding more than 20 percent of their time had, on average, 30 percent lower team throughput. Not slower personally — the team was slower. Luna: Thirty percent is massive. That's more than a speed bump — that's a systemic drag. What's the mechanism? Is it just opportunity cost? Lucas: Partly. But it's also signaling. When the CTO is heads-down coding on a feature, the team infers that coding is the highest-value activity. So they de-prioritize things like documentation, mentoring, architecture reviews — the stuff that compounds over time. The CTO's behavior sets the culture. Luna: So the 'coder CTO' creates a culture where individual contribution is king, even when the company needs more collaboration and long-term thinking. Lucas: Exactly. And there's a second-order effect. If the CTO is coding, they're often a bottleneck in code review because they want to approve everything. Or they're shipping such high-quality code that the team feels intimidated to refactor it later. It creates technical debt disguised as excellence. Luna: I've seen that. The CTO's code becomes a sacred artifact. Nobody wants to touch it. Lucas: Right. So the argument for the non-coding CTO is really about leverage. One decision about team structure or tooling can affect 100 engineers for a year. One feature commit affects a few users for a week. Which lever should the CTO pull? Luna: But let me push back. There's a real risk of the CTO becoming disconnected. If you never touch the code, how do you know whether your team's estimates are realistic? How do you know if a 'quick fix' is actually quick? Lucas: That's the delegation versus abdication trap. A good non-coding CTO stays close to the code through architecture reviews, design docs, and regular pairing sessions. They don't need to commit to understand. They need to listen and ask the right questions. Luna: So what's the right allocation? I've heard the '80/20 rule' floated — 80 percent leadership, 20 percent technical work. Lucas: That's actually the framework I'd recommend. But the '20 percent technical' needs to be defined. It should not be feature coding. It should be architecture reviews, code review of critical paths, debugging production incidents, and maybe a small prototyping project that's explicitly non-shipping. The key is that the technical work informs leadership decisions, not the other way around. Luna: So the CTO who still reviews pull requests in the fintech unicorn — that's in the 20 percent. The CTO who jumps on a bug fix for a key customer — that might be, too, if it's rare. But if they're doing that every week— Lucas: Then they're slipping into the 80 percent coding bucket, and the team will start feeling it. There's a litmus test. Ask yourself: 'If I step away from coding for two weeks, does the team slow down?' If yes, you're a bottleneck and you need to delegate more. If no, you're probably doing it right. Luna: That's a great question. I'm going to use that. So for a CTO who's currently coding heavily—how do they transition without the team seeing it as abandonment? Lucas: Transparent communication. Say: 'I'm shifting my focus to unblocking the team and improving our systems. That means I'll write less code, but I'll be more available for design discussions and career growth.' Then back it up with visible actions. Show up to stand-ups. Review architecture docs. The team will adapt. Luna: And if the CTO is already non-coding but the team feels disconnected? Lucas: That's harder. They need to rebuild technical credibility. They can join a rotation on-call for a month. Or pair with a senior engineer on a gnarly bug. The goal isn't to become a coder again — it's to demonstrate that they still understand the system's pain. Luna: I like that. It's a middle path. The CTO stays technical without becoming a producer. Lucas: Exactly. And the final piece of this is company stage. At a 20-person startup, the CTO might need to code because there's no one else. At 200 people, coding is a distraction. At 2,000, it's almost malpractice. Luna: So the advice shifts. A first-time CTO at a Series A might need to hear: 'It's okay to keep coding for now, but plan your exit from production code.' A seasoned CTO at a public company might need: 'If you're still coding, you're failing at your real job.' Lucas: That's harsh but accurate. The real job is building the environment where great engineers do their best work. That's harder than any feature you could write. Luna: Alright, final question. If you're a CTO listening right now and you're not sure where you stand — what's the one thing you should do this week? Lucas: Track your time for five days. Honestly. Code commits, meetings, 1:1s, design reviews. Then ask: 'Is my calendar aligned with my impact?' If you're spending more than 20 percent of your time on tasks that only you can do as a coder, you're undervaluing your leverage as a leader. Luna: And if the answer is uncomfortable? Lucas: Then you know where to start. The first step is admitting you might be the bottleneck. And that's actually good news — because you can fix it.