What a fractional CTO actually does, and when a startup should hire one

I have been a fractional CTO since June 2023. Before that I was VP of Software Engineering at Talent Systems, where I led 60+ web, mobile and QA engineers across eight product lines and then ran the full 100+ person org, including IT and DevOps, for about six months. People ask me what the fractional version of that job looks like, usually because they are trying to decide whether to hire one. This is the honest answer.

What a fractional CTO is

A fractional CTO is a senior engineering executive who works for your company part time, on a fixed cadence, with real authority over technical decisions. Not an advisor who takes a call once a month. Not a contractor who writes tickets. Someone who owns the technical direction of the company for one to three days a week and is accountable for what happens.

The word "fractional" describes the time, not the responsibility. When I am in the seat, I am the CTO. I sit in leadership meetings, I make architecture calls, I hire and sometimes fire, and I answer to the founder and the board for engineering outcomes. The difference from a full-time CTO is that I am doing it for a few companies at once, and each one pays for the slice it needs.

What the week actually looks like

The job has four parts, and in a normal week I touch all four.

Technical strategy. Which platform do we build on, what do we buy instead of build, how does the architecture need to change before the next stage of growth, and where is the technical debt that will actually hurt us versus the debt that is fine to carry. These are decisions with long shadows and most early teams make them by default rather than on purpose.

People and org. Who do we hire next, what does the team structure look like at twice the size, who is ready to lead, and who needs coaching. At PublicSq. I grew the engineering team from 4 to 24 in under a year. Most of that was hiring loops, onboarding, and making sure ownership was clear enough that new people could ship in their first week.

Delivery. Is work moving, is it the right work, and does the founder know what is shipping next month. I set up a weekly operating rhythm with visible metrics, a 90-day plan with owners and checkpoints, and release practices like feature flags and CI/CD so speed stops breaking quality. At Talent Systems that discipline doubled sprint velocity and cut production incidents by 80 to 90%.

Hands on the code. I still write and review code. Not because the team needs another engineer, but because a CTO who cannot read the codebase is guessing. Some weeks that means reviewing the pull request that changes the auth model. Some weeks it means pairing with a senior engineer on a migration plan. For the last couple of years it has also meant installing AI and agentic engineering workflows and staying close enough to know whether they are working.

What you are paying for

Founders sometimes think they are paying for hours. They are paying for decisions and for the absence of certain mistakes.

The expensive mistakes at the seed to Series B stage are predictable. Hiring a team around the wrong architecture. Choosing a vendor that cannot scale and finding out during a launch. Letting one engineer become the only person who understands production. Running without SLOs until a customer leaves. Signing an enterprise deal that needs SOC 2 and realizing nobody has started. I have led SOC 2 readiness end to end for fractional clients, and the difference between starting early and starting under deal pressure is months.

A fractional CTO has usually seen each of those mistakes several times. That pattern recognition is the product. The weekly cadence is just the delivery mechanism.

When a startup should hire one

Five signals, in roughly the order I see them.

The founder is the de facto CTO and does not want to be

Plenty of non-technical founders end up running engineering by default. They manage a contractor or a small team, make technical decisions they are not confident in, and spend their evenings reading about databases. That works until it does not. If you are the founder and engineering is the part of your week you dread, you are the signal.

There are engineers but no technical executive

The company has three to twenty engineers, a lead who is strong but has never run an org, and nobody at the leadership table who can translate between the business and the codebase. Roadmap conversations turn into estimation arguments. Hiring stalls because nobody can judge senior candidates. This is the most common case I get called into.

Technical due diligence is coming

A fundraise, an acquisition conversation, or a large enterprise customer is about to look under the hood. You want someone who has been on both sides of that review to find the problems before the other party does. I cover this kind of work on the CTO consulting page.

The product works but production does not

Outages, slow releases, a backlog of bugs that never shrinks, and engineers who are tired. Usually this is a systems problem rather than a people problem, and it responds quickly to the right release discipline, observability and ownership structure.

You want AI in the engineering process and nobody owns it

Every team is experimenting with coding agents. Few have anyone responsible for turning that into a working practice with review gates, testing rules and spend controls. That is a leadership job, and it is a growing share of mine.

When you should not hire one

A fractional CTO is wrong for some situations, and I would rather say so up front.

If you have no engineers and no product yet, you need a technical co-founder or an agency, not an executive. If you already have a strong CTO and the problem is bandwidth, hire a VP of Engineering or an engineering manager. If you need forty hours a week of someone in the seat for the foreseeable future, hire full time and treat a fractional engagement as the bridge. I wrote more about that choice in fractional CTO vs full-time CTO vs VP of Engineering.

The other bad fit is a company that wants the title on the slide deck but does not want the person to change anything. The work only pays off when the fractional CTO has the authority to make decisions and the founder is willing to act on them.

How an engagement starts

My engagements start the same way regardless of company size. Week one is discovery: architecture, team, delivery process and spend. I listen more than I talk, and I read the code. Week two is a priority roadmap and a 90-day plan with owners and checkpoints. Week three sets the operating cadence, the dashboards and whatever staffing changes are obviously needed.

From there it is one to three days a week, scoped by the quarter. If the numbers say the engagement should continue, it does. If the company has grown into a full-time hire, part of my job is to help make that hire and hand off cleanly. The structure and pricing models are covered in how fractional CTO engagements are structured and priced.

What good looks like after 90 days

The founder knows what engineering is doing and why. There is a written plan with names on it. Releases go out on a schedule without heroics. Production has alerts that mean something and a person on call who knows what to do. The next two hires are defined. The biggest architectural risk has a mitigation underway. And the engineers, who are usually the people most relieved by all of this, are shipping more than they were.

If that is what you need, the fractional CTO page describes the engagement, my resume covers the background, and the contact page is the fastest way to start a conversation.

Frequently asked questions

How many hours a week does a fractional CTO work?

Usually one to three days a week on a fixed schedule, plus availability for urgent calls. Advisory-only arrangements can be a few hours a month. The cadence is agreed in writing before the engagement starts.

Is a fractional CTO the same as a technical advisor?

No. An advisor gives opinions on request. A fractional CTO owns technical decisions, runs the engineering function on their days, and is accountable for outcomes like delivery, reliability and hiring.

Can a fractional CTO manage the engineering team directly?

Yes, and in most of my engagements I do. Engineers report to me on the days I am in the seat, and a lead or manager on the team runs the day to day in between. For larger teams the fractional CTO usually manages the managers rather than every engineer.

What size company is a fractional CTO right for?

Most commonly startups and mid-sized companies with roughly 2 to 100 engineers. Below that you probably need a technical co-founder or an agency. Above that you usually need a full-time executive, with a fractional leader as a bridge or for a defined project.