Right on the money. I've come to similar conclusions over the years. You can't be a CTO without writing code. Not all of it, and certainly not the critical parts, but at least some code.
I've been in a company where I stopped writing code — and I found that I just couldn't keep up. I couldn't participate in architectural discussions, couldn't form opinions based solely on what other people told me. Worst of all, I started losing interest.
These days I strive for a healthy balance. It certainly doesn't make sense for a CTO to write code that is needed in production right now, because other duties might make him unavailable anytime. But prototyping, testing new solutions, writing proof-of-concept code, trying out a major refactoring just to see if it works — these things make sense and they allow a CTO to both perform his regular duties and keep in touch with code/technology.
> I've been in a company where I stopped writing code —
> and I found that I just couldn't keep up. I couldn't
> participate in architectural discussions, couldn't form
> opinions based solely on what other people told me.
Just wanted to add a counter-point; I was CTO for a technical team of ~40 and didn't write code (and joined once the team was already almost that big). While I'm sure I had many failings, I didn't find keeping up with the technology to be any kind of problem, and frequently got involved in the nitty gritty of technical discussions.
I worked with many talented people, but I think was frequently able to make better contributions to the architecture as a direct result of having not been close to the code. Not having any baggage from having not grown up with the company, and from not being day to day at the code-face gave me some altitude, I think.
Do you have a way of measuring? One of the companies I worked for was completely sunk by the "chief technical architect", who to the end was convinced he was making the right choices.
The risk with this approach is that you take "cool" work away from your own engineers. The first question you should always ask is "is there anybody else who really wants to do this or who could learn a lot from it".
Unfortunately, the answer is almost always yes, because in most cases the code that is needed in production now is the least interesting work.
And you don't want to be known as the guy who keeps all the good bits to himself.
I've been in a company where I stopped writing code — and I found that I just couldn't keep up. I couldn't participate in architectural discussions, couldn't form opinions based solely on what other people told me. Worst of all, I started losing interest.
These days I strive for a healthy balance. It certainly doesn't make sense for a CTO to write code that is needed in production right now, because other duties might make him unavailable anytime. But prototyping, testing new solutions, writing proof-of-concept code, trying out a major refactoring just to see if it works — these things make sense and they allow a CTO to both perform his regular duties and keep in touch with code/technology.