When a fractional CTO is the wrong answer

The question arrives in almost the same words every time: we are too small for a CTO, should we get a fractional one? It is the right instinct and the wrong first question, because the answer does not turn on your size, stage or budget. It turns on whether the job in front of you is made of decisions or made of presence. Fractional leadership supplies decisions on a schedule; it cannot supply presence, and no amount of seniority changes that. Four tests tell you which you have.

Start with what the arrangement actually is, because the word invites the wrong model. Fractional is not a discounted executive or an advisor with a better title. It is a senior technical leader who owns a named set of decisions on a recurring schedule — commonly one to three days a week — and who is genuinely absent the rest of the time. Everything below is downstream of that. The failure modes here are almost never competence failures; they are authority and availability failures, both predictable before anybody is hired.

The first test is authority, the one buyers skip. When a decision this person is supposed to own arrives, does it route through them, or around them? If you cannot answer that about a full-time employee you already have, you will not answer it about somebody who is in the building on Tuesdays.

The most instructive evidence here is not from startups. The US Government Accountability Office reviewed how 24 federal agencies defined the role of their Chief Information Officers and reported that “None of the 24 agencies have policies that fully addressed the role of their Chief Information Officers (CIO) consistent with federal laws and guidance”, and that “the majority of the agencies did not fully address the role of their CIOs for any of the six key areas that GAO identified” (GAO, Federal Chief Information Officers: Critical Actions Needed to Address Shortcomings and Challenges in Implementing Responsibilities, GAO-18-93, August 2018). This is a role created by statute, in organisations where, per the same report, “Agencies plan to spend more than $96 billion on IT in fiscal year 2018”. The title existed. The money existed. The written authority did not.

What GAO found next matters most for a fractional engagement: “officials from most agencies stated that their CIOs are implementing the responsibilities even when not required in policy”, and yet the CIOs themselves “acknowledged in their responses to GAO’s survey that they were not always very effective in implementing the six information technology (IT) management areas”. Doing the work informally is not the same as being able to decide, and the report is direct: “Until agencies fully address the role of CIOs in their policies, agencies will be limited in addressing longstanding IT management challenges.”

A federal agency is not a fifteen-person company and the finding does not transfer whole. The transferable part is narrow: a title does not create decision rights, and a part-time title is more exposed to that gap, not less. Before the first day, write down three lists — the decisions this person makes alone, the ones they make with you, and the ones they only advise on. If you cannot populate the first, you have a hole where an internal decision-maker should be, and somebody who visits will not close it.

The second test is latency: for each decision waiting on this role, how long can it wait? Architecture selection, model and vendor choice, build-versus-buy, the design of a hiring loop, the technical half of a board narrative — all tolerate a week and are usually better for it, because batching a decision behind a week of thinking beats making it in a corridor. That is the natural habitat of the model. Now list what cannot wait a week. A production incident. A security disclosure arriving in an inbox. An engineer resigning. A customer escalation needing a technical answer today. None are edge cases you can plan away, and all land on days a one-day-a-week leader is structurally absent.

The vocabulary for this is sharpest in security guidance. The National Institute of Standards and Technology added a GOVERN function to version 2.0 of its Cybersecurity Framework, defined as “The organization’s cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored”, with a category covering “Cybersecurity roles, responsibilities, and authorities to foster accountability, performance assessment, and continuous improvement” (NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26 February 2024). Read the verbs underneath it. “Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving.” “Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced.”

Established and communicated are things a visiting leader does well, often better than an incumbent who has stopped noticing what is undocumented. Understood, enforced and continually improving are not events; they are conditions that must hold on the days nobody senior is scheduled. A fractional CTO can write the policy, and will usually write a better one than you would otherwise get — but somebody there on Thursday has to enforce it. If no such person exists, their first job is naming who carries each continuous obligation. The jobs that must carry a name the day a system goes live are set out in who owns an AI system after it ships; a fractional leader can hold one or two, never all.

The third test is the simplest and catches the most expensive mistakes. Is this a hands-on need or a leadership need? That is the first question in our own intake for the role, because the two present identically to a founder under pressure: both feel like engineering is not moving fast enough.

Here is the discriminator. Write down the three things that must be true in ninety days, then check what kind of object each is. The architecture is decided and written down. We have chosen between building the retrieval layer and buying one. There is a hiring plan and an interview loop a non-engineer can run. Those are artefacts one senior person produces by thinking and writing, and a fractional CTO produces them faster than a new full-time hire would, having made the same decisions elsewhere. But if one of your three is that a feature is live in front of customers, you have a capacity problem wearing a leadership costume — a fractional CTO will direct that work and will not perform it.

