What to look for in a CTO.

A great CTO has been at multiple companies, at multiple stages, in multiple industries — and stayed long enough at each to actually see the consequences of their decisions. That experience compounds into pattern recognition: knowing what a five-person team needs versus a fifty-person one, when to over-engineer and when not to, what scales linearly and what scales as the square.

You can't fake this. Reading about it isn't the same as having watched a system you architected fall over at 10× scale and learned why. The decisions that look obvious in retrospect are rarely obvious in the moment, and the only way to know which is which is to have made enough of them.

"AI literate" is now table stakes for any senior technology role. But there's a wide spectrum between "has built something with the OpenAI API" and "knows when an LLM is the wrong tool." You want someone toward the latter end.

A good CTO can tell you when an LLM earns its complexity — open-ended language tasks, summarisation, retrieval-augmented Q&A — and when it doesn't: deterministic logic, structured data extraction with a known schema, anything where a regex would work better. They can talk evaluations, hallucination mitigation, prompt injection, and cost-per-request without slipping into vendor talking points.

The tech industry runs on commission relationships. A CTO who's quietly on a referral list for a specific vendor — or who only ever recommends the stack from their last job — is a liability dressed as expertise.

You want someone with strong opinions, weakly held. Someone who can tell you why Postgres usually beats Mongo, why you probably don't need Kubernetes, why Cloudflare is often the right choice — but who will change their mind in front of you when you give them new information. The willingness to be wrong, in public, is itself a signal.

This is the rarest combination in the industry. Most senior technologists are excellent at one or the other — deeply technical, or strategically articulate — but not both. The career incentives split early, and few people have the discipline to keep both muscles trained.

A great CTO can read a pull request, spot the architectural compromise, and explain in two sentences to a non-technical CEO why it matters and what the trade-off is. They can sit in a board meeting and translate "we need to refactor the data layer" into "we have $400k of risk if we don't do this in Q3." This dual fluency is what makes them effective. Without it, you have either a senior IC who can't influence the business, or a strategist who's lost touch with the code.

Most companies treat security as a Q4 panic — the thing they remember when an enterprise prospect sends a 200-question security questionnaire. By then, it's too late to do well. The patches go in, the certificate is earned, and the underlying posture remains weak.

A good CTO bakes security into the defaults: SSO from day one, secrets in a vault, least-privilege access, code-signed artifacts, zero-trust networking. Compliance — SOC 2, ISO 27001 — becomes a paperwork exercise on top of an actually-secure system, rather than the other way around.

Cloud bills and AI inference costs can quietly eat margin. Most engineering organisations have no idea what their actual unit economics look like — they just see a monthly invoice that grows. By the time it becomes a board-level concern, the right time to design for cost was a year ago.

A modern CTO measures cost as a first-class concern: cost-per-customer, cost-per-request, cost-per-feature. They know that an LLM-powered feature might cost forty cents to serve and need to be priced accordingly. They right-size before scaling, not after.

The single most underrated discipline in technology leadership. The teams that write things down — decisions in ADRs, post-mortems after incidents, runbooks for the rest of the team — compound their learning. The teams that don't, repeat the same mistakes every eighteen months as people roll over.

A CTO who writes is a CTO who thinks clearly. The act of writing forces the trade-offs to surface. And it leaves a trail the team can follow when the CTO isn't in the room — which, in a fractional engagement, is most of the time.