When a company brings in a Fractional CTO, they're usually in one of a few situations: a technical co-founder who has hit their ceiling, a non-technical CEO trying to manage an engineering team, or a growth-stage company that needs strategic technology direction without a full-time commitment.
In all of these situations, the same question applies: how do you create real value, quickly, without blowing up what's already working?
The first 90 days set the tone for everything. Do it right and you become the technology partner the company didn't know it needed. Do it wrong and you become an expensive external voice that nobody listens to.
Here's exactly how I approach it.
The most important thing about the first 90 days
Your job in the first 90 days is not to fix everything. It's to build trust, establish shared language, identify the highest-leverage problems, and demonstrate enough value that the right decisions get made with your input — not despite it.
The Four Phases
Before you change anything, you need to understand everything. This phase is pure information gathering — no recommendations, no judgements, no changes.
- →1:1s with every engineer and the founding/leadership team
- →Full inventory of the technology stack and running systems
- →Review the last 6 months of git history
- →Map the dependency graph and critical paths
- →Review incident logs, support tickets, and deployment records
- →Understand the business model, revenue drivers, and growth targets
With the map in hand, you can now make an honest assessment of technical health and build a prioritised action plan.
- →Technical debt inventory with estimated cost and risk
- →Security posture assessment
- →Team capability and capacity assessment
- →Architecture review against growth requirements
- →Vendor and tooling audit
- →Draft 90-day roadmap with prioritised initiatives
Execute the two or three highest-value, lowest-risk improvements. These prove that the engagement is delivering tangible results.
- →Implement the one security control with the highest immediate impact
- →Unblock the engineering bottleneck that's slowing the most developers
- →Establish a lightweight architecture decision record (ADR) process
- →Run the first structured team retrospective
- →Introduce or improve the incident response process
With trust established and early wins delivered, you can now drive strategic decisions. This is where the longer-horizon work begins.
- →Present the 12-month technology roadmap
- →Define engineering hiring plan if needed
- →Lead the first architecture review board session
- →Establish OKRs for engineering aligned with business goals
- →Present the technology narrative to investors or board if applicable
Phase 1: Listen and Map (Days 1–14)
The biggest mistake new CTOs — fractional or full-time — make is arriving with an agenda. You've seen problems like this before, you think you know what needs to happen, and you want to demonstrate value immediately by fixing things.
Resist this. Completely.
The first two weeks are for listening. Schedule 30-minute 1:1s with every member of the engineering team. Ask open questions:
- "What's the thing that slows you down the most?"
- "What would you change if you had authority over one thing?"
- "What are you most worried about that leadership doesn't know about?"
- "What's working well that you'd hate to see changed?"
You will hear consistent themes. The same problems will surface from multiple people independently — and those are your real priorities, not the ones leadership thinks matter most.
Simultaneously, do a technical inventory. Read the codebase. Not to audit it, but to understand it. Review recent deployments, incident logs, and support escalations. Look at what the monitoring covers and — critically — what it doesn't.
The deployment diary
Pull the last 6 months of deployment history and incident logs in the first week. The pattern of what breaks, how often, and how long it takes to resolve tells you more about the true health of a system than any architectural diagram.
Phase 2: Assess and Prioritise (Days 15–30)
By the end of week two, you have enough to make an honest assessment. Now you need to structure it and align with leadership.
I produce a single document — I call it the Technology Health Assessment — that covers:
- Architecture — current state, growth constraints, key risks
- Security — critical gaps and quick wins
- Engineering process — what's working, what's not
- Team — capability, capacity, and knowledge concentration risk
- Technical debt — a rough inventory with estimated cost to carry
- Tooling and vendors — whether the current stack is fit for purpose
The critical rule: make the assessment honest. Not brutal, not diplomatic — honest. If there's a security vulnerability that could sink the company, say so. If there's a team culture problem that will cause attrition, say so. This document is the foundation for everything that follows, and it needs to be trusted.
Share this document with the CEO and founding team before acting on it. Get their input. There will be context you're missing.
Phase 3: Quick Wins and Trust (Days 31–60)
Now you act — but selectively. In month two, pick two or three initiatives that:
- Can be completed within the month
- Deliver demonstrable, visible value
- Don't require significant engineering resources
- Address something that's bothered the team for a long time
The "bothered the team for a long time" criterion is important. When you fix something engineers have been complaining about for months, you build immediate credibility. You become the person who actually makes things better.
What counts as a quick win
Some of the highest-impact quick wins I've delivered:
- Setting up Slack alerts for production errors that were previously only visible in a log file nobody checked
- Migrating API keys out of a shared Notion document into a proper secrets manager
- Writing a single architecture diagram that gave the team shared vocabulary for a system they all understood differently
- Establishing a 30-minute weekly engineering sync that replaced ad-hoc Slack conversations
None of these required code changes. All of them made a measurable difference.
Phase 4: Strategic Direction (Days 61–90)
With two months of context and a track record of delivery, you now have the standing to drive strategic decisions.
The output of this phase is a 12-month technology roadmap that connects every significant engineering initiative to a specific business outcome. Not "migrate to Kubernetes" — but "migrate to Kubernetes to support the enterprise customer tier we're launching in Q3, which requires multi-tenant isolation."
Present this to leadership and the board if appropriate. Walk through each initiative: what it enables, what it costs, what happens if you don't do it.
This is also when you establish the recurring rhythms that will sustain the engagement:
- Weekly engineering sync — priorities, blockers, health check
- Monthly architecture review — one system or decision examined in depth
- Quarterly OKR review — are engineering efforts moving the business metrics that matter?
- Continuous security cadence — regular posture reviews and incident drills
What Makes This Different From a Consultant
A consultant delivers a report and leaves. A Fractional CTO is embedded in the team — building trust, shaping decisions in real time, and accountable for outcomes.
The framework above isn't designed to produce a deliverable. It's designed to build a relationship in which you become the trusted technology voice in the room — the person who gets called before the CEO signs the vendor contract, before the engineering team debates whether to rebuild the monolith, and before the next board meeting.
That trust doesn't come from your credentials or your previous experience. It comes from showing up, listening carefully, telling the truth, and delivering what you said you would deliver.
If you're evaluating whether a Fractional CTO engagement is the right fit for your company, let's talk. The first conversation is always about your situation, not my services.