What a Fractional CTO Actually Does

The expectation problem

Every failed fractional CTO engagement I’ve seen follows the same pattern: mismatched expectations that were never documented.

The founder expected daily hands-on coding. The fractional CTO provided weekly strategic direction. Neither was wrong - they just never agreed on what the engagement included.

Here’s the scope I use with my clients. You can use it to evaluate any fractional CTO - including me.

What a fractional CTO does

1. Technical direction

This is the primary value. A fractional CTO sets the technical strategy: what architecture to use, what technologies to adopt, what to build vs buy, how to structure the engineering org.

What this looks like: Architecture decisions, technology stack choices, build-vs-buy analysis, technical roadmap, sprint planning input, quarterly technical reviews.

Time allocation: ~40% of engagement hours.

2. Engineering process

Establishing and improving how the team works: development workflows, code review standards, deployment processes, testing practices, incident response.

What this looks like: CI/CD pipeline design, code review standards, deployment strategy, testing framework selection, incident response process, technical documentation standards.

Time allocation: ~25% of engagement hours.

3. Team mentorship

Developing the existing team’s capabilities. A fractional CTO isn’t there forever, so the team needs to grow into the role.

What this looks like: One-on-ones with team leads, code review (selective), architecture review sessions, technical mentoring, pair programming (selective), career development input.

Time allocation: ~20% of engagement hours.

4. Stakeholder communication

Translating between technical and non-technical stakeholders: reporting to the board, communicating with investors, aligning engineering priorities with business goals.

What this looks like: Board updates, investor technical DD support, cross-functional alignment meetings, risk communication, roadmap presentations.

Time allocation: ~15% of engagement hours.

What a fractional CTO doesn’t do

1. Write production code full-time

This is the most common expectation mismatch. A fractional CTO writes code selectively - critical path items, proof-of-concepts, emergency fixes. But they’re not a full-time contributor.

Why: If they’re writing code full-time, they’re not doing the strategic work you’re paying them for. Hire a senior engineer for coding. Hire a fractional CTO for direction.

2. Manage day-to-day sprint execution

They don’t attend every standup, assign every ticket, or run every retrospective. They set the process and ensure it’s followed, but day-to-day execution belongs to the team lead.

Why: Sprint management is a full-time role for a tech lead or engineering manager. Fractional CTO oversight, not operations.

3. Be on call 24/7

They’re available for escalation and major incidents, but they’re not the first responder. The team handles operations. The fractional CTO handles the post-mortem.

Why: 24/7 availability requires a full-time commitment. The fractional model works because it’s focused and scheduled.

4. Hire and fire

They may interview candidates and provide input, but hiring decisions belong to the founder. A fractional CTO doesn’t manage HR processes.

Why: Employment decisions require daily presence and organizational context that fractional doesn’t provide.

5. Make everything better immediately

Fractional CTOs solve systemic problems over time. If you need a firefighter to fix an immediate crisis, hire one - but understand it’s a separate engagement from strategic technical leadership.

Why: Systemic change takes 3-6 months. Anyone who promises immediate transformation is selling something else.

The scope trap

The single biggest reason fractional CTO engagements fail: scope was never documented.

Here’s a one-page scope agreement I use. Fill this out before signing anything:

Engagement scope:

• Weekly hours committed:
• Response time for urgent issues:
• Key deliverables by month 1, 3, 6:
• What’s explicitly NOT included:

Success criteria:

• By month 3, we’ll have:
• By month 6, we’ll have:
• We’ll measure by:

Handover plan:

• By month [X], the team will be able to:
• Documentation will include:
• Post-engagement support will be:

If the fractional CTO won’t fill this out, they’re not planning to deliver. They’re planning to collect.

The two most common failure patterns

Pattern 1: The ghost

The fractional CTO shows up for the weekly call, gives good advice, and disappears. No documentation. No follow-through. The team gets direction but no momentum.

Fix: Require deliverables, not just meetings. Every week should produce something tangible: a decision, a document, a code review, a spec.

Pattern 2: The scope creeper

The engagement was supposed to be 10 hours/week. It’s now 25. The founder keeps asking for more. The fractional CTO keeps saying yes. Neither is happy.

Fix: Document scope upfront. If scope changes, amend the agreement. Don’t let good intentions create bad engagements.

FAQ

Can a fractional CTO be a temporary emergency CTO? Different role. An emergency CTO is full-time, hands-on, on-call. A fractional CTO is strategic, scheduled, and limited. If you need emergency coverage, hire for that specifically.

How long should a fractional CTO engagement last? 3-12 months typically. Less than 3 months isn’t enough to make systemic changes. More than 12 months means the team hasn’t developed the capability to operate independently, or the engagement should transition to full-time.

What if I need more hours than we agreed? Discuss it. Sometimes the workload justifies more hours, sometimes the scope needs to be reduced. The key is having the conversation explicitly rather than letting scope creep build resentment.