The First 30 Days: What a Great Fractional CTO Delivers in Month One

If you are hiring a fractional CTO, the single best thing you can do before the engagement starts is get crisp on what the first 30 days should look like. Not "get to know the team." Not "assess the situation." Those are fine activities, and they are also the kind of vague deliverables that protect underperformers. You deserve specifics.

This article is the 30-day plan I run on every engagement. I give it to clients before we start. I work against it in public. It is a contract between me and the founder that makes the value of the first month visible and measurable — and more importantly, it sets the rhythm for everything that comes after.

If you already have a fractional CTO and you are not sure whether they are delivering, this is also a useful mirror. Compare their first 30 days against what follows.

The shape of month one

A great 30-day plan does three things at the same time. It learns the company fast enough to be useful. It ships something concrete so the team sees real value, not just meetings. And it decides on the direction for the next 60–90 days so the engagement has momentum going into month two.

Those three threads — learn, ship, decide — run in parallel. Any fractional CTO whose first-month plan is only one of the three is doing the job wrong. Pure learning is what advisors do. Pure shipping is what contract engineers do. Pure deciding is what consultants do. You are paying for a leader, which means all three.

Week 1: Listen and look

Goal: Understand the real state of the team, the codebase, and the founder's actual concerns. Not the versions that get said in meetings — the real versions.

The founder conversation

Day one is a long, private conversation with the founder. Not a kickoff meeting with slides. A two-hour, uninterrupted, candid conversation about what is working, what is not, and what is keeping them up at night. I ask questions like:

What are you most worried about on the technical side right now?
If one thing about engineering suddenly fixed itself tomorrow, what would you want it to be?
Who on the team do you trust? Who do you not? Who do you not know well enough to answer?
What decisions have you been avoiding because you do not know how to make them?
What would success look like to you in 90 days?

These answers shape everything that follows. A founder who cannot answer them is a founder who is going to get a generic engagement, because no one can run a specific engagement without specific information.

The engineer 1:1s

Next I meet every engineer on the team individually, for 30–45 minutes each, in the first week. Three questions:

What are you working on right now and what is in your way?
If you could change one thing about how the team works, what would it be?
What am I not going to hear from anyone else on this team that I should know?

The third question is the one that earns its keep. It is where engineers tell me the things they would never say in a standup — the person who is checked out, the piece of the code nobody wants to touch, the decision that was made six months ago that nobody thinks was right.

The codebase walk

I spend several hours reading the codebase directly. Not a tool-assisted audit report. Me, reading the actual code, the actual pull requests, the actual tests, the actual infrastructure. I want to see the shape of it myself. Bad codebases hide well in abstract summaries. You have to read them.

The artifact

At the end of week 1, the founder gets a written document from me called "What I'm seeing so far." Two or three pages, blunt, honest, no softening. It covers: the state of the team, the state of the codebase, the two or three things I think matter most, and the three questions I still need answered before I can propose a 90-day plan.

Week 2: Install the operating rhythm

Goal: Get the weekly cadence running — standups, engineering review, planning, 1:1s — so the team has a heartbeat and the founder has visibility.

I have written a separate article on the exact weekly operating rhythm I install; the short version is that by the end of week 2, the following should be true:

Async written standups are happening daily in a dedicated Slack channel, with 100% participation.
A weekly Monday planning meeting is on the calendar and has a shared planning doc that the team owns together.
A weekly Wednesday engineering review is on the calendar, including a short demo of anything shipped the previous week, and the founder attends.
A weekly Friday founder-and-CTO sync is on the calendar.
I am doing 30-minute biweekly 1:1s with every engineer.
A short Friday written update goes out team-wide.

Installing this is not glamorous work. It is also the single highest-leverage thing I do in month one. A team with a broken rhythm cannot be fixed by better architecture or better tooling. The rhythm comes first because it is the forcing function for everything else.

The artifact from week 2: a calendar that looks different from the one the team started the month with, plus the first real Wednesday engineering review on the books.

Week 3: Ship something real

Goal: Deliver one concrete, visible improvement. Not a proposal. Not a plan. Something the founder and the team can point to and say "that is better now."

This is the week that separates a real fractional CTO from a consultant. The specific thing shipped varies by engagement, but the shape is always the same: a real problem, a real fix, rolled out in a real environment. Examples from recent engagements:

Installed DORA metrics tracking in an afternoon, backfilled four weeks of data from git, and presented the baseline at the Wednesday engineering review. The team's lead time was worse than anyone thought. Conversation started.
Rewrote the CLAUDE.md file for a client's monorepo and ran the team through the Plan → Spec → Execute → Verify loop on a real feature. Velocity on AI-assisted work doubled within two weeks.
Audited the cloud bill line by line and killed $3,400 per month of waste the founder had been meaning to look at for a quarter.
Fixed a long-standing deploy flakiness issue that had been "in someone's backlog" for three months. One afternoon of real work.
Conducted a code review of the billing module and identified three silent bugs that would have caused customer-facing issues within the quarter. Wrote the tickets to fix them.

