Fractional CTO: What the First 90 Days Look Like

A fractional CTO is not a contractor hired to complete a defined spec, and it is not a full time employee. It is a part time executive relationship where someone with senior technical leadership experience works across your team for a fraction of a full time schedule.

The distinction matters operationally. A contractor delivers against a brief someone else wrote. A fractional CTO writes the brief, challenges assumptions, makes architecture decisions, and then oversees delivery. The accountability is different. The relationship with the CEO and founding team is different. The exit condition is different.

Typical time commitment runs 8 to 20 hours per week depending on company stage and what the engagement is designed to solve. Pre-product or very early stage companies usually need 15 to 20 hours per week because the fractional CTO is doing original architecture work alongside the team. Scaling stage companies with an existing engineering team often need 8 to 12 hours per week because the fractional CTO is providing direction and oversight rather than hands on delivery.

Communication is typically structured around two standing meetings per week — a shorter sync with the CEO or founder, and a longer engineering team session — plus async availability on Slack or equivalent. Decisions are made jointly and recorded in a shared decision log. You are not waiting for monthly reports; the fractional CTO is embedded enough to surface blockers in real time.

A fractional CTO who starts making changes in week one — restructuring the team, rewriting the architecture, canceling vendor contracts — is working from assumptions rather than evidence. Good practitioners spend the first 30 days observing, interviewing, and auditing. The exception is a genuine crisis: a production outage, a critical security vulnerability, or a hard regulatory deadline. Those require immediate action. Everything else waits.

By the end of day 30 you should have received: an architecture assessment document (8 to 15 pages), a risk register with severity rankings, a draft 90-day roadmap for the fractional CTO's own work, and a debrief with the founding team.

If the assessment and debrief have not happened by the end of week three, something is wrong. Common causes: the fractional CTO has not been given proper access, key stakeholders are too busy for interviews, or the engagement is under resourced on hours. All three are solvable, but they need to be named and fixed early.

Every scaling startup has a backlog of deferred technical decisions. Build versus buy on a critical capability. Whether to migrate from a monolith to services and what the path looks like. Which authentication or payment vendor to standardize on. Whether the current team has the right composition to deliver the roadmap. The fractional CTO's job in month two is to make these decisions, explain the reasoning, and get alignment from the founding team before executing.

Technical strategy decisions come first. Based on the architecture assessment, the fractional CTO works with the team to prioritize the roadmap: what gets addressed first and why. Not everything in the risk register is a current-quarter problem. The strategy work separates what is genuinely urgent from what can be safely deferred.

These are the decisions the team has been circling. The fractional CTO drives each one to a documented conclusion: a recommendation, the reasoning behind it, the alternatives considered, and the decision log entry. This prevents revisiting the same decisions in three months.

If the team has capability gaps — a missing senior engineer, an absent security function, an under resourced QA practice — the fractional CTO writes a specific hiring brief: role definition, seniority level, what the ideal candidate looks like, and a recommended hiring timeline. This is not a wish list; it is scoped to what the company can afford and execute in the next 90 days.

Month two is also where the operating model starts to form. Sprint cadence, definition of done, code review standards, incident response process, and on call rotation (if the company does not already have one). These do not need to be perfect in month two; they need to exist.

Deliverables at the end of day 60: a technical strategy document with a prioritized roadmap and rationale, an engineering hiring brief (if applicable), a decision log with three to five major decisions documented, and a draft operating model for the engineering team.

This is the phase that separates fractional CTOs who can advise from fractional CTOs who can lead. The output of month one and month two is documentation. The output of month three is shipped work.

By day 60, the team should be running sprints (or equivalent planning cycles) that the fractional CTO has helped design. In month three, those sprints produce results: features shipped, technical debt items addressed, infrastructure improvements in production.

If the team had no formal code review culture, month three is where it takes hold. The fractional CTO models the behavior directly — reviewing code, leaving specific and constructive comments, setting the bar for what makes it to production.

Where the team has identifiable gaps — nobody has experience with the new framework, the team has never written production tests, nobody has architected a distributed system before — the fractional CTO works on those gaps through direct pairing, targeted feedback, and deliberate skill transfer. This is one of the highest-value outputs of the whole engagement and one of the most commonly skipped.

At the end of day 90, you have a documented retrospective: what changed, what did not, and what still needs to happen. This also sets the context for the continuation decision — whether to extend the engagement, transition to a lighter advisory model, start a full time CTO search, or exit with a capable team running independently.

Deliverables at the end of day 90: at least one shipped improvement directly attributable to the engagement, a documented engineering operating model, a retrospective and continuation recommendation, and a candidate shortlist or search process underway (if a CTO hire is planned).

On day one, the architecture lives in people's heads. On day 90, it exists in a written document that a new engineer can read and understand. The same is true for the risk register, the operating model, and the key technical decisions. Documentation is not the end goal — but it is evidence that the fractional CTO transferred knowledge rather than just made decisions in private.

Not a wish list of everything the team wants to build — a prioritized, scoped, sequenced technical roadmap with specific engineers or roles responsible for each item and a realistic timeline. If you cannot point to this document at day 90 and say "we are working from this," the strategy phase did not land.

Month three must produce something in production. It does not have to be the biggest item on the roadmap. It has to be real, shipped, and attributable to the fractional CTO engagement. If nothing shipped in 90 days, the engagement produced only documents.

The best sign that a fractional CTO engagement went well: by day 90, the team is making good technical decisions independently. The fractional CTO transferred judgment, not just deliverables. If every decision still flows through the fractional CTO at the end of the engagement, the engagement created dependency rather than capability.

For most seed to Series A companies evaluating a fractional CTO for the first time, the part time fractional format is the right starting point. Start at 8 hours per week, run the 90-day engagement, and adjust the hours at the 90-day mark based on what the company actually needs.