Fractional CTO Red Flags: 11 Warning Signs

1. No post launch story in the portfolio

The candidate can describe past architectures in detail — the stack, the tradeoffs, the decision rationale. But when you ask what happened six months after go live, the story goes quiet. You hear about designs, not outcomes.

A fractional CTO who cannot speak to post launch consequences has not been accountable for them. The work that compounds — learning from production failures, correcting early architecture decisions under real load, scaling a team through the first growth curve — happens after the initial launch. Gaps here suggest engagement without accountability.

Ask directly: walk me through an architectural decision you made that turned out to be wrong. What did you do about it? A senior practitioner has this story ready. Someone without post launch accountability will generalize or deflect.

2. Refuses references from founders they served for more than six months

References exist, but they cover short engagements — project based work, advisory roles, vendor relationships. No one who worked with them closely in a fractional capacity for six months or more.

The first 90 days of a fractional engagement are the highest trust period. The real friction — missed deadlines, misaligned priorities, communication breakdowns, architectural disagreements — shows up in months four through twelve. References who only saw the first quarter tell you almost nothing useful.

Ask for two references from founders or CEOs they served in a fractional role for at least six months. A first fractional engagement is a legitimate answer. No satisfactory answer is not.

3. No curiosity about the gap between their stack and yours

Their recent production work is in Python and FastAPI. You are running a Node.js monorepo heading toward a distributed architecture. They do not ask about your tooling, your team's strengths, your technical debt, or your current constraints before the conversation moves to what they would change.

Senior technical leaders who have worked across stacks know the gap between their familiarity and your context matters. Their first instinct is to understand the system before opining on it. Absence of curiosity is not confidence — it is pattern matching from prior engagements rather than engaging with your specific situation.

Bring a specific current architectural challenge to the conversation, unresolved and honest. Watch whether they ask more questions or immediately reach for answers. The quality of their questions is what you are evaluating.

4. Time based retainer with no outcome anchor

The proposal is a monthly rate for a set number of hours per week. There is no definition of what deliverables, milestones, or outcomes correspond to that time. Everything beyond the rate is verbal.

Without outcome anchors, there is no accountability mechanism. When the engagement goes sideways — and most do in the first 60 days, at least once — there is no shared definition of success to return to. You are paying for presence, not progress.

Ask for a first quarter plan with three or four concrete deliverables and their success criteria. The willingness to commit to them in writing tells you more than the deliverables themselves. The fractional CTO hiring guide has a template for structuring this conversation.

5. No architecture audit or current state document by day 14

Day 14 arrives and there is no written summary of the system. No inventory of services, no debt map, no list of architectural risks, no assessment of team capacity versus roadmap ambition. Meetings have happened. Syncs have occurred. Nothing is written down.

Writing forces clarity. A fractional CTO who cannot produce a current state document in two weeks has not absorbed enough to be useful, or has not made the effort to structure what they have learned. The document does not need to be complete — it needs to be honest and specific.

Set the expectation before day one. Ask for a written current state by day 14, even a working draft. The specificity and honesty of that document is a direct proxy for their system comprehension and communication discipline.

6. No written hiring plan

You brought in the fractional CTO partly to build the technical team. Three weeks in and you have no skills matrix, no role priority ranking, no timing model, no definition of what the engineering organization needs to look like in six months.

Hiring is the highest leverage technical work in the first year of most startups. A fractional CTO who cannot articulate a hiring framework is not thinking about the team the way a full technical leader would. This is a coverage gap, not a stylistic preference.

Ask for a draft hiring plan in week three. The roles they would hire first, the criteria for each, and the reasoning. If they have not thought about it, this request will surface that. If they have thought about it but not committed it to writing, this request will surface that too.

7. No defined delivery milestones or velocity metric

You have no way to measure progress. There is no sprint cadence, no delivery milestone, no agreed leading metric for technical velocity. Each week you hear that things are moving, but you have no frame for whether moving is fast enough.

A fractional CTO who does not establish a shared measurement model is setting up an unresolvable dispute. When you feel progress is insufficient and they believe it is on track, you have no shared ground to return to. The absence of metrics is not an engineering philosophy — it is an accountability gap.

Ask in week two what the leading indicator of technical progress looks like in your context. It does not need to be a complex framework — it can be a deployment frequency, a debt reduction milestone, or an outcome metric. The metric matters less than the willingness to commit to one.

8. No on call or incident runbook proposed

The system goes down. No one knows who owns it. There is no runbook, no escalation path, no communication template for an incident. The fractional CTO has not proposed one.

Incidents are the highest leverage moments for engineering trust and culture. A technical leader who does not treat incident response as a first class infrastructure concern in the first month is telling you something about how they view operational accountability. You do not need a sophisticated on call rotation in week two. You need evidence they are thinking about it.

Ask in week three: what does our incident response process look like today, and what should it look like in 60 days?

9. Still planning at 90 days with nothing shipped

The planning documents are thorough. The roadmap is detailed. But no engineering milestone has been completed. Nothing has gone to production. The team is still in analysis mode.

Planning without delivery is a risk accumulation pattern. A fractional CTO should be establishing credibility with the team by demonstrating they can get things done, not just advise on them. A leader who cannot ship an initial increment in three months will not become easier to work with over time.

Have an explicit delivery conversation at the 60 day mark, not the 90 day mark. Ask: what are we shipping in the next 30 days? If the answer is still that more planning is needed, you have your signal.

10. Greenfield rewrite proposed as the first major initiative

Within three months, the fractional CTO proposes a full rewrite — new framework, new architecture, clean break from the current codebase. The proposal frames the existing system as fundamentally unsalvageable. The migration path is vague or deferred to a later phase.

Greenfield rewrites are almost never the right first move. They take longer than estimated, they carry your existing bugs forward under a new name, and they stop all feature delivery during the build period. A technical leader who reaches for a rewrite in the first 90 days has not yet understood the system well enough to know what the real problem is.

Ask for a detailed comparison of the rewrite option against three to five incremental alternatives, with timeline, risk, and opportunity cost estimates for each. A fractional CTO who is right about the rewrite will welcome this analysis. One who cannot produce it should not be the one leading it.

11. No succession plan or knowledge transfer framework

Three months in and all architectural context, vendor relationships, team dynamics, and technical roadmap direction lives in one person's head. There is no documentation plan, no internal development track, no defined transition framework.

A fractional engagement that does not build internal capability is a dependency, not a resource. The exit of a fractional CTO who has not built succession structures creates a gap proportional to how long they were engaged. By day 90, there should be a clear picture of what stays when they leave.

Ask explicitly in month two: what is your plan for knowledge transfer, and what does a healthy internal capability look like at the end of this engagement? A strong practitioner will have thought about this before you ask.

The response depends on the stage and the number of signals.

One signal, before signing: ask the direct question it maps to. The signal itself is not disqualifying — the response is.

Two or more signals before signing: do not proceed until you have satisfactory answers. The evaluating an AI consulting proposal guide has a structured due diligence framework that applies equally well to fractional CTO candidates.

One signal in the first 30 days: name it explicitly in a one on one and ask for a specific commitment with a specific date. Write it down.

Two or more signals in the first 30 days: this is a performance conversation, not a wait and see situation. Define what success looks like in the next 14 days.

Any delivery gap at 90 days: this is structural. Either the scope is wrong, the accountability model is wrong, or the engagement fit is wrong. If you are starting to question whether the engagement model itself is the issue, the fractional CTO versus technical cofounder comparison is useful for that decision.

If you want to understand what a well structured fractional CTO engagement looks like by default — including the deliverables, timelines, and accountability structures built into a well run engagement — the fractional CTO service page outlines the engagement model I use.