The First 90 Days as a Fractional CTO
The 90-day plan looks clean on paper. Discovery, diagnosis, roadmap. In practice, you're three weeks in and the client is asking you to ship a feature. Here's what actually happens — and the line you need to hold.
The 90-day plan looks clean on paper. Weeks one through four: discovery. Weeks five through eight: diagnosis. Weeks nine through twelve: roadmap and early wins. Michael Watkins wrote the book on it — literally — but he wrote it for permanent hires stepping into established roles. Fractional is a different animal. The structure is useful. It’s also fiction — or at least, it will be by week three.
I’ve done two fractional CTO engagements so far. Not twenty. Not fifty. Two. That’s a small sample — but small samples teach you the lessons that matter most, because you remember every detail. The biggest lesson had nothing to do with technology, architecture, or process. It was about what the client actually expected me to do versus what I was there to do.
The supply chain strategist
Think of a supply chain strategist. Their job is to map the network — which routes, which hubs, which contingencies, where the fragility lives. They see the whole system: the bottlenecks that individual drivers can’t see from inside their lorries, the single points of failure that only become visible from above. Hiring a supply chain strategist to drive deliveries is a misallocation of what they’re trained to see. The deliveries still need to happen — they require skilled operators. But only the strategist can see the patterns that determine whether the network succeeds or fails.
The strategist doesn’t drive lorries. But they need to have driven them — because understanding execution constraints shapes what’s strategically possible. That’s the fractional CTO role. You’re hired to see the whole network. The moment you start driving lorries again, you lose the vantage point that makes you valuable.
The textbook plan
The structure is well-established and it works — as a compass, not a railway.
Weeks 1–4: Discovery. Listen more than you speak. Map the landscape: the technology, the team, the processes, the culture. Adam Horner, a fractional CTO with over thirty years in the industry, frames this around three pillars — aligned strategies, empowered people, optimised processes. That’s a useful lens. Sit in on standups. Read the architecture. Review the hiring pipeline. Have 1:1s with every engineer and every stakeholder who’ll give you the time. You’re building a mental model of the organisation — not just how it works, but how it thinks it works, and where the gap between those two things lives.
Weeks 5–8: Diagnosis. Separate the symptoms from the root causes. Slow delivery might look like a tooling problem, but it’s often a team structure problem. Technical debt might look like an engineering problem, but it’s often a prioritisation problem — which means it’s a leadership problem. Ned Lowe, CTO and co-founder of MISSION+, calls this the discipline of being “uncomfortably simple” — stripping away functional and technical complication until what remains is the actual problem, not the symptoms the team has built around it. Architecture reviews, team topology analysis, process audits, hiring gap assessments — this is where your outside perspective earns its keep. You see patterns the team can’t see because they’re inside them.
Weeks 9–12: Roadmap. Strategy, vision, concrete deliverables. A prioritised roadmap the client can act on. Early wins that demonstrate momentum — not to prove your value, but to give the team confidence that the diagnosis was right and the direction is sound. Culture interventions if needed. Change management if the org isn’t structured for what the roadmap demands.
This structure maps to industry-standard fractional executive frameworks — Matt Blumberg’s Startup CXO covers similar phases, and it’s reflected in how firms like Umbrex structure advisory engagements. The phases aren’t original. The execution is where every engagement diverges.
That’s the plan. It’s a good plan. Here’s what actually happens.
What actually happens
The execution expectations arrive early, and they arrive quietly.
Nobody says “we expected you to write code.” They say “could you just look at this pull request?” and “could you pair with the team on this feature?” and “we’d love your hands on the migration.” Each request is reasonable in isolation. Taken together, they’re a gravitational pull toward execution — and if you don’t name it, you’ll wake up in week six wondering why you haven’t started the architecture review because you’ve been buried in implementation details.
This is what happened in my first engagement — a B2B SaaS company with a small engineering team and more ambition than bandwidth. The boundary blurred — not because the client was unreasonable, but because the line between advisory and execution isn’t obvious when you’re a technical person sitting next to a team that needs help. The instinct to roll up your sleeves is strong. It feels productive. It feels like you’re earning your fee. And the client is happy — in the short term — because things are getting built.
But the roadmap isn’t getting built. The diagnosis isn’t happening. The strategic work that only you can do is being displaced by tactical work. You stop seeing the system and become embedded in it. You’re driving the lorry instead of mapping the route.
The moment I recognised it, I raised it. That conversation — “this is what’s happening, here’s what it’s costing us, here’s what I need to refocus on” — was uncomfortable. There was a pause. The client needed to recalibrate what they thought they’d hired. But they got it, and the expectations realigned. Not every client will. That’s a risk you accept when you hold the line.
The rule I took from it is simple: the moment you see the boundary shifting, name it. Don’t wait for it to become a problem. Don’t assume it’ll self-correct. Silence, in a consulting relationship, is consent.
That said, not every moment of execution is drift. A security incident, a critical outage, a major architectural decision that requires getting hands-on with the codebase — these aren’t failures of the boundary, they’re part of being a senior technologist. The difference is intentionality: strategic execution you choose because the diagnosis requires it is different from accidental execution that creeps up because you never named the boundary. One is leverage; the other is distraction.
Advisory versus execution
The distinction matters — for the client as much as for you.
The fractional CTO’s value lives in the work that requires an outside perspective — assessing the architecture, evaluating the team structure, designing the hiring framework, setting the technical vision, introducing change management, challenging assumptions the team is too close to question. These interventions need pattern recognition from working across multiple organisations and the seniority to make the calls that shape how the whole system works.
There’s a middle tier worth naming: architectural code review, mentoring on critical decisions, pairing on high-judgment technical trade-offs. This work requires your seniority — but it’s collaborative, not owned. You do it when it informs the strategic direction, not as a standing commitment.
Then there’s the day-to-day: writing features, running sprints, triaging bugs. Important work. But it doesn’t leverage what a fractional CTO is actually for. When you spend your time there, you’re not adding something the team couldn’t do without you — you’re just doing it at a higher rate.
Dan Gwalter, who has run a fractional consulting business for over a decade, advocates fixed monthly retainers with agreed deliverables over hourly billing — precisely because the retainer model forces both sides to define the scope upfront. What are you delivering? What are you not delivering? When the answers are explicit, drift has nowhere to hide.
In my second engagement, I scoped this from day one. The engagement model was explicit: advisory, not execution. Execution support requires more time, commands a different rate, and — more importantly — is not my primary value. The clarity changed everything. No drift. No uncomfortable course-correction conversation. The client knew what they were getting, and I could focus on the work that actually moves the needle.
I should be honest about the trade-off. Holding the advisory line can cost you the engagement. Some clients want hands on keyboards, and when you explain that’s not the service, they’ll find someone who will. That’s a commercial reality every fractional operator has to sit with. But the alternative — becoming an expensive contractor — is worse. You lose the strategic vantage point, the client doesn’t get what they actually need, and you’ve commoditised the one thing that makes you worth the rate.
The compass, not the railway
The 90-day plan is real. Use it. But hold it loosely.
Discovery will bleed into diagnosis before you’re ready — because you’ll uncover something urgent in week two that can’t wait until week five. The roadmap will start forming during discovery — because some problems are obvious enough to act on immediately. And the client’s needs will shift as they learn what a fractional CTO actually does, which may be different from what they imagined when they signed the contract.
Set the expectation early: the structure is a compass, not a railway. The phases will overlap. The timeline will flex. What won’t flex is the focus — you’re there to see the whole network, not to drive the deliveries. When the boundary gets tested — and it will — name it early, name it clearly, and redirect.
My first two engagements taught me that. I suspect the lesson scales.