Most Fractional CTO job descriptions sound the same. “Technical leadership, strategic direction, engineering oversight.” Written that way it sounds like a vague management layer floating above the work. The reality of the first 90 days is much more concrete, and most of what matters happens before you’ve made a single big decision.
This is what a real Fractional CTO engagement looks like in the first ninety days. Week by week, with the order that actually works. Written from experience, not theory.
What a Fractional CTO actually is
A Fractional CTO is a senior technical leader who works with your company part-time, typically two days a week, usually on a three-month minimum engagement. The role is not an advisor. It is not a mentor. It is not a contract developer writing code in a silo.
The Fractional CTO owns the technical direction of the business while they are engaged. They make decisions, they hire, they write architecture documents, they talk to the board, they sit in on customer calls when it matters. They are also allowed and expected to get hands-on with code, review pull requests, and pair with the engineers on the team.
This role is usually the right fit when:
- You are a funded startup without a technical co-founder
- You are a scale-up with a product team but no senior enough technical voice to set strategy
- You are mid-pivot or mid-rebuild and need someone who has done it before
- Your existing team lead is strong technically but needs cover on board communication and strategy
It is not the right fit if what you actually need is a mentor (cheaper, hourly), a CTO-as-a-service (which is usually just advisory), or a senior engineer to write code. Those are different jobs with different price points.
Before day one: the setup
Good Fractional CTO engagements do preparation work before the engagement officially starts. This sounds boring but it is the single biggest determinant of whether the first month feels productive or chaotic.
The week before day one should cover:
- Scope locked in writing. Two days a week, Tuesday and Thursday, three-month minimum, with a named set of outcomes for the first 90 days.
- Tool access granted. GitHub or GitLab, AWS or GCP, Linear or Jira, your issue tracker, your monitoring dashboards, your design tool. Nothing kills the first two days like waiting for a Google Workspace invite to propagate.
- Board and investor awareness. A single email to the board saying “we have hired a Fractional CTO for a three-month engagement, here is who and why”. No surprises.
- A written “no big changes in week one” commitment. This one is important. The engagement starts with listening. Anyone who arrives day one with strong opinions about what needs changing has not done the job before.
Weeks 1–2: land and listen
The job in the first two weeks is to understand what you have inherited. Not to fix it. Not to judge it. To understand it.
Concretely, this means:
- A 1:1 with every engineer on the team. Thirty minutes each. What are they working on, what is frustrating, what would they change if they could, what do they want from me.
- A 1:1 with the CEO and each co-founder. What does good look like in six months. What is the worst-case scenario they are worried about. Who do they trust on the team and who do they not.
- Reading the codebase. Not a light skim. I usually spend a full day reading the main repository end to end, taking notes. Another day on whatever supporting services exist. This is where surprises live.
- Reading the last 60 days of pull requests. This tells you more about team culture than any 1:1 will. Who reviews, how detailed is the review, how fast are PRs merged, are commits clean.
- Reading every customer support ticket from the last 30 days. This is the most underrated activity. It tells you what is actually broken from the user’s point of view, not what the team thinks is broken.
- Sitting in on at least one customer call. If the company is B2B, ideally two. The vocabulary alone is worth the time.
What you do not do in weeks one and two: push for changes, reorganise the team, criticise the tech stack, promise the board anything. Not yet.
Weeks 3–4: write the audit
By the end of week two you have opinions. The job in weeks three and four is to write them down in a document the CEO, the board, and the team can all read.
The audit I write always has the same three sections:
State of engineering. What the codebase looks like, what the critical risks are, what the delivery cadence is, and what we are good at. Named risks, not vague worries. “The payment flow has no automated tests and has been the source of four of the last ten production incidents” is a risk. “Code quality needs improvement” is not.
State of product. What we are shipping, what we are not shipping that we should be, and the gap between what the team thinks the product is and what customers are actually using it for. This is where the customer tickets and calls from weeks one and two pay off.
State of team. Who is on the team, what they are good at, what gaps exist, who is at risk of leaving, and whether the team is the right shape for the next six months. This section goes to the CEO only, not to the wider team.
Each section ends with named recommendations. Not twenty. Five to eight across the whole document. Numbered, ordered by priority, with a rough effort estimate against each.
This document is how you earn trust. It is the visible deliverable that shows the CEO and the board that they have brought in someone who can see clearly and write clearly. Every Fractional CTO engagement I have done lives or dies by this document.
Weeks 5–8: the first big decision
By week five you stop writing and start doing. The shape of weeks five to eight depends on what the audit surfaced as the top priority. In my experience it is nearly always one of two things.
If the top priority is a hire
You write the role, agree the level and the salary band with the CEO, source candidates, and run the interview process yourself. The reason this is a Fractional CTO job and not an HR job is that the role definition is nearly always wrong when the company writes it. I have rewritten “we need a senior React Native developer” into “we need a mobile lead who can own our release process” more than once.
The first hire you make is the hire you will be judged on for the next year. Spend the time.
If the top priority is an architectural decision
You write your first ADR (architecture decision record). A proper one: context, decision, consequences, alternatives considered. Share it with the team, run one meeting to pressure-test it, ship it.
My actual first ADRs from real engagements have covered things like: migrating from a shared monolith to service boundaries, moving from a self-hosted Postgres to RDS, replacing Firebase Auth with Supabase, picking between RAG and fine-tuning for an AI feature. The topic varies. The format is always the same, and the decision gets documented in the repository where anyone new joining in month four can read it.
Either way: the team should feel the change
By week eight the team should be able to say “here is a specific thing that is now better because the Fractional CTO joined”. If they cannot, the engagement is off track.
Weeks 9–12: set the cadence
The final third of the first 90 days is about making your work survivable without you. Fractional means part-time. The team needs to function on the days of the week you are not there.
The things that usually need introducing or tightening in this window:
- A weekly delivery standup if there isn’t one, or a tightening of the existing one. Fifteen minutes, not thirty. What shipped last week, what ships this week, what is blocked.
- DORA-style delivery metrics, tracked somewhere visible. Deployment frequency, lead time for changes, change failure rate, mean time to recovery. These are boring and they work. They give the CEO a real answer to “how is engineering doing?” without asking me.
- A monthly retrospective cadence, run by the team lead not by me. I attend the first one and step back.
- A monthly board update template. One page. Shipped, shipping, team changes, technical risks, hiring. Repeatable, so it survives after the engagement ends.
- A fortnightly 1:1 cadence between the CEO and me, to replace the daily back-and-forth of the first month.
By the end of week twelve, the engagement has a natural decision point. Either it continues (most do, usually at the same cadence) or it ends cleanly with the team able to carry on.
What changes after the first 90 days
Assuming the engagement continues, the shape of the work shifts. The first 90 days is about landing, diagnosing, and building trust. The next phase is about compounding. This usually looks like:
- Ongoing hiring, with a pipeline you maintain rather than rebuild
- Regular architecture reviews at a cadence (monthly is usually right)
- Mentoring the team lead or senior engineers towards taking over your role
- Staying available for unexpected moments, the RFP, the incident, the acquisition conversation
The Fractional CTO engagement that ends well is one where the company no longer needs the Fractional CTO. The good ones plan for this from day one.
Red flags in a Fractional CTO candidate
If you are hiring a Fractional CTO and trying to work out whether the person across the table is the right one, here are four things I would check:
Recent hands-on experience. A Fractional CTO who has not written code in three years cannot audit your codebase. Ask when they last shipped something themselves. If the answer is years ago, they are an advisor not a Fractional CTO. Different role, different price point.
Specific past engagements they can name. Not “worked with various startups”. Named companies, named outcomes, named durations. If the engagement history is vague, the quality is also likely vague.
A first-90-days answer they can give off the top of their head. If you ask “what would your first 90 days look like?” and they need to think about it, that answer is being made up on the spot. Anyone who has done this multiple times has a framework.
A willingness to walk away. The right Fractional CTO should be willing to say “I don’t think I am the right person for this” on the first call if the fit is wrong. If they are selling hard from the first email, be cautious.
What this engagement costs at Walsh London
For reference: our Fractional CTO engagement starts at £5,000 per month for two days a week, with a three-month minimum. Larger scopes (three or more days per week, deeper hands-on involvement) are quoted on discussion.
Most engagements extend beyond three months. The three-month minimum exists because meaningful work takes at least that long, and engagements that end at three months usually do so because the fit is genuinely wrong, which is fine. The engagement follows roughly the structure above.
All prices shown are exclusive of VAT where applicable.
The short version
A Fractional CTO in the first 90 days should, in order:
- Listen, read, and understand before changing anything (weeks 1–2)
- Write a clear audit with named risks and named recommendations (weeks 3–4)
- Make one substantive decision or hire and ship it (weeks 5–8)
- Set a repeatable cadence so the work survives without them (weeks 9–12)
If that is not roughly the shape of the engagement you have in front of you, you are looking at something else. Possibly cheaper, possibly more expensive, but not a Fractional CTO.
