How to Evaluate a Fractional CTO: A 6-Step Framework for Founders

Be specific about what you need before any conversation

The most common evaluation mistake is going into conversations without a written definition of the gap you are trying to fill. Without it, you will evaluate people on general impressiveness rather than fit. A technically brilliant fractional CTO who has spent the last five years at enterprise scale may be exactly the wrong person for a seven-person seed-stage team.

Before any conversation, write down: which of the four CTO functions is most critical right now (technical strategy, team leadership, delivery oversight, external representation), what you expect the person to have delivered within 90 days, and what "done" looks like for the engagement. If you cannot answer these three questions, the evaluation will not produce a clear outcome regardless of how many people you speak to.

The Engineering Without a CTO Guide includes a diagnostic for identifying which CTO function you are actually missing — this is a useful starting point before you write your own definition.

Ask about the first 30 days, not the long-term vision

A common interview question: "What's your vision for a company like ours in two years?" This question tells you how someone presents and how confident they are. It does not tell you how they will actually behave in the first month.

A better question: "Walk me through what you would do in the first 30 days. What would you spend time on, what would you not spend time on, and what would you have produced at the end of the 30 days?"

The answer you are looking for is one that prioritises understanding over opining. A good fractional CTO will describe some version of: speaking to everyone on the engineering team individually, reviewing existing architectural decisions and their rationale, reading outstanding tickets, understanding what the team has been building and why, and producing a written assessment at the end of 30 days. What they should not describe in day one is fixing things, rewriting systems, or making hiring recommendations before they have understood the existing state.

A fractional CTO who arrives with solutions before they have understood the problem will produce the most expensive kind of engagement: the kind where they are confidently wrong.

Evaluate stage fit, not just technical depth

Technical depth is necessary. It is not sufficient. What matters equally is whether the person has operated at your stage before.

A fractional CTO who spent the last ten years in post-Series-B companies will have deep experience with problems that do not exist at your stage yet: engineering org design at scale, platform team formation, compliance frameworks, architectural decisions for multi-region deployment. They may have relatively shallow experience with the specific problems you actually have: making architectural decisions under extreme uncertainty, hiring the first few engineers, building technical credibility with investors who are not yet convinced of the product.

Ask directly: "What's the smallest team you have worked with as CTO, and what were the hardest decisions you made in that context?" The more specific and concrete the answer, the more likely they have actually done it. Vague answers about "wearing multiple hats" often signal someone who observed startup constraints rather than operated under them.

Test how they handle a real problem from your codebase

The evaluation that tells you the most is a paid test engagement — typically a half-day or full-day session where you bring a real problem and evaluate how the candidate handles it. This is not a free consulting session; you pay for their time and you get real signal in return.

The problem you bring should be one you have already thought about — not to catch them out, but so you can evaluate the quality of their approach against your own thinking. Useful categories: a real architectural trade-off you are currently facing, a process or delivery problem that has been affecting the team, or a technical due diligence question you are preparing for.

What you are evaluating is not whether they reach the same conclusion you did. It is how they handle the problem: do they ask clarifying questions before proposing a direction? Do they acknowledge what they do not know? Do they surface trade-offs or do they present a single answer with confidence? A fractional CTO who treats every problem as having one obvious answer is going to be expensive to work with.

Clarify availability and communication expectations explicitly

The fractional model creates structural ambiguity around availability that needs to be resolved before the engagement begins, not during it.

The questions to resolve: How many days per week are genuinely available — and is that the same days every week or variable? What is the expected response time for async messages on non-engagement days? Who do they report to internally, and how do they handle situations where their advice conflicts with the founder's position? Are there other engagements that could create conflicts of interest or reduce availability?

The failure mode is a fractional CTO who is theoretically available two days a week but in practice unreachable for extended periods when their other clients need them. The engagement agreement should specify availability explicitly. If a candidate is reluctant to commit to specific days, that is useful information.

Check references from companies at your stage

Request two to three references from companies that were at roughly your stage when the engagement ran — same team size, same funding stage, same type of technical challenge. General references from impressive companies at a different scale tell you relatively little.

When you speak to references, the most useful questions are not "would you hire them again?" (almost always yes) but: "What specifically did they deliver in the first 90 days?", "What did the engineering team think of them?", and "What would you tell them to do differently?" The last question is where the most honest information usually lives.