It was hard to tell if he means he doesn’t do meetings at all, though it’s kind of implied. There are lots of high leverage activities around advocating for engineering’s perspectives among the other executives and bringing the business context to engineering, both of which don’t involve directly managing reports.
But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones.
It seems like this sentiment relates closely to the ideas around dual track career progression, and having technical leadership tied to hiring and managing people. Hiring engineering talent is certainly important to the company, but is quite orthogonal to technical decision making and it seems like a natural place to split the role.
"But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones."
The distinction might be something more subtle - I think s good CTO should maintain a deep technical skill, but should do so without putting the technology of the company in jeopardy. I write code, and am a CTO, but I don't write code for our products. I write code in order to continue to develop and maintain deep technical skill. I also manage our technical operations, so I make an effort to a good understanding of the technical areas that are needed to operate - networking, device configuration, IP, etc. In a pinch I am fully capable of making a configuration change to a Cisco switch or a Palo Alto firewall, but in practice I have a team of people that are much better at those tasks. That allows delegation and understanding.
But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones.
It seems like this sentiment relates closely to the ideas around dual track career progression, and having technical leadership tied to hiring and managing people. Hiring engineering talent is certainly important to the company, but is quite orthogonal to technical decision making and it seems like a natural place to split the role.