The First 30 Days With a Fractional CTO: What Should Happen

The first 30 days of a fractional CTO engagement are the most diagnostic. By day 30, you will know with reasonable confidence whether you hired for advisory or installation, whether the engagement is going to produce something durable, and whether the person you hired is doing what they said they would do.

Most engagements that end in disappointment show the warning signs before day 30. Most engagements that deliver real value also show the signal before day 30. The pattern is visible early. Knowing what to look for tells you whether to stay the course, redirect, or cut losses before you have spent six months getting advice you could not act on.

What Day One Through Five Should Look Like

The first week should be oriented almost entirely toward deep discovery, but discovery with a deadline. The fractional CTO should be reading the codebase, talking to every engineer on the team, reviewing the production incident history, and forming an early view of where the biggest leverage points are.

The signal to watch in week one is whether the discovery is pointed or open-ended. A fractional CTO who asks structured questions with a clear framework for what they are trying to understand is doing diagnosis. A fractional CTO who is simply absorbing information without a clear framework for what it means is doing the beginning of an advisory engagement.

By the end of week one, you should be able to have a conversation where the fractional CTO tells you: here is what I have seen, here is what I think the highest leverage points are, and here is what I want to start working on in week two. If the week one debrief is a list of observations without a recommended starting point, push back. The diagnostic phase should produce a direction, not more questions.

Also in week one: the fractional CTO should have met the leadership team and made clear how they want technology decisions to be made during the engagement. Which decisions do they want to be involved in? Which can the team make without them? What should escalate? This clarity prevents the most common early failure mode: the fractional CTO being pulled into every meeting rather than focused on the highest-leverage work.

What Week Two Should Produce

Week two is where the first concrete work should appear. Whatever the fractional CTO identified as the highest leverage starting point in their week one debrief should have a work-in-progress deliverable by the end of week two.

If the starting point is context infrastructure, a draft CLAUDE.md should exist by end of week two, ready for review with the senior engineers who know the codebase best. If the starting point is an architecture review, a written summary of the three to five most significant findings and the recommended sequence for addressing them should exist. If the starting point is a specific project that needs technical leadership, that project should have started.

The deliverable does not need to be final or polished. It needs to exist. A fractional CTO in week two who can show you something real that did not exist in week one is demonstrating that the engagement is moving toward installation. A fractional CTO in week two who is still in discovery, still forming views, still not ready to put anything in writing is demonstrating that the engagement is moving toward advisory.

This is a hard conversation to have early if the fractional CTO is confident and articulate. They may have good explanations for why the discovery phase needs more time. Those explanations may even be accurate. But the pattern of needing more time before producing anything is the same whether it is genuine caution or a sign that the person is more comfortable advising than delivering. You want the pattern to break early.

What Week Three Should Establish

Week three is the point where the engagement should be showing up in the team's work, not just in leadership conversations.

This means the fractional CTO should be in the engineering team's workflow: attending relevant team sessions, doing real work alongside engineers rather than only talking to them, and becoming a visible presence in the day-to-day of how engineering gets done. A fractional CTO who is visible at the leadership level but not in the team's actual work is producing advisory engagement dynamics regardless of what the contract says.

The engineers on the team should have a clear sense by week three of what the fractional CTO is working on, why it matters, and what they should be doing differently as a result. If the engineering team describes the fractional CTO as "someone who has meetings with leadership," the engagement has not established itself at the team level. If they describe the fractional CTO as "working on the context infrastructure with us" or "helping us redesign our review process," the engagement has.

Week three is also when the first iteration should happen on whatever was started in week two. The draft CLAUDE.md should have been reviewed and improved. The architecture findings should have been discussed with the relevant engineers and the first one should be in progress. The project should have had its first real cycle of work. The pace of iteration tells you how the engagement will run for the remaining weeks.

What Day 30 Should Look Like

By day 30, three things should be true.

First, something should exist that did not exist 30 days ago. Not a plan for something. Not a recommendation for something. The thing itself, in however early a stage. If the engagement is about context infrastructure, the CLAUDE.md should be in the repository and the team should be using it. If it is about review standards, the written standards should exist and at least some PRs should have been reviewed against them. If it is about a specific project, the project should have made meaningful progress with the fractional CTO's direct involvement.

Second, the team should be doing something differently. The fractional CTO's presence should be visible in how the engineering team is working, not only in what leadership is thinking about. Engineers should be able to point to something specific: "we are doing our reviews differently," "we have a CLAUDE.md now," "we are tracking incident rate alongside velocity." If the team's day-to-day work is unchanged, the engagement has produced advisory outcomes regardless of what the deliverables look like on paper.

Third, you should be able to see a clear path from where you are to the agreed success criteria. At day 30, the engagement is roughly a third to a quarter of the way through a typical 90-day engagement. The progress made should give you confidence that the success criteria are achievable in the remaining time. If day 30 feels like you are still at the beginning, you have a problem.

What to Do If Day 30 Is Only a Roadmap

If day 30 arrives and the primary output is a strategy document or a detailed roadmap without implementation started, the engagement has slipped into advisory.

This is recoverable if you catch it at day 30. It is much harder to recover if you notice it at day 60 or 90, when the engagement is ending and you are left with documentation you need to implement without the person who wrote it.

The conversation at day 30 should be direct: we agreed the engagement would produce installed capability, not advice. The deliverable at day 30 is a roadmap and not an implementation. What needs to change for the remainder of the engagement to produce the agreed outcomes rather than documentation?

A good fractional CTO will engage with this conversation honestly. They may have a legitimate explanation for why the first 30 days went differently than planned. More often, they will acknowledge the pattern and redirect. Either way, having the conversation at day 30 gives you 60 more days to course-correct.

If the response to the day 30 conversation is defensive, or if the fractional CTO argues that the strategy document is itself the deliverable, the engagement is not going to produce what you hired for. Ending or restructuring at day 30 is better than running a full advisory engagement when you hired for installation.

The AI Engineering Maturity Assessment is a useful tool to run at the beginning of any fractional CTO engagement. It establishes a baseline across five dimensions and gives both you and the fractional CTO a specific starting point for what the engagement should address. Use it in week one.

Most fractional CTO engagements end with a strategy deck. Mine end with capability your team runs without me. See how I work or book a 20-minute call.