I appreciated the sentiment but I do wonder how on earth a CTO has enough time to write one line of code, let along several thousands. Even before reaching the C-suite roles, higher ups tend to be in meetings all day, back to back. In the short amount of non-meeting time they find, they typically have to do other admin related things or information sharing.
I guess that CTO uses weekends or works super long hours which I is fine if they don't push that expectation onto others.
I'd only really expect a CTO in an early stage startup to be pushing code like this (and eventually stepping back when they grow).
While I think CTOs should take steps back from pushing to production systems because there's a lot of I dotting and T crossing that needs to happen with production systems that CTOs don't reasonably have time for, if a CTO wasn't writing experiments and building test systems to determine technical direction, or at least getting their hands dirty with said systems produced by their top principles, I wouldn't trust their judgment to set direction.
The last time I worked for a product company was 2020. I was the second technical hire by a then new CTO of a growing company started by a two non technical brothers who hired an outside consulting company to do all of the work.
When the company found product market fit, they hired the CTO to bring the technology leadership in house. Early on he would do experimental POC work that he passed on to me to make it a working system as I was swamped doing my own architectural herding cats work as the company was growing.
But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team.
I’ve been working full time for consulting departments/companies since mid 2020. My goal on any project I’m on with more junior people is to development them. I purposefully give them ambiguous technical requirements with broad guardrails so they have the autonomy to learn and grow and then help them when needed and I put them in front of the customer early on to I present their “workstream”.
From a hands on keyboard side, I let them pick what they want to work on first and I take the left overs.
"But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team."
That is a good summary of the progression of a successful CTO. The capabilities of the team is a summation operations, not a selection operation.
This might be best said as you want your CTO to be ABLE to build and operate your products, but not actually do it.
I like to say that my job as a CTO is to be able to do the job of most the people that work for me, but most of the people that work for me are much much better at it.
I guess that CTO uses weekends or works super long hours which I is fine if they don't push that expectation onto others.
I'd only really expect a CTO in an early stage startup to be pushing code like this (and eventually stepping back when they grow).