The skill that makes CTOs is saying no to things engineers want to build.
The common framing of CTO skills — architecture, hiring, technical vision — is directionally right and also misses the hardest part of the job. What actually separates effective CTOs from smart senior engineers who got promoted is the ability to say no to technically appealing work that doesn't move the business. Every team wants to rewrite the monolith, adopt the new framework, build the shared library, refactor the data pipeline. Most of those impulses are correct technically and wrong strategically, and the CTO is the person who has to kill them without demotivating the team.
This requires two things most senior engineers aren't trained in. First: translating technical decisions into business outcomes with honest numbers, which means learning to speak the language of the CFO and the COO. Second: absorbing the emotional cost of being the person who blocks work, which is not the same thing as being unpopular but can feel similar for a while. These are learned skills, not innate ones, and they're the ones that fail most first-time CTOs.
The practical path if you're tracking toward CTO is to spend more time in business conversations and less time in code reviews, years before you actually need to. The engineers who arrive at CTO conversant with unit economics and org design have an enormous head start.