"What does a fractional CTO actually do?" is a question founders ask in the first conversation. The vague version of the answer — "strategic technical leadership" — doesn't help. Here's the concrete version, structured as a 30-day playbook.
Days 1–7: orient
The first week is all listening. One-on-ones with every engineer, including contractors. Read the codebase — not to find bugs, but to understand the shape of the system and the conventions the team has built. Read the last six months of incident reports, sprint retros, and design docs. Talk to the CEO, the head of product, the customer-facing teams. Goal: understand the engineering function from the inside, not from the org chart.
What you don't do in week one: propose changes, kick off projects, introduce new processes, or call your first all-hands. Resist the urge to look productive. The work is invisible right now, and it's the most important week of the engagement.
Days 8–14: assess
Map the system. Document the architecture as it actually is, not as the original design doc says it's supposed to be. Identify the top three risks: security, scaling, key-person dependencies. Identify the top three friction points slowing the team down. Look at the hiring pipeline. Look at the on-call rotation. Look at the meeting calendar.
By the end of week two, you should be able to draw the system on a whiteboard from memory, name every engineer and their core strength, and explain in plain English why the team is or isn't shipping at the rate the CEO wants. Most of this is unwritten institutional knowledge being made explicit.
Days 15–21: align
Present findings to the CEO and leadership. This is a working session, not a deck — show what you've learned, where the gaps are, what the priorities should be, and where you'd push back on the current direction. Discuss tradeoffs. Pick the two or three things to focus on first.
The output of this week is the engagement contract: what we're going to work on, what success looks like, what we're explicitly *not* doing. Without this alignment, the rest of the engagement drifts.
Days 22–30: ship the first wins
Quick deliverables that build trust and demonstrate the engagement is going to be different. The wins are deliberately visible — to the team and to the CEO. Examples: a CI improvement that cuts deploy time in half. A hiring loop refresh that produces a better signal on candidates. A blocked architectural decision unblocked. A roadmap rewrite that the team actually believes in.
These wins do two things at once. They make the engagement real — the team feels the change. And they earn the credibility you'll spend on harder, longer-arc work in months two and three.
What you should not see in the first 30 days
A big rewrite proposal. An "AI strategy" deck. New process introduced top-down without the team's input. A reorg announcement. Those come later, if at all — and only after the engagement has earned the right to make them. A fractional CTO who walks in and immediately reorganizes the team is selling motion, not progress.
By day 30, the team knows you, the CEO has clear visibility into engineering, and trust is being earned through delivery instead of slides. That's the foundation. Everything else builds on it.
If this is the kind of engagement you're looking for, we'd love to talk.