Fractional CTO vs Full-Time CTO: Hire for the Work

A contact centre had a failure where a deleted conversation task could leave a real person waiting for help. We had to reactivate the conversation, recreate the task with its original routing, return it to the known worker or queue, and give it a two-week timeout.

That is CTO work, but it is sometimes only two days of engineering work, so the title tells you little about which your company needs.

Founders often decide backwards: start with budget or the status of hiring a CTO, then make the role fit. Start with six months of work, who does it, and how often a decision is needed that day.

A fractional CTO is not a cheaper full-time CTO. It is a different operating model with a narrower promise.

The job is either to build, lead, or provide coverage

Separate three jobs companies keep putting into one title.

Building takes a product from unclear brief to working software: reduce scope, choose boring parts, unblock the team in code, review what ships, and keep it deployable.

Leading sets direction for people who can build: standards, architecture, hiring, coaching, performance, team shape, planning, and the product-engineering boundary. It needs context to distinguish disagreement from noise.

Providing coverage means being available when production breaks, a major customer asks a question, an engineer needs an answer, or a security concern appears at 7am. It requires a rota, documented ownership, and people who can act.

A fractional CTO can combine building and leadership for a small focused team: decide what not to build, establish delivery rhythm, make architecture legible, and write the parts needing senior judgement; they can lead an assessment before a costly hire or rebuild, but they cannot be permanent coverage. If a leader must be in the room daily for product decisions and incidents, buy that capacity.

The contact-centre work split cleanly between planned technical design and operational ownership: it combined a React agent desktop, Node.js services, Twilio Flex, TaskRouter, Studio flows, background workers, and a CRM integration, while webchat had normal, out-of-hours, and safeguarding-sensitive paths, and conversation context, recovery behaviour, and queue ownership could be decided in planned time. An offline agent, platform-deleted task, or hand-off retaining reason and destination needed an operational owner, so the first suits part-time leadership while the second needs named coverage.

A fractional CTO works when the company can concentrate its decisions

Part-time leadership works when important decisions are bounded, the founder makes product calls quickly, and the team moves between those decisions.

The strongest fit is a team or contractors without enough experience to judge the work. If estimates drift, requirements arrive late, and integrations surprise the team, you need someone to inspect code and plan, make hard calls early, and prevent three weeks of avoidable work, not another person at every stand-up.

It also fits a replacement workflow: a UK property inventory agency replaced an old PHP integration service joining its source system and Airtable, and the replacement had to preserve historic properties, inspections, report bodies, PDFs, and images before controlled deletion; it also needed an operations workspace, client portal, signed webhooks, a queue, audit trails, and failure replay. These were irreversible decisions while daily work continued.

A fractional lead can raise one or two capable engineers: set review standards, pair on risky changes, turn a roadmap into milestones, and make hiring less random. The team still needs a day-to-day owner, but not necessarily an executive hire.

It can provide an honest technical picture before an investment, acquisition, rebuild, or agency change: what runs, where data lives, which vendor contracts hold the product together, what fails with ten more customers, and whether the team can ship the roadmap. My technical due diligence checklist covers the evidence required.

The company must collect meaningful questions for a regular decision point, then let the team execute, because a fractional CTO can think through consequences but cannot become the human message queue for every uncertainty.

A good engagement has one product goal, known team, stated days per week or month, written decisions the lead owns, and an incident owner for non-working time; "All technical things" is already wrong. It should leave a roadmap, system boundary, tests around risky paths, deployment process, hiring plan, or incident owner.

A full-time CTO earns the cost when coordination is the work

A full-time CTO is justified when technical leadership is a daily operating function: coordination, people management, availability, and cross-team judgement, not a fashionable headcount.

Choose one when product decisions cannot be batched: sales needs technical input on customer calls several times weekly, support uncovers failures needing a fast call, and design, product, data, and engineering dependencies move daily, so shared services, release timing, and platform contracts cannot wait.

It also applies when the engineering organisation needs building, because hiring is role definition, calibration, onboarding, performance feedback, and manager coaching; a fractional CTO can design that system or help with a key hire, but should not run it indefinitely for a growing team.

Reliability can force the same choice. If interruption has contractual consequences, affects safety-sensitive work, or stops revenue, someone must own the operating model full time: rota, usable runbooks, correct access, incident reviews, and no service dependent on one contractor answering a phone.

The Twilio contact-centre platform had a 1,200-second escalation interval: twenty minutes for a task to move through a defined rule, not twenty minutes to decide who owns a production failure, and it also had specialist routing for conversations with risk flags or keyword triggers. Technical design can be part-time, but service obligation cannot.

Full time is also right when the founder no longer wants to make product and priority decisions: some want a technical partner owning daily trade-offs, while others want a builder who turns clear choices into software, and both are valid but different hires.

Do not hire a full-time CTO merely to build an MVP, because that can leave a senior person waiting for decisions and producing strategy while the product stays unfinished; for a first build, a hands-on senior engineer with product judgement is often more valuable.

Most failed CTO hires are a mismatch of tempo

The expensive mistake is buying advisory capacity when you need delivery, or a permanent leader when you need someone hands-on.

The first failure is a founder hiring a fractional CTO because the roadmap is late: the CTO audits code, recommends architecture, produces a plan, and runs a weekly meeting, but no engineers can implement it, contractors wait for answers, and the founder expects every urgent task picked up. The company needed a hands-on builder, probably full time for a period, not advice for a few days monthly.

The reverse is a company hiring a full-time CTO to "get control" of a small product, then giving them unbounded delivery work and no authority over priorities, so they become the most expensive senior developer while product still bottlenecks with the founder and hiring and systems work do not happen.

Then comes the interrupt failure: a fractional lead has four urgent daily requests, such as a custom sales-demo answer, customer data issue, shipping decision, hosting-bill change, or failing integration, which erase the time that would make requests rarer. Part-time leadership does not make unlimited interrupts affordable.

The property platform made this plain during migration: an early image-download path omitted cover images and meter photographs when source records lacked UUIDs, but the integrity check caught it. We verified all 17,595 distinct cover-image URLs and all 42,494 distinct meter-photo URLs in the checked work were in storage, although actions backfill remained incomplete, so we waited before deleting the source set.

The job is to present evidence, name risk, and refuse an unsafe declaration of done; if the company cannot protect that decision from daily pressure, it needs more embedded leadership or operational capacity.

Availability is not a personality trait, and "They are responsive" is not an incident plan: people get ill, travel, sleep, work with other clients, and have boundaries, so neither CTO can be a one-person rota. Build shared access, recovery steps, escalation contacts, and enough engineers to act, then decide where senior oversight belongs.

Use this decision rule before you start interviewing

Write down the next twelve weeks of technical work, not aspirations - feature delivery, production support, hiring, vendor work, migration, customer commitments, security requests, and product decisions - then put each into build, lead, or coverage.

For each item, ask:

1. Does a senior person need to do it, or decide how someone else should?
2. Can it wait for a planned weekly session, or need an answer that day?
3. Who owns it when the technical lead is unavailable?
4. Will it remain after twelve weeks, or is it bounded?

Choose a fractional CTO when important work is schedulable senior judgement, the project is clear, and someone else owns daily support. Add hands-on delivery if no team can execute, and price it as build time.

Choose a full-time CTO for daily technical decisions, engineering management, hiring, cross-team alignment, or a permanent operating owner. Do not hire a one-person emergency department; their first job is making the system less dependent on them.

Choose a hands-on senior engineer or technical product lead when nothing is built; founders skip it because it feels less grand, but a product needs someone who takes a bounded brief, makes sensible calls, and finishes it. My guide to MVP development cost explains why unclear decisions, existing data, and integrations cost more than a feature list suggests.

Choose neither until product-decision ownership is written down. No CTO model repairs a founder who cannot decide what the company makes or a leadership team changing direction weekly without saying so.

Ask candidates for a checkable first 30 days: which system they inspect, risk they reduce, decision they make, what gets written down, and who handles a Tuesday-evening incident when they are unavailable. "Strategy", "alignment", and "mentorship" are not answers.

The engagement must say what it will not cover

The clearest fractional engagement begins with exclusions: no permanent on-call rota, every Slack message, line-managing a team needing daily support, turning an undefined roadmap into delivery without founder or product-owner trade-offs, or fixing a company that needs daily presence while funding one day weekly.

Those boundaries are the honest contract: how a part-time lead stays useful rather than permanently late.

I can reduce a difficult technical problem to decisions that matter, build where risk demands it, give a small team direction, and leave work another engineer can own, but I can also say the company needs another hire, which costs less than six months with the wrong role.

For a wider comparison of ways to buy technical capacity, read freelancer vs agency vs in-house; I work hands-on with founders and small teams at 600 EUR a day, and my CV, work and rates are here.