The CTO resume,
read by people who cannot read code.
A CTO resume is usually written for the one audience that will never decide the hire. The engineers who could assess it are not in the room. The people in the room — a chief executive, a nominations committee, a search partner — read consequences only: what shipped faster, what cost less, what stopped breaking, and what you refused to build.
What gets read first
The first screen is not read in the order it was written. A reader takes three things in sequence: the size of the estate you were accountable for, the size and shape of the function you ran, and the class of problem you were brought in to solve. Technology names are scanned last, and mostly to check that nothing looks a decade out of date.
This is why a stack list at the top of a CTO resume costs more than it earns. It answers a question the reader did not ask, in a vocabulary they cannot grade, and it expires. A record organised around consequence — availability held through a re-platform, unit cost halved, release cadence moved from quarterly to daily — still reads at the right level in five years.
Estate before stack: transactions or requests a day, environments, data volume, regulated workloads. Use whichever unit your sector actually counts in.
The function as an organisation. Headcount, how many layers, how many of those people you hired, and what attrition looked like while you held it.
The mandate. Scale-up, turnaround, consolidation after acquisition, or first-time productisation. A CTO is hired for one of these and the reader is working out which.
The reporting line and the room you sat in. Reporting to a chief executive with board exposure is a materially different job from reporting through a chief information officer. Both are called CTO.
The numbers that carry weight
Engineering measures itself more thoroughly than any other function and publishes almost none of it. Four families of number travel outside the function: speed, quality, cost and retention. Each has an obvious business translation, and each survives a reference call.
Deployment frequency and lead time from commit to production, with the starting position. Quarterly to weekly is a larger claim than daily, because it names where you began.
Change failure rate and defect escape rate. A leader who publishes the rate at which their own releases fail is read as someone who measures, which carries further than the figure itself.
Platform cost per transaction, per order or per active user. Absolute cloud spend flatters a shrinking business; unit cost is the number a chief financial officer will recognise and argue with.
Availability against a commitment you name. “High availability” is unreadable. “99.95% against a contracted 99.9%, held through a live migration” has a shape a non-engineer can hold.
Regretted attrition in the engineering function and time to fill senior roles. Retention is the only figure that proves you could staff the plan you sold to the board.
Technical debt paid down deliberately: capacity ring-fenced, held for how many quarters, and what it bought. It turns an engineering preference into a governance decision, which is the register the board reads in.
Where CTO profiles go quiet
Three claims appear in almost every CTO record at this level. All three are usually true. None is usually evidenced, and an unevidenced claim in a senior record is read as an ambition rather than a fact.
“Set the technical strategy.” The strategy is never stated. Name the two or three architecture decisions that carried it, what each cost or saved, and — the part that proves authorship — what you decided not to build.
“Built and scaled a high-performing team.” From what to what, over what period, at what regretted attrition, and what happened to the people who could not make the step up. A doubling that lost a third of the original team is a different story from one that held.
“Drove innovation”, or patents and standards work cited as a badge. A granted patent number, a named working group, a published specification and its adoption are checkable. The word innovation is not.
Three lines, rewritten.
The same fact, made checkable. Every figure is illustrative of the shape an evidenced line takes — nothing here is invented on your behalf.
The claim on the left is not wrong. It is simply unreadable as evidence: nothing in it can be checked, compared or priced. The version on the right makes the same statement in a form a search partner can act on.
Owned technology strategy and drove significant cost optimisation across the cloud estate.
Cut platform cost per transaction by 38% over four quarters, by retiring two self-hosted services in favour of managed equivalents and re-architecting the read path, while transaction volume grew 2.4x. Absolute run rate fell despite the growth.
Grew the engineering organisation from 40 to 120 while maintaining a strong culture.
Grew engineering from 40 to 120 across three sites in 20 months, held regretted attrition at 7%, and promoted 9 of the 14 engineering managers from within.
Improved system reliability and reduced production incidents.
Took Sev-1 incidents from 11 a quarter to 2 and mean time to restore from four hours to 38 minutes, funded by ring-fencing a fifth of engineering capacity for debt across six consecutive quarters — a commitment carried to the board and reported against each quarter.