What "fractional" looks like, week to week
What you're actually buying: the cadence, the access, and where a fractional CTO's judgment gets used versus where it doesn't.
"Fractional CTO" describes an arrangement, not a job description, and the arrangement varies enough between practices that it's worth being specific about what it actually looks like on a normal week, rather than leaving it as an abstract title.
What's fixed
- A standing cadence. A regular sync — usually weekly — that isn't a status meeting. It's where architecture decisions, hiring calls, and roadmap tradeoffs that are hard to make alone actually get made, with someone in the room whose job is exactly that.
- Direct access, not a queue. The team can reach out between syncs for the decisions that can't wait a week — a production incident, a vendor contract that needs a technical read, an offer that needs a second opinion before it goes out.
- Written output. Architecture decisions and their reasoning get written down, not just discussed — so the decision survives past the meeting it was made in, and a new hire six months later can read why, not just what.
What flexes with the engagement
How much of the week is spent in the room with your team versus heads-down on something specific — a migration plan, a security review, an architecture doc — depends on where you actually are. Early-stage and the CTO's time skews toward hands-on building and getting the first real architecture decisions right. Post-seed with a growing team, it skews toward hiring, roadmap, and the org-design questions that come with headcount. Neither mode is "more fractional" than the other — it's the same relationship, pointed at whatever's actually the constraint that quarter.
What you're not buying
A fractional CTO isn't a part-time individual contributor who happens to have a senior title, and it isn't an advisor who shows up once a month with slides. The former undersells the judgment you're actually paying for; the latter doesn't have enough contact with the day-to-day reality of the codebase and the team to be useful when a real decision needs making. The useful middle is regular enough contact to have context, and senior enough judgment that the time spent is disproportionate to the hours billed.
How it usually starts
Most engagements start with an assessment period — real architecture and org review, not a sales pitch dressed up as one — before settling into the regular cadence. That's on purpose: the right cadence and focus for the engagement should come out of what's actually true about your systems and team, not out of a standard package.