Someone asked me recently at what point the fractional CTO model becomes constrained by delivery capacity. Every new client brings another roadmap, another implementation, another stream of engineering work. At some point, one person can’t carry all of it.

It’s a reasonable question, and it tells me something about how most people picture the role. They’re imagining a CTO who does the work. The model breaks when you think about it that way. It’s supposed to.

The question assumes the CTO is the bottleneck

Many “fractional CTOs” work exactly this way. They write code, design systems, review every pull request, own the deployment pipeline. Senior contractors with a leadership title. The work is often excellent, but it’s not CTO work.

The distinction matters because it changes what the founder is buying. Delivery capacity scales linearly with hours and hits a ceiling fast. Decision quality compounds. When you hire for delivery, the output stops when the person stops. When you hire for decisions, you get a company that can deliver without the CTO present.

Vadim Kravcenko wrote one of the clearest breakdowns of this shift. At a 10-person company, the CTO might spend 80% of their time writing code. At 100 people, near zero. At 1,000: 70% information intake, 20% synthesis, 10% storytelling to the board. The code disappears. The decisions stay. If a fractional CTO is still personally producing the technical output at a 50-person company, they’re doing the job they had at 10 people and calling it leadership.

If what you need is 30 hours a week of hands-on architecture and delivery, hire a senior contract engineer. Different role, lower cost, and no pretence about it being CTO work.

What a fractional week actually looks like

The image most people have is a CTO splitting 40 hours of coding across four clients. Ten hours each, four roadmaps, four standups, four Slacks. That’s wrong.

A typical engagement runs 10 to 15 hours per month per client. Most practitioners settle on 2 to 4 clients, with 3 as the sweet spot. The time goes toward decisions that shape what the team builds and whether the technical direction supports where the business is heading.

In practice, a week looks more like this. Monday morning is board-prep for one client, testing the technology narrative against commercial metrics and working out what question the lead investor is likely to ask. Monday afternoon is a hiring calibration for a second client, pressure-testing whether the role the founder described is the role they actually need filled. Tuesday is an architecture decision review for a third client, where the engineering team has already produced a recommendation and the CTO’s job is to validate the reasoning, spot untested assumptions, and sign off or send it back.

None of that is delivery. All of it shapes what gets delivered.

Kravcenko has a line I keep coming back to: “You’re building a machine that builds the product.” The fractional version means building that machine for more than one company. That’s only constrained by delivery hours if you’re confusing yourself with the machine.

The real constraint is context depth, not hours

The honest limit is not delivery throughput. It’s context depth per client. There is a finite amount of trust and institutional knowledge one person can carry across multiple companies, and that’s the constraint worth naming.

A CTO spread across six clients can’t hold enough context to make the specific, uncomfortable, correct call. They default to generic best practices. Right in the abstract, wrong for the business. That’s the failure mode, and it’s why good fractional CTOs limit their client count rather than expanding it.

This is also why the “not enough time” criticism misses. A full-time CTO who spends five days a week in code review has the same problem. Present, but not leading. All the hours and none of the influence. The constraint was never the calendar. It was whether the person in the role is doing work that only they can do, or doing work that a senior engineer should be doing while the CTO-shaped decisions pile up unaddressed.

The test is simple. If the company would stall tomorrow because the CTO stopped showing up, the CTO has been doing the wrong work. A CTO who has made themselves a single point of failure hasn’t built leadership. They’ve built a liability.

I work with 2 to 3 companies at a time because the context constraint is real, and I’d rather do the job properly for fewer clients than spread thin across more. If this argument matches how you think about leadership, book a conversation.

Most funded startups don’t need 40 hours of CTO time per week. They need the right 5 decisions per month and a team that can execute them. If the implementation isn’t flowing through the team, that’s the first decision to address.

Share: