The First 90 Days as a Fractional CTO

The first 90 days of a fractional CTO engagement are different from any other role. You don't have six months to find your feet. From day one, the company expects CTO-level decisions. And unlike a full-time hire, you're at one to two days per week. Every hour has to count.

This isn't a situation where you can spend the first month attending standups and "getting the lay of the land." You need a structured approach that compresses the learning curve without skipping the listening. This is how I structure those first 90 days, based on running this process across multiple engagements.

Key Takeaways

• Research by Michael Watkins (Genesis Advisors) found that 40% of executives fail within the first 18 months in a new role and the Corporate Executive Board puts the number as high as 50–70%. The cost of failure is estimated at 400% of the executive's annual salary (HBR, accessed 2026-05).
• Month one is for listening, not fixing. The most common mistake is moving to solutions before understanding the real constraints.
• At the 90-day mark, you should have a written architecture assessment, at least one material improvement shipped, and a working cadence with the engineering team. If those three things don't exist, the engagement isn't on track.

Why the First 90 Days Are Different for a Fractional CTO

Compress the time and you compress every risk. A full-time CTO can absorb context over weeks through sheer presence; at one to two days per week, you don't get that. The 30-60-90 framework below is how to manage that compression without losing diagnostic quality.

In research published alongside Michael Watkins' updated edition of The First 90 Days (accessed 2026-05), 87% of HR professionals considered leadership transitions one of the most challenging processes leaders face, and that's for full-time hires with full-time access. The fractional version is harder, not easier.

From practice: Founders almost always expect structural changes in month one, a new process, a new hire, a revised team shape. In my experience, almost none of those decisions are ready to be made in month one. The urge to act fast is understandable; you're paying for senior expertise and you want to see it working. But acting before you understand the context often means undoing the change in month two. One of the first things I do with a new client is explicitly agree that month one produces an assessment, not a plan of action.

Days 1–30: Listen Before You Fix

The first month is almost entirely diagnostic. Not because you can't add value yet, but because you're investing that time in understanding the company's technical reality, which is the only basis for adding value that lasts. This is the month where you build the map before you start moving the furniture.

Specific activities for month one:

• Stakeholder interviews: founder/CEO, product lead, and all tech leads, 30 to 45 minutes each. Ask about the company's biggest technical risks, what's slowing down shipping, and what they'd fix if they had extra time. Record or take detailed notes. You'll refer back to these.
• Codebase walkthrough: sit down with a senior engineer for two to three hours. You're not auditing line by line. You're getting a feel for architecture patterns, the areas where people wince when you ask about them, and the debt that's been quietly accumulating.
• Incident review: pull the last three to six months of incidents and postmortems. What breaks, how often, and how long does recovery take? This tells you more about the engineering team's operational maturity than any documentation ever will.
• Roadmap alignment: understand the product roadmap and then ask how the engineering team feels about it. Is it achievable? Is there a backlog of technical work that keeps getting pushed? Is the team involved in roadmap decisions at all?
• Hiring review: look at recent hiring decisions and current open roles. Who did they hire in the last 12 months, what drove those decisions, and what's still open? This is a proxy for where the team thinks its gaps are.

What not to do in month one: make structural changes, start a hiring process, restructure teams, or make public commitments about what you're going to fix. Any of those actions, before the full picture is clear, risks creating more problems than they solve.

The output of month one is a written summary for the founder, one to two pages, not a prescriptive action plan. An honest assessment of what you found: the technical risks, the team's actual velocity, where the product and engineering roadmaps diverge. Founders find this useful even when the news isn't great, because it replaces intuition with specifics.

Citation capsule: Leadership research consistently shows that the primary cause of executive failure in a new role is not capability, it's insufficient time spent understanding the cultural and organisational context before taking action. McKinsey found that three-quarters of executives considered themselves unprepared for a new position due to poor onboarding processes. A fractional CTO can't afford a full formal onboarding, which makes structured listening in month one even more important, not less. (McKinsey & Company; Michael Watkins, The First 90 Days, updated edition; both accessed 2026-05.)

What a fractional CTO actually does and doesn't do

What to Assess in the First Month (And How)

