The First 90 Days: What a Fractional CTO Actually Does

Before day one: the brief

The 90-day period actually starts before the engagement formally begins. The most important thing a fractional CTO should do before their first day is understand the brief well enough to know what success looks like. That means a proper conversation with the founding team or CEO about:

What's prompting this now? (The specific trigger matters.)
What does the engineering team know about this engagement?
What does the board know? What are their technology concerns?
What's the company's biggest technology risk in the next 12 months?
What does a great first 30 days look like from your perspective?

This conversation also sets the operating norms: which meetings they attend, how they communicate with the team, how decisions get escalated, and what "part-time" actually means in practice (a calendar block, not a vague agreement).

Days 1–30: Listen before you act

The most common mistake a new fractional CTO makes is coming in too fast. They've been hired because they have strong views about technology and leadership. They see problems within the first week. The instinct is to start fixing them immediately, and this is almost always the wrong instinct.

The first month is for understanding, not changing. Here's what that looks like in practice:

Meet everyone who matters

1:1s with every engineer, product manager, and relevant stakeholder in the first two to three weeks. Not to evaluate, to listen. "Tell me about the biggest frustration you have with how we build things" will surface more useful information than any architecture review.

Pay particular attention to the most senior engineers in the team. They know where the bodies are buried. They also know whether this engagement is going to work, their buy-in matters enormously.

Review the codebase and infrastructure

Not to rewrite it, but to understand it. What are the key services? Where is the coupling that will bite you when you scale? What does the deployment pipeline look like? Where is the security posture weakest? This review is diagnostic, not prescriptive, the recommendations come later.

Map the technical debt

Every codebase has technical debt. The question is whether it's being managed deliberately or accumulated accidentally. A one-month debt map should categorise debt by: risk (could this cause an outage?), velocity impact (is this slowing down delivery?), and cost to fix (is this a weekend or a six-month project?).

Understand the product roadmap

The technology strategy has to serve the product and business strategy. Before you can have a view on where the architecture needs to go, you need to understand where the product is going. What are the next three major product bets? What will those require technically that you can't deliver today?

What you should produce by end of month one

A technology audit: an honest, written assessment of where the engineering function is today. Covering: team structure and capability, codebase health, infrastructure and security posture, process maturity, and the top five technology risks. This document becomes the shared truth for every conversation that follows.

A note on quick wins: If you spot something obviously broken in week one (a security misconfiguration, an on-call rotation that's burning out the team, a process that's creating unnecessary overhead) fix it. Small, visible improvements build trust quickly. The point is to avoid strategic moves before you have enough context. Tactical fixes are fine.

Days 31–60: Build the roadmap and earn authority

Month two is where the diagnostic work translates into direction. You have enough context now to have informed opinions. The job shifts from listening to proposing, and navigating the inevitable pushback.

Present the technology audit

Share the month-one audit with the leadership team and board. This is the fractional CTO's first major moment of credibility, or the first sign that they don't have a grip on the situation. Present it clearly: what's working, what isn't, what the risks are, and what you're recommending.

Be honest. CEOs and boards have generally seen enough sanitised reports. An audit that only tells good news isn't useful. The point is to create a shared and accurate picture of the technical reality, even if parts of that picture are uncomfortable.

Build the technology roadmap

Not a five-year technology vision. A 12-month roadmap that answers: what are we going to fix, what are we going to build, and in what order? This roadmap should be tied explicitly to the product and business roadmap, not a wish list of engineering improvements divorced from customer value.

It should also include a technical debt reduction programme. The single biggest mistake engineering teams make is treating debt reduction as something they'll do "when things calm down." Things never calm down. Debt needs to be budgeted (typically 20–30% of sprint capacity) as part of the regular rhythm.

Assess the team

By month two, you have enough data to have a clear view of the team's strengths and gaps. Who are the engineers who have the potential to be leads? Where are the capability gaps that will constrain delivery in the next six months? Are there any people problems that need to be addressed, performance conversations, misaligned incentives, or cultural issues that the team has been tiptoeing around?

Start hiring (if needed)

If the audit identified capability gaps that need external hiring, month two is when the hiring process starts. A fractional CTO should own the technical hiring process, defining the role, writing the job description, building the interview process, and leading the final technical assessment. This is one of the highest-leverage things they do.

Days 61–90: Deliver and establish rhythm

Month three is about shifting from "new person" to "established leader." By this point, the team should have a clear sense of the CTO's operating style, values, and priorities. The leadership team should have confidence in the technology direction. The roadmap should be in motion.

First roadmap deliverables

Some item from the technology roadmap should be visibly in flight or complete by the end of month three. This doesn't need to be a major architectural overhaul, it might be a significantly improved deployment pipeline, a security improvement that was flagged as a risk, or the first hire from the new engineering hiring process. Visible progress validates the roadmap and builds confidence.

Establish the operating cadence

A fractional CTO works best when the engagement has a clear weekly rhythm. Typically: a weekly team standup or leadership touchpoint, a fortnightly 1:1 with the CEO, monthly board or leadership team reporting on technology, and a quarterly OKR review aligned with the product roadmap. Once this cadence is established, the part-time nature of the engagement becomes far less of a constraint, because everyone knows when the CTO touchpoints are and can plan around them.

Build the team's independence

One of the most important (and often overlooked) goals of a fractional CTO is to increase the engineering team's ability to operate well in their absence. This means clear architectural principles documented, well-designed processes that don't require a CTO to adjudicate every decision, senior engineers who have been given genuine ownership and authority, and a culture of clear communication about blockers.

A fractional CTO who creates dependency isn't doing their job. The best ones leave every room smarter than they found it.

What success looks like at 90 days

By the end of the first three months, a successful fractional CTO engagement should have produced:

A clear, shared technology audit and roadmap, no surprises lurking in the codebase that only one person knows about.
An engineering team that is clearer about priorities, more energised, and less reactive.
The first visible outputs of the technology strategy, whether that's a hire, a technical improvement, or a process change.
A board and leadership team with genuine confidence in the technology function.
A clear picture of what the next 12 months look like, and what milestones will indicate that the engagement has achieved its purpose.

The first 90 days are foundational. Companies that treat the fractional CTO engagement as "someone to answer questions and attend the odd meeting" will rarely see these outcomes. Companies that genuinely integrate them into the leadership team (giving them authority, inclusion in key decisions, and honest access to the team) almost always do.