From fractional to full-time CTO: how to plan the handover

Moving from fractional to full-time CTO leadership makes sense once the job fills the whole week: decisions wait days for your part-time CTO, the team keeps growing and the roadmap never pauses. Start the search three to six months ahead, let your fractional CTO help hire their successor, and plan a few weeks of overlap.

Done well, the switch is boring. The new CTO inherits a documented system, a working team and a clear roadmap, and customers never notice. Done badly, you lose months of context, a former contractor's personal email still owns the cloud account, and your expensive new hire spends their first quarter on archaeology. Here is how to plan it, from someone who sits on the fractional side of the table.

When should you switch from a fractional to a full-time CTO?

The trigger is workload and stakes, not a funding announcement or a nagging feeling that real companies have a full-time CTO. These are the signals I watch for:

• Decisions are waiting on the calendar. Pull requests, architecture questions and vendor calls sit for days until your CTO's next slot. When the team routinely says “let's ask on Thursday,” the part-time model has become the bottleneck.
• The hours keep creeping up. You have extended the retainer twice and your fractional CTO is close to full-time anyway. You are now paying for most of a full-time job without full-time commitment.
• There is a real team to lead. With somewhere around five to eight engineers, the one-on-ones, hiring loops, career conversations and code review alone can fill a week.
• The hiring plan is big. If you intend to double the engineering team within a year, someone needs to run recruiting, onboarding and team design every single week.
• The stakes have changed. Enterprise security reviews, uptime commitments, an on-call rotation, an advantage that now lives in proprietary technology, or a growth round where investors ask who will run engineering for the next three years.

One signal on its own rarely justifies the move; two or three together usually do. Some things are not signals at all: a single big contract, an investor's offhand comment, or wanting the org chart to look complete. If you are not sure you are there yet, compare fractional and full-time CTOs on cost, commitment and fit first.

Is a full-time CTO really the next hire?

Before writing a job ad, check that a full-time CTO is the role you are missing. Often the gap is not technology direction but day-to-day management, and that can be filled faster, cheaper and with less risk.

Promoting from within is underrated. Your best senior engineer already knows the codebase, the customers and the team, and a promotion tells everyone else there is a path upward. The risk is losing a great engineer and gaining an unhappy manager, so treat it as a supported trial: your fractional CTO can coach them for a few months before the title becomes permanent.

If the real problem is that nobody runs delivery day to day, read up on how the CTO and VP of Engineering roles divide the work before you decide. Plenty of companies whose technology supports the business, rather than being the business, do well with a full-time engineering lead plus a fractional CTO setting direction a few days a month.

How your fractional CTO should help hire their successor

Your fractional CTO knows the system, the team and the gaps better than anyone, so use them. That is how I see my own role: I stay on as CTO for as long as a company needs one, and when it outgrows one person, I hire and manage the team around the founder. Helping hire whoever eventually takes the seat is the natural end of that job.

A fair question is whether a fractional CTO has an incentive to slow-walk their own replacement. A good one will not, and you can make that structural: agree up front that hiring and handover are part of the scope, and pay for that work like any other.

Write the role spec from the real job

Generic CTO job descriptions attract generic candidates. Your fractional CTO can write the spec from what the role involves today and over the next 18 months:

• Stage, current team size and the hiring plan for the next year.
• The stack and the main technical challenges ahead: a migration, scaling, an AI feature, a compliance audit.
• How hands-on the job is: shipping code weekly, reviewing code, or leading only.
• Who the new CTO reports to and which decisions they own.
• What success looks like at 6 and 12 months, in concrete terms.

The classic mistake is hiring for the title rather than the job: a big-company executive who has not written code in years, joining a five-person team that needs someone to review pull requests. Budget honestly too, because a full-time CTO's salary, equity and hidden costs add up quickly.

Split the interviews

The founder judges leadership, values and whether you can work together for years. The fractional CTO judges technical depth. A loop I would use:

1. A walkthrough of your real architecture, where the candidate asks questions and critiques it. Strong candidates ask about users and constraints before they mention tools.
2. A conversation about a past technical decision that went wrong and what they changed afterward.
3. A working session on a live problem from your backlog, paid if it runs beyond a couple of hours.
4. Time with the engineers they would lead, who give their feedback afterward.
5. Reference calls, including at least one person who reported to them.

Plan onboarding before the offer is signed

Agree on the start date, who prepares access and what the first month looks like before anyone signs. That month should be about learning: reading code, sitting in on releases, meeting key customers and every member of the team. Big changes can wait until the new CTO has context.

The CTO handover checklist

This is what I would want the outgoing fractional CTO to have ready before the new hire's first day, and to walk through together in the first two weeks:

• Accounts owned by the company. Code hosting, cloud, domain registrar, DNS, app stores, payment providers, email services and analytics all sit in company-owned accounts, with the new CTO added as an admin.
• Credentials in a company password manager. No secrets in anyone's head or personal vault. Rotate keys and passwords once the outgoing CTO's access is reduced.
• Architecture overview. A diagram and a page or two of plain description: the main components, data flows, third-party services and where the data lives.
• Architecture decision records. Short notes on why each major choice was made, what the alternatives were and what would make you revisit it.
• Runbooks. How to deploy, roll back, restore a backup and handle an incident, tested by someone other than the author.
• A technical debt register. An honest list of known problems, the risk each one carries and a rough cost to fix.
• Roadmap and commitments. What is in flight, what was promised to customers or investors, and what was deliberately deferred.
• Budget and renewals. Cloud and tool spend, contract terms and renewal dates, so nothing renews unnoticed.
• Vendors and contractors. Who does what, on which terms and notice periods, with candid notes on performance.
• Team context. Each person's strengths, growth areas and open concerns, any promises made about roles or pay, plus open roles and the candidate pipeline.
• Security and compliance. The current posture, open findings, data protection obligations and anything a customer or auditor is waiting on.

If most of this already exists, your fractional CTO has been doing the job properly. If it would take weeks to produce, start now, whether or not you are hiring. Make it a contractual deliverable rather than a favor: the handover clauses in a fractional CTO contract are where it belongs. And if any account turns out to be in someone's personal name, fix that first; here is how code and account ownership should work.

How long should the overlap last?

For most startups going from fractional to full-time CTO, I would plan four to eight weeks of overlap: shorter for a small, well-documented system, longer if there is a team to hand over or a big migration in flight. A phased overlap works far better than an abrupt switch:

1. Weeks 1 and 2: shadow. The fractional CTO still leads. The new CTO joins every meeting, reads the code and works through the checklist with them.
2. Weeks 3 and 4: reverse shadow. The new CTO leads planning, reviews and decisions. The fractional CTO observes and flags anything missed.
3. Weeks 5 to 8: on call. The new CTO owns everything. The fractional CTO keeps a weekly check-in and answers questions as they come up.
4. After that: optional advisory. A few hours a month for three to six months, if both sides find it useful.

Two rules make it work. Name the date when decision rights move, and tell the team, so nobody can play one CTO against the other. And have the founder announce the change, with the outgoing CTO visibly handing over authority: to the team first, then to investors and key customers.

Mistakes that make the transition painful

• Starting the search too late. A full-time CTO search often takes three to six months, plus notice periods. Waiting until your fractional CTO is overloaded means months of strain on everyone.
• Ending the fractional engagement on the new hire's first day. Everything that was never written down leaves with them. Budget for the overlap.
• Two CTOs at once. Without a dated handover, the team does not know whose decision counts, and the loudest voice wins.
• Letting the outgoing CTO choose alone. Their technical judgment matters, but you will work with this person for years. The final call is yours.
• Expecting a new roadmap in week two. Give the new CTO room to learn before they redesign anything.

The bottom line

Make the move from fractional to full-time CTO when the work fills the week and the stakes call for someone all-in, not because a round closed. Use your fractional CTO to write the spec, judge technical depth and hand over properly, and keep them on as an advisor if that helps. The best handover is a boring one: nothing breaks, nobody panics, and the new CTO starts with everything they need.