Structured assessment is the core work of month one. I use five dimensions, and I try to get a read on each one before forming any views about what to do.

1. Technical risk. What could take the product down, and how likely is it? I'm looking for single points of failure, undocumented critical systems, and infrastructure that's grown beyond the team's ability to reason about it.

2. Engineering velocity. How fast can the team actually ship, and what's impeding them? This is different from what the sprint board says. Talk to engineers about where they spend time that doesn't feel like building product.

3. Team capability. Where are the genuine skill gaps? Not the ones on the job descriptions. The ones that show up in the code review comments and the things that always require the same two people to get done.

4. Process gaps. What's missing or broken in the way the team works? This could be deployment automation, incident response, documentation, how decisions get made, or how work gets scoped before it enters a sprint.

5. Strategic alignment. Does the engineering roadmap reflect the business roadmap? Or is engineering working on a technical agenda that made sense 18 months ago but hasn't been revisited since?

From practice: The category that consistently surprises founders is technical risk. They usually know about the code quality problems, those are visible and discussed. What they don't know is the key-person dependency hiding in the middle of the stack: the one engineer who understands the payment integration, or the data pipeline, or the auth layer, and who happens to be quietly interviewing elsewhere. Finding that in month one, rather than month six, is often the most valuable thing the first-30-days assessment produces.

Days 31–60: Pick the First Win

Month two is about demonstrating value without over-committing. The 2017 HBR study of 500+ executives (HBR, accessed 2026-05) found that nearly 60% reported it took six months or more to feel effective in a new role. You don't have that luxury, but you also shouldn't try to close the gap by doing everything at once. The right move is to pick one thing and fix it properly.

A good first win meets three criteria: it visibly affects engineers' daily work, it has a measurable before and after, and it doesn't require changes that outlast the engagement if the scope shifts. A bad first win is anything that takes three or more months to show results, anything that requires team workflow changes without proper buy-in, or anything that creates new dependencies before the team trusts the approach.

Typical candidates for a strong first win at this stage:

• CI/CD pipeline: if builds are slow or flaky, fixing this is immediately felt by every engineer, every day. It's also self-contained, no cultural change required, just technical work.
• Architecture documentation: write it down. If the architecture lives only in two engineers' heads, producing a clear document of how the system works is valuable immediately and has long-term compounding returns.
• Engineering all-hands: if the team has no regular forum for technical alignment, establishing one in month two is low-cost, high-signal, and builds the muscle for the cadences in month three.
• Closing a critical open hire: if there's a senior role that's been open for four months and blocking work, take ownership of the technical side. Screen candidates, define the brief, run the technical interview, and make the recommendation. Directly useful and immediately visible.

Scaling your CI/CD pipeline without breaking your engineers

What Makes a Good "First Win"?

The first win is partly about the work and partly about trust. Engineers have seen consultants come through before; they've watched people parachute in, produce a slide deck, and leave.

The first win is how you demonstrate that you're different, that you understand the actual problem, that you can work within the constraints of the team, and that you're making things better rather than just making things visible. That's why the criteria matter. An improvement that the team can see and feel on Monday morning is worth more than a comprehensive restructuring plan that takes six months to validate.

Days 61–90: Build the Cadence

Month three is about establishing the rhythm that will carry the rest of the engagement. By day 61, you've done the assessment and shipped a first win; now you're building the infrastructure for ongoing work.

A 2023 McKinsey study on leadership transitions (accessed 2026-05) found that new executives who established clear operating rhythms in their first three months were significantly more likely to build high-performing teams within a year.

The core cadences:

• Weekly 1:1s with tech leads: 30 minutes, consistent agenda. Not a status update, a space to discuss technical decisions, team issues, and anything they're not sure how to handle.
• Monthly engineering all-hands: 30 to 45 minutes. Covers technical direction, recent decisions and why, and space for questions. This is how you build alignment without being in the building every day.
• Sprint review attendance: you should be present, even briefly, to maintain visibility on what's shipping and what's slipping.
• Hiring pipeline ownership: for any senior role, you should own the technical side of the process, defining the brief, running the technical interview, and making the recommendation.
• Technical steering group (for teams of 20+ engineers): a regular forum, monthly or bi-weekly, for senior engineers to surface architectural decisions, discuss trade-offs, and build shared ownership of technical direction.

