The fractional CTO playbook: what four hours a week actually buys you
Four hours a week is enough to fix architecture, hiring, and roadmap if you spend it on the right things, and useless if you spend it reviewing pull requests.
tl;dr. Most fractional CTO engagements fail because the founder hires for hours instead of for outcomes. Four hours a week is enough to fix architecture, hiring, and roadmap if you spend it on the right things, and useless if you spend it reviewing pull requests. Here is what I do in those four hours, what I deliberately do not do, and how to tell the two engagements apart before you sign.
A founder told me last month that they had tried a fractional CTO and it had not worked. When I asked what the engagement actually looked like, the answer was that the person attended their daily standup, reviewed pull requests on Friday, and sat in on sprint planning every other week. That is not a fractional CTO. That is an expensive observer with the title of one.
The category is genuinely confusing right now, partly because demand for fractional and interim engineering leadership is growing faster than the language for describing it. So before you hire one, you should know what you are actually buying, because the four hours you are paying for are a tiny attention budget that breaks down very differently in a healthy engagement than in a broken one.
The category problem
There are at least four roles that get sold under similar names, and most founders do not know they are different until something goes wrong.
A fractional CTO is a senior engineering leader who works with you part time, on retainer, on outcomes that span months. They own decisions like architecture direction, hiring strategy, and technical risk, but they do not own delivery for any specific feature.
A technical advisor is lighter touch. Two hours a month of strategic input, usually paid in equity, often a former CTO of a peer-stage company. The output is sounding-board quality, not executable plans.
An interim CTO is a full-time leader for a fixed window, usually three to nine months, while you search for a permanent hire or while the company finishes a hard transition. They run the team, ship product, and sign on the line for delivery.
A staff engineer for hire is a senior individual contributor selling their hours by the week. They write code and review it. They are not running anything.
The single most common founder mistake is paying fractional-CTO money for what turns out to be staff-engineer-for-hire work. The titles look similar from a distance and the rates are similar, but the value you get is not.
What four hours a week actually contains
A fractional CTO is paid for outcomes, not for presence. Four hours a week is a budget, not a calendar. If I spend three of those hours on a hiring scorecard and one of them on a weekly sync with the founder, that is a normal week. If I spend all four in your standups, you should fire me, and I will agree with the decision.
The shape of a healthy engagement looks roughly like this. One weekly sync with the founder, usually 45 to 60 minutes, focused on the next two strategic decisions rather than the current sprint. One written deliverable per week that both the founder and the engineering team can reference, whether that is an architecture decision record, a hiring scorecard, a vendor evaluation, or a quarterly technical roadmap. Async review on architecture proposals, hiring loops, and any technical claim the company is about to make to investors or customers.
That is the whole job. Notice what is not on the list. I do not write production code. I do not run your standups. I do not manage individual engineers, although I will sometimes coach the person who does. I do not own delivery for any sprint, and I will not let myself be made accountable for one. The reason I do not do those things is not that they are beneath me, it is that doing them would make me redundant with whoever you are paying full-time to do them, and would also make me unable to do the things only an outside senior voice can do.
The first thirty days
When I start an engagement, the first thirty days are an audit, a risk register, and a hiring plan. They are not a code commit.
The audit is straightforward. I want to understand the architecture, the deployment pipeline, the data model, the on-call rotation, the security posture, and the people. I read the wiki if there is one, the README files if not, and I sit in on whatever meetings the engineering team already runs. By the end of the first two weeks I should be able to draw the system on a whiteboard from memory and tell you which parts will break first under three times the current load.
The risk register comes out of that audit. It is a written document, usually six to twelve items, sorted by likelihood of causing a serious problem in the next twelve months. Each item has a recommended action, an estimated cost, and a rough deadline. I rank them ruthlessly because you cannot fix everything, and the value of the document is that it tells you what to fix first.
The hiring plan is the third deliverable, and it is usually the one founders are most surprised by. Most early teams need fewer hires than they think and different hires than they planned. I will often recommend you delay your next two hires by a quarter and bring forward a role you had not been thinking about. That conversation is worth the entire engagement on its own, because hiring is the single most expensive decision an early company makes.
I refuse to ship code in month one. The reason is not pride, it is that the moment I start writing code I become accountable for the system in a way that contaminates my ability to give you honest architectural feedback. You did not hire me to be another engineer. You hired me to see the things your team has stopped seeing.
Pricing logic
Fractional CTOs price on retainer, not on hours, and the reason is incentive alignment. If I bill you by the hour, I am rewarded for slow weeks and meetings that run long. If I bill you a fixed retainer for a defined cadence of outputs, I am rewarded for finishing the audit faster and writing tighter scorecards.
The rate range in Europe in 2026 sits roughly between four and eight thousand euros a month for a senior fractional CTO with a real operating background, depending on the seniority required, the depth of the engagement, and the urgency. That is a lot less than the loaded cost of a full-time hire of the same seniority, and a lot more than a junior engineering manager. Both of those comparisons matter, because founders sometimes try to use a fractional CTO as a cheaper full-time hire, and that is also a recipe for a failed engagement.
The contract length that works is six months minimum, with a thirty-day exit clause on either side. Anything shorter is too short for the work to compound. Anything longer is a commitment neither side should make until trust is earned.
When a fractional CTO is wrong for you
There are three situations where you should not hire one, and I will say so on the intro call.
If you are pre-product, you do not need a fractional CTO. You need a technical co-founder, or you need a small contracting team that can ship the first version while you figure out whether the market exists. A fractional CTO at this stage will cost you opportunity and slow you down, because the work I do does not compound on a product that does not yet exist.
If you are post-Series-B, you almost certainly need a full-time CTO or VP of engineering. The decisions at that stage have to be made by someone who is in the room every day, owns headcount budgets that run into millions, and reports to your board on quarterly cadence. A four-hour-a-week voice cannot carry that weight, and pretending it can is a failure mode I have seen up close.
If you actually need a co-founder, you need a co-founder. A fractional engagement does not solve the equity, commitment, and identity gaps that a missing co-founder leaves. It will paper over them for six months, and then it will not.
How to tell the difference before you sign
A few questions to ask in the intro call, because they will tell you most of what you need to know.
What does the first thirty days look like in writing? If the answer is "we will see how it goes," you are buying hours, not outcomes.
What will you not do for me? A senior fractional CTO has strong opinions about scope. They will tell you what they are not going to be on the hook for, and a good answer here will sound surprisingly narrow.
How do you measure whether this engagement is working? The right answer is two or three concrete written outputs and a defined review point at thirty and ninety days, not a vibe.
What is your exit clause? Anyone who refuses a thirty-day exit is selling you a contract, not a partnership.
Where this fits
I take a small number of fractional CTO engagements at any one time, usually two or three concurrently, because beyond that the quality of attention drops. Most of my clients are climate, energy, or AI companies somewhere between pre-seed and Series A. The work I do at Pstryk, where we shipped Poland's leading dynamic electricity tariff and now run a fleet of several thousand IoT devices, is what makes me useful in those conversations rather than just credentialed for them.
If you have read this and recognized your own situation, the intro call is thirty minutes and the first thirty days are scoped before either of us commits to anything longer. The link is on the consulting page.