The fourth test is the subtle one, and where the research helps most. DORA, Google Cloud’s DevOps Research and Assessment programme, measures leadership through five dimensions taken from Rafferty and Griffin: Vision, Inspirational communication, Intellectual stimulation, Supportive leadership and Personal recognition (DORA, Transformational leadership). Its central finding is not that leaders drive delivery directly, but that “effective leaders impact software delivery and organizational performance indirectly, by enabling teams to adopt technical practices and lean product management practices”. The association is large: “teams with the least transformative leaders (the bottom third) were also far less likely to be high performers at software delivery — in fact, they were half as likely to exhibit high software delivery performance”.

Now split those five by what each needs to exist. Vision and intellectual stimulation are portable — they survive a schedule, and are arguably improved by somebody who arrives with distance, since DORA describes intellectual stimulation as challenging people “to rethink some of their basic assumptions about their work”. Supportive leadership, “Considers others’ personal feelings before acting”, and personal recognition, “Commends team members when they do a better than average job”, are per-person and continuous. DORA is explicit: “It’s crucial that these behaviors are demonstrated consistently, and particularly when the team is under stress.” Under stress is exactly when a fractional leader is measured in days since last contact.

So the fourth test is about the team rather than the work. If your engineering team is small, stable and reasonably confident, a fractional CTO adds the two dimensions it is most likely missing. If your team is demoralised, has just lost someone, or does not trust whoever last held this role, a part-time leader will not repair it — recognition and support cannot be batched, and DORA’s own conclusion is that “leaders cannot achieve higher performance on their own”. Two caveats about that evidence: the findings are correlational, and the outcome measured is software delivery performance rather than commercial success. DORA itself warns that “the presence of leaders with transformational characteristics is not enough to achieve high performance”.

Three things a fractional CTO cannot fix, whoever they are, because they cause most of the disappointment. The first is an undecided product: no architecture rescues a build whose customer has not been chosen, a decision that sits on the founder’s side of the boundary in what a non-technical founder should own. The second is a founder who will not release the decisions the role exists to make — the GAO pattern in miniature, and the failure most often blamed on the hire. The third is missing information: if nobody can tell a wrong answer from a right one in the AI system you are building, the first months go into building that capability rather than the roadmap. That is the correct order of work, and only a disappointment if nobody said so in advance.

The signals that you have outgrown the arrangement are behavioural rather than financial. The queue of decisions waiting for the scheduled day is longer than the day. Incidents get resolved by whoever is nearest rather than whoever is accountable. Hiring decisions are made between sessions because they cannot wait. Engineers have quietly started routing around the role — the same failure GAO documented. When two of those are true, the fix is usually not a full-time CTO immediately: days per week is a dial and an executive hire is not, so turn the dial first. If the gap is specifically AI roadmap, model selection and governance rather than engineering broadly, what you are describing is a fractional Chief AI Officer rather than a second CTO.

Where the model genuinely wins is decision-dense work with a long tolerance for latency, and AI has made that category larger. Provider selection is no longer a one-time choice, because models are retired on published schedules and a migration can be forced on you by a date somebody else set. Build-versus-buy has become build-versus-buy-versus-assemble. Technical due diligence now covers data access, permissions and evaluation, not only code. Those are judgement calls made a handful of times a quarter by somebody who has made them before — precisely the scope a fractional CTO AI engagement is built around, alongside architecture ownership, hiring plans and the board-facing narrative.

For what decision-dense looks like in delivery rather than a role description, a 150-branch student information system is a useful reference shape. The choices that determined the outcome were architectural and made early: per-branch data isolation and audit trails designed into the deployment rather than retrofitted, and a revenue and royalty engine with per-branch rules instead of spreadsheets. Neither needed the person who made them present every day; both would have been ruinous to reverse a year in. That asymmetry is the argument for fractional leadership, and the argument against using it where the work is continuous.

If you are not sure whether your gap is leadership, capacity or evaluation, an AI readiness assessment will answer it in less time than a month of the wrong hire costs. And read hiring your first engineer when you cannot judge one before you interview anybody for this role, because the same problem — evaluating work you cannot personally assess — applies with more force to the person who will evaluate everyone else.