2026-06-08: Your CTO Needs to Code
A man's true delight is to do the things he was made for. - Marcus Aurelius
If your CTO does not code, they should not be your CTO. Anyone who wishes to lead an organization, and I mean lead, not command (and certainly not control, expecially by fear), should be operate at a level of technical excellence that at a minimum commands the respect of other.
A CTO that does not code is not respected. The rank-and-file, those who do the work day-to-day, will come to understand immediately that such a boss is simply a fool to be played. Any estimate, any deadline, any architecture, any approach: all of this is on the table, because a CTO that does not code cannot reasonably nor feasibly push back on such things, as they have no context and therefore no ability to understand how such a decision was arrived at. They must trust people that do not trust (nor respect) them.
The CTO may be well-liked by the executive team. This is often a red flag, and a good sign that playing politics is their forte, especially when they have no current technical ability.
Your CTO should delight in the technicality of things, should be well versed in your codebase (or at least a part or parts of it), and should know your workflows from experience. A CTO that does engage in the day-to-day work themselves likely has no understanding of the work, the challenges, nor the friction of the processes that exist and that people offer suffer under.
High-performing technology organizations have technical CTOs who understand the work, understand the technology and the trade-offs, and who can make the right decisions about technology direction, architecture, and product implementation approaches without guessing or needing to rely on what others have to say.
If a CTO does not understand your technology stack, they are at the whims of their staff to provide direction, which means divergent approaches, technologies, architectures, and (worst of all) languages will proliferate. There will be no consistency in larger systems, there will be friction in onboarding, in moves of employees between teams and products, and a lack of reusability, all of which are expensive.
Employee management will present a challenge. How do you assess who is performing well? How do you know when someone needs training, or to be terminated? Or when you have a gap that needs to be filled with a hire, and therefore you need to advocate for and find budget for this role? CTOs that do not code do not know. They listen to management.
This same logic applies all the way down, really. If your VPs do not code, they are subject to all the above. If you directors do not code... same problem. If your managers do not code, what do they do all day?? Presumably nothing because managing a team of 10 people is not a full time job in software development.
Worse, a lack of technical understanding in the entire chain of command (manager to director to VP to CTO) magnifies your problems, because no one understands anything up or down, and politics will be played, and money (immense sums of money) will be wasted.
If your CTO did code... well... their skills are not current and they likely are not adding a whole lot to your technology strategy.
I have spoken to hundreds of people who have said they have never met their CTO, and almost every single one of these people worked at a smaller company than the one I led. This is frightening, and sad, and largely a result of your CTO not being able to code. What do they have to talk to their team about? The latest slop they posted on LinkedIn interests no one. It probably even makes the team respect them even less.
Many people will claim that a CTO should not code. This is flat-out wrong, and we do not back any organization where that is the case. If you want to have a leader that cannot lead, you might as well hire no one (and empower someone on your team).
Previous: 2026-06-06: Every Line is a Liability