CTO plain-English.

The title covers at least four different jobs. At ten people the CTO of a company writes most of the code. At fifty they stop writing it and start deciding what gets written. At two hundred they are running managers, budget, and vendor contracts. At two thousand they are largely an external role — analysts, partners, keynotes — while a VP of Engineering runs the actual building. Same three letters, four entirely different weeks.

What stays constant is accountability for technical consequence. Architecture that will still stand in three years, build-versus-buy calls, security and regulatory exposure, the hiring bar, and the honest answer when the roadmap and the engineering reality disagree. A CTO who cannot say no to a date is a title, not a role.

Two common confusions. A CTO is not the same as a VP of Engineering: the VP owns delivery — throughput, quality, the team's operating system — while the CTO owns direction and risk. And a CTO is not the most senior engineer with a nicer title; the job is judgment under uncertainty, most of it exercised in rooms with no code in them. Plenty of companies promote their best engineer and then wonder why the architecture drifted.

Most companies under fifty people need CTO-grade judgment a few days a month, not five days a week — which is why the fractional version of the role exists and why full-time CTO hires so often get made twelve months too early.