From practice: The cadence element that gets skipped most often is the monthly engineering all-hands. It feels like overhead. "We already have too many meetings." But without it, you end up with a team that doesn't understand technical direction, doesn't feel ownership over decisions, and gradually stops surfacing problems until they're too big to ignore. Establishing the all-hands in month three, even at 30 minutes, is one of the highest-leverage things you can do for team alignment over a 12-month engagement.

What Should Exist at the 90-Day Mark?

By day 90, the engagement should have produced concrete, tangible outputs. If it hasn't, something has gone wrong, either in how the engagement was structured, how clearly expectations were set, or how the fractional CTO has been spending their time.

• Written architecture assessment covering current state and key risks
• Engineering team capability map, including key-person dependencies
• At least one material improvement shipped and visible to the team
• Weekly 1:1 cadences running with all tech leads
• Monthly engineering all-hands scheduled and running
• Hiring priorities documented and at least one active process underway
• Draft 3–6 month technical roadmap aligned with the product roadmap

If these don't exist at 90 days, the engagement isn't working. That's a conversation worth having at day 90 rather than day 180.

Engineering strategy that engineering teams will actually use

The Most Common First-90-Days Mistakes

After running this process across multiple engagements, the failure modes are predictable enough to list:

1. Trying to fix everything in month one. You look decisive. You create churn. Month two is spent unwinding the things you did before you understood the context.
2. Optimising for looking busy. Fractional CTOs who are insecure about the part-time model sometimes overcorrect by producing output at high volume. Output volume is not the metric. Impact is.
3. Not documenting anything. All the insight stays in your head. The month-one assessment never gets written. The founder has no artefact to refer back to, no baseline to evaluate progress against.
4. Skipping team relationship-building to go straight to technical. You can be technically right and still fail. Engineers who don't trust you will route around your decisions. Building relationships with the team in month one isn't soft work, it's the foundation for everything else.
5. Not being honest with the founder when the assessment is uncomfortable. This one ends engagements. Not because founders can't handle bad news, they can, but because softening the assessment or deferring the difficult conversation destroys the trust that makes the rest of the engagement work.

Frequently Asked Questions

How quickly should a fractional CTO produce visible results?

The honest answer is that month one produces an assessment, not visible results. Month two should produce at least one tangible improvement. If by the end of month two you can't point to something that's measurably better, that's a signal something isn't working, either in how time is being spent, or in how access and trust have been established.

What should I give my fractional CTO access to in week one?

Repository access, incident history and postmortems, the product roadmap, any existing architecture documentation, and the ability to schedule 30-minute conversations with your tech leads and product lead. Those five things allow the month-one assessment to happen. Without them, you're paying for someone to guess.

How do I evaluate whether the engagement is going well?

Use the 90-day checklist above as a baseline. Beyond that, ask yourself: does the engineering team seem to trust this person? Is the founder getting clearer answers to technical questions than they were before? Are decisions being made faster and with more confidence? If the answer to all three is no at day 90, the engagement needs restructuring.

What if the month-one assessment contains really bad news?

Good. Genuinely. Bad news you know about is a problem you can address. Bad news you don't know about is a risk that materialises on its own schedule. The right fractional CTO will deliver uncomfortable findings clearly and with a path forward, not just a list of problems. If you find yourself hoping the assessment doesn't surface anything difficult, ask yourself why you hired a fractional CTO in the first place.

Should I introduce my fractional CTO to the board?

Yes, and relatively early, certainly before the 90-day mark. The board will have technical questions in investor meetings and board sessions. Having a fractional CTO they've met, who can speak to technical strategy directly, changes those conversations. It also gives the fractional CTO the context to understand what technical credibility looks like to your investors, which shapes the work.

The 30-60-90 structure isn't rigid. Some engagements move faster in month one; others need more time in month two. What the framework provides is a shared language between the fractional CTO and the founder for evaluating progress, it turns "how's it going?" into a conversation that can actually be had. The 90-day mark is the natural point to reassess scope and plan the next 90 days. That's the rhythm. Not one sprint, but a series of arcs.