The common thread: concrete, completed, visible. Not a deck about what should be done. A thing that is now done. This is what buys you trust from the team and confidence from the founder going into month two.

Week 4: Decide the direction

Goal: Deliver a written 90-day plan with specific, owned, dated deliverables, and get the founder's buy-in on it.

By the end of week 4 I have enough context to propose the next 60–90 days in real detail. The document I deliver is usually 4–6 pages and has five sections:

1. What I'm seeing

A sharper, updated version of the week 1 document. Same honesty, more specificity. The team dynamics, the codebase state, the strategic risks, the specific strengths I want to protect.

2. The three things that matter most

I force a ranking. Not "here are ten things to work on." Three. The three things that, if we fix them in the next 90 days, will move the company the most. Everything else goes on a "later" list.

Forcing this prioritization is where most founders and most CTOs fail. Everything looks important. Everything cannot be worked on at once without producing nothing. A fractional CTO who will not commit to three priorities is not doing the job.

3. The 90-day plan

A week-by-week plan for the next 13 weeks, covering the three priorities. Each week has 1–3 specific outcomes with named owners. Some owners are me, some are engineers on the team, some are the founder. The plan is realistic about scope — it accounts for holidays, for on-call load, for the fact that surprises happen.

4. The metrics we will track

The numbers we will watch weekly to know whether the plan is working. Usually some combination of DORA metrics, a handful of product metrics, and one or two specific diagnostic numbers for whatever was broken at the start.

5. The decisions I need from the founder

Every plan requires founder decisions. I list them explicitly: hiring, vendor choices, scope tradeoffs, tech debt priorities. I do not proceed on these without a clear yes or no.

The Wednesday review

The end-of-month 90-day plan gets presented in the last Wednesday engineering review of the month. Not as a mandate, as a proposal. The team gets a chance to push back on it before it becomes the operating plan. Any good proposal changes a little based on that pushback. That is the point.

What the founder should see at day 30

If the engagement is working, here is what the founder should be able to say at the 30-day mark, honestly:

"I know what my engineering team is doing this week and why."
"I know what the biggest risks are and we have a plan for each one."
"I have a written document I can use to explain the engineering plan to my board or investors."
"The team feels more organized than it did 30 days ago. At least two of them have said so unprompted."
"At least one concrete thing got better in the codebase or the infrastructure this month."
"I spent less of my own time on engineering questions this week than last week."

If any of those is not true at day 30, the engagement is off track and you should say so out loud in the next sync. A good fractional CTO welcomes that conversation — they would rather hear it in week 4 than in month three.

What the team should see at day 30

The team's experience matters too, and it is often overlooked. If month one went well, the engineers should be able to say:

"The new operating rhythm is lighter than I expected and I have more maker time."
"Someone senior is paying attention to the things that were hard before."
"I have had at least one real 1:1 with the new leader and it was not performative."
"Something visible got fixed this month that had been broken for a while."
"I am not worried that this person is going to blow up the team or waste my time."

These are low bars and yet they are not always cleared. A fractional CTO who arrives with slides and strong opinions but no listening will have already lost the team by day 30. The engineers are the customers of the operating rhythm, and if they are not convinced, nothing else will take.

Counterpoint: what happens when month one is hard

Not every month one is clean. Sometimes the situation is worse than the founder initially described and the "ship something real" goal shifts to "stop the bleeding on something that is actively broken." Sometimes there is a personnel issue that becomes unavoidable in week 2 and half the month goes into handling it. Sometimes the codebase is in such bad shape that the honest artifact at day 7 is "this needs a much bigger intervention than originally scoped."

All of this is fine, as long as it is said out loud. The value of a written 30-day plan is that it makes deviation visible. A plan that slips is not a failed plan — it is a plan that is telling you something new about the situation. The failure mode is silence, not slippage.

Your next step

If you are in the middle of hiring a fractional CTO, or about to be, print this article and share it with them. Ask: "Is this the kind of month one you would run? If not, walk me through yours." Their answer will tell you more about whether they will be effective than any resume or reference check.

If you are a founder who is currently stuck trying to decide whether to bring one in at all, the 30-day frame is also useful: if you cannot imagine any of the above being valuable at your company in the next month, you probably do not need a fractional CTO right now. If even two of them would obviously help, you almost certainly do.

Where I come in

I run this exact 30-day playbook on every engagement. It is written in my standard engagement agreement and I am measured against it. The first month is the highest-leverage part of the whole engagement, and I treat it that way.

If you want to see what the first 30 days would look like at your company specifically, book a 30-minute call. I will ask you the week 1 questions live, and by the end of the call you will have a much clearer picture of what month one would actually deliver for your team.