What a fractional CTO actually does all week

You have heard the term in three conversations this month. A founder friend hired one and swears by it. An investor asked, in that careful way investors ask, who owns technology decisions now that you are past 20 people. And you have a nagging sense that something is slipping: deploys that used to take an hour now take a day, a security questionnaire sat unanswered for two weeks, and nobody can say with confidence who has access to the production database.

So you start looking into a fractional CTO. The first thing you find is that the title means six different jobs depending on who is selling it. One person writes architecture documents and disappears. Another joins your stand-ups and reviews pull requests. A third never touches code, sitting in board meetings translating engineering risk into language your investors understand.

That spread is the real problem. You cannot decide whether you need a fractional CTO until you know what the good ones do with a week. So here is the week, hour by category, with the parts that matter and the parts that are theater.

The early week is where a fractional CTO earns the title, and it looks less dramatic than you would expect. It is mostly decisions that were stuck.

A real one spends the front of the week:

• Unblocking choices the team has been circling for a month, like whether to stay on a single cloud account or split workloads, and writing the reasoning down so it does not get relitigated in three weeks.
• Reading what is already running. Not a strategy deck about the future stack, the actual one: what is in Microsoft 365, what identity controls are on, whether Conditional Access exists or is a checkbox someone meant to revisit.
• Sitting with the engineers who carry the most context and finding out what they are quietly working around. The thing nobody put in a ticket is usually the thing that matters.

Notice what is missing. There is no 40-page technology roadmap nobody will read. An operator makes calls and records them. A consultant produces artifacts. The difference shows up by Wednesday, when the team is either moving or still waiting for the document.

Wednesday and Thursday are where the unglamorous prevention happens, and it is the part founders most often skip because it never announces itself.

This is access reviews: who can reach what, and whether the contractor who left in March still has a key. It is turning on the threat detection you are already paying for, like GuardDuty in AWS, then reading the findings before they pile up in a console nobody opens. It is making sure the policies your next buyer will ask for exist as living documents, kept current, findable, and ready before the audit lands.

Most of what a fractional CTO prevents, you will never see, because the page that did not go off at 3 a.m. does not send a thank-you note.

That is the honest trade. The work that protects your company is quiet, and quiet work is hard to value until the week it is missing. A founder who wants a feature list will be disappointed. A founder who wants to stop lying awake about access and audits is buying the right thing.

The end of the week points back at you. A fractional CTO who only talks to engineers is half-useful. The other half is sitting across from a non-technical founder and a board and saying, in plain terms, here is the risk we carry, here is what we are spending attention on, and here is what we are deliberately not doing yet.

That last part matters more than it sounds. Saying what you are skipping (the enterprise tooling you do not need at 30 people, the compliance work that can wait two quarters) is itself a decision, and a good one names it out loud so it is a choice, not an accident of neglect. Founders do not want a longer list of capabilities. They want to know the floor is solid and someone competent is watching it.

Walk back to the slipping you felt at the start: the slow deploys, the unanswered questionnaire, the database access nobody could account for. None of those is a tool problem. Each is a decision that nobody with enough context and authority has owned. That is the gap a fractional CTO fills, and it is also the test for whether you need the title at all.

If your problems are work the team knows how to do but keeps deprioritizing, you may need an operator running it, not a part-time executive thinking about it. The line between those two is worth getting right before you hire either. So the question to sit with is this: is technology decision-making truly stuck, or is it simply unowned?