The first 90 days as a fractional CTO

A fractional CTO engagement starts the way most consulting engagements should not. Someone phones, usually a chair or a CEO, and the first sentence is a version of "we are not sure what is going on with technology, but we know it is not working." The second sentence is almost always a number. A delivery slipping by months. A cost that has doubled. A platform that is down too often. A board paper that contradicts itself.

The brief at that point is rarely well formed. Asking the client to write a clean brief is the wrong move. The brief is what you produce in the first thirty days. The first ninety days are how you turn that brief into something that has actually shifted.

This is what the shape of that work looks like, drawn from a sequence of engagements across regulated industries, PE-backed assets, and public sector. The detail is different every time. The shape is remarkably consistent.

Phase one: see (days 1 to 30)

The first phase looks like nothing is happening. That is correct. You are building a model of the estate that the people running it cannot give you, because they have either lost perspective or never had it. The output is a written assessment of every material system on one ranking scale. We use Rickety, Sickety, Ticketyboo. Anyone else's three-band scale works fine. The point is the comparison.

The discipline is tight. Every system gets a ranking, a confidence score, and one sentence on what would have to change to move it up a band. No system is exempt because it is too important, or too political, or too new to assess. If you cannot rank it, say so on the page and move on. The gaps tell you as much as the rankings.

Alongside the inventory, you do three meetings that have to happen before day twenty. They are not the obvious ones.

• The CFO. Not the FD, not the controller. The person who owns commercial decisions. You are looking for the difference between budget, forecast, and actual on technology, and for which contracts are within the next ninety days of renewal. You will spend the rest of the engagement working with this person. Start now.
• The most senior engineer who is still hands-on. Sometimes a principal engineer, sometimes an architect, occasionally the head of platform. They know what is broken and what is duct tape. They have usually told someone, more than once, and been ignored. You are not there to validate them. You are there to find out what they stopped saying.
• The customer who complains the most. External customer if it is a product business, internal business unit if it is a corporate function. The shape and frequency of their complaints is the cleanest signal you will get about whether the systems work. Treat their complaint log as a dataset, not as noise.

While these are happening, you also read the meeting minutes. Twelve months of board papers, exec meetings, and any technology programme steering committee that has been running. You are looking for the same problem appearing in different language across successive months. That is the signal that the organisation has noticed but cannot decide. It is almost always within a step of the real constraint.

Phase two: decide (days 31 to 60)

The midpoint of phase one and phase two is the moment you name the constraint. It is one sentence. "We cannot ship to production reliably because the deployment pipeline depends on a single engineer's laptop." "Our customer support cost is rising because every escalation requires a developer." "Our data is correct in the warehouse but wrong everywhere a customer can see it." Whatever it is, it has to be small enough to fit on one slide and concrete enough that two reasonable people could agree that fixing it would unlock everything else.

Naming the constraint is the highest-leverage action of the engagement. Get it right and the priorities order themselves. Get it wrong and you spend ninety days fixing symptoms while the real issue compounds. The test is whether the fix would make the next three problems easier or just defer them.

Once the constraint is named, the prioritised plan writes itself, more or less. It should fit on a single page. It has three parts: what gets done in the next thirty days, what gets started, and what gets explicitly deferred with a reason. The deferred list is as important as the active list. It is the only protection you have against the organisation reverting to "do everything at once" once the pressure relaxes.

Phase three: move (days 61 to 90)

Phase three is execution. By day sixty, the constraint is named, the plan is signed off, and the first interventions are in flight. Phase three is making them land. This is where most engagements quietly fail. The plan is clean, the team agrees, the budget is approved, but nothing actually changes on the ground because nobody owns the work end-to-end with enough authority to clear blockers in real time.

That is the role of the fractional CTO in phase three. Not to do the engineering. To remove obstacles fast enough that the engineering can happen. The most common obstacles are not technical. They are a security review that has not been scheduled, a procurement decision waiting on a signature, an internal team that has not been told their priorities have shifted, a third party whose contract turns out to forbid the change you are making.

Three things have to be true at day ninety. The constraint is visibly easing. At least one measurable indicator is moving in the right direction. The board can see what comes next, in writing, on one page. If any of these is missing, you have not finished phase three even if the calendar says you have.

What does not work

The patterns that fail are predictable.

Strategy first. Some incoming CTOs spend the first ninety days writing a strategy. By day ninety the strategy is well-written and nothing has shifted on the ground. The board's confidence has not recovered, because nothing observable has changed. Strategy is downstream of an estate you understand. Get the estate first.

Re-organisation as the first move. Tempting because it is visible. Almost always wrong. Re-orgs are expensive in trust and slow in payoff. Save them for after the constraint is named and the answer turns out to be a structural one. In most engagements, the structure was not the constraint. The clarity was.

Tool selection as a deliverable. Choosing a new platform, new vendor, or new framework feels like progress. It rarely is, in the first ninety days. The existing tools usually work. The reason they look broken is that no one is using them consistently. Forcing a tool decision early defers the conversation about discipline that has to happen anyway.

Deferring hard conversations. A fractional engagement compresses time. The conversation about an underperforming senior engineer, a vendor that is not delivering, or a sponsor who has lost faith in their own programme has to happen by week six at the latest. Defer it past week six and it spills into the second half of the engagement, which costs you the time you need for execution.

What changes for the board

The board hired a fractional CTO because they had a question they could not answer. Usually some version of "is this fixable, and if so, in what timeframe and at what cost." The first ninety days exists to answer that question with evidence. Not opinion, not a roadmap, evidence.

The day ninety board update has three sections. What we found, written so a non-technical director can follow it. What we did, with measurable changes. What comes next, as a sequenced plan with named owners and explicit dependencies. Two pages, a one-page appendix for the assessment table, and a verbal walkthrough.

At that point the engagement either becomes the next ninety days or it hands over. Both should be possible. If only one of them is possible, something has gone wrong with the brief.

A fractional CTO engagement is not a strategy review. It is a delivery commitment with a clock on it. The promise is not that you will know everything by day ninety. The promise is that the system will be moving in the right direction, the board will be able to see it, and the next step will be obvious enough that the organisation can take it without you in the room.

That is the work. The first ninety days are where it gets earned.