Your First 90 Days as a Fractional CTO: A Practical Playbook

The first 90 days of a fractional CTO engagement are the most important. They decide whether the team trusts you, whether the founder gets value, and whether the work you do later actually sticks.

Most fractional engagements go wrong in the first month. Two things happen most often. The new CTO shows up, sees a long list of problems, and starts trying to fix all of them at once. Or they spend so much time "listening" that nothing changes and the founder starts to wonder what they are paying for.

The playbook below avoids both. It is what I have used across enough engagements to know it works. It is not a script — every company is different — but the structure holds.

The Goal of the First 90 Days

Before the playbook, the goal. In the first 90 days you are trying to do three things:

1. Build enough trust with the team that they will tell you the real truth, not the polished version.
2. Understand the company well enough to tell the difference between a real problem and a symptom.
3. Make two or three visible improvements that prove the engagement is worth the money.

That is it. You are not trying to fix everything. You are not trying to rewrite the architecture. You are trying to learn fast, earn trust, and ship a few small wins that build the foundation for everything that comes after.

If you try to do more than that in 90 days, you will do all of it badly.

Days 1 to 30: Learn Before You Lead

The first month is mostly listening. This is the part most people get wrong.

Week 1: Meet Everyone

The first week is one-on-ones. Every engineer. The founders. Product. Design. Sales if they exist. Customer support if they exist. You are not running a formal review — you are just having conversations.

Ask each person three things:

1. What are you working on right now?
2. What is the most frustrating thing about working here?
3. If you had a magic wand, what would you change?

Listen more than you talk. Take notes. Do not promise anything. Do not jump in with opinions. Your job this week is to map the human side of the company before you touch the technical side.

You will hear the same things from multiple people. Those repeated themes are the real problems. The one-off complaints are usually noise.

Week 2: Read the Code and the Docs

In week two, go through the technical side. Not in detail — you do not have time for that — but enough to know what you are working with.

Look at:

• The main repository or repositories. Read the README. Try to set it up locally.
• The architecture diagram, if one exists. If it doesn't, that is itself useful data.
• The CI/CD setup. How long does a deploy take? How often does it fail?
• The on-call rotation. How often are people paged? For what?
• The last three months of incidents or post-mortems.
• The roadmap. The OKRs. The most recent retrospective notes.

You are not trying to become an expert in the codebase. You are trying to understand the shape of the system, the maturity of the practices, and where the rough edges are. Take notes. Do not start fixing anything yet.

Week 3: Sit in the Meetings

Spend week three watching the team work. Sit in on standups, planning sessions, retros, design reviews. Watch how decisions get made. Watch who talks and who doesn't. Watch how disagreements get resolved — or not resolved.

This is where you learn the real culture, which is almost never what the founder describes. The gap between "how we say we work" and "how we actually work" is usually big, and it is the most important thing for you to understand.

By the end of this week you should have a clear picture of where time is being wasted and where decisions are getting stuck.

Week 4: Write It Down

In week four, take everything you have learned and write it down. One document. Not for the team yet — for yourself.

Structure it loosely as:

• What this company does well. Always start here. There is always something.
• The two or three real problems. Not the long list. The biggest things, named clearly.
• What you are going to do about each one. First steps only. Not the whole solution.
• What you are explicitly choosing not to address right now. Just as important.

Share a short version of this document with the founder at the end of week four. Not the whole thing — a one-page summary. This becomes the contract for the next 60 days. It also signals that you have actually been listening, not just collecting hours.

Days 31 to 60: Pick Your Battles

The second month is when you start making changes. Not many. Two or three. The ones that matter most.

Choose Two or Three Things

You will be tempted to do more. Resist. The team can absorb a small number of meaningful changes well. They cannot absorb a large number of changes at the same time without either resisting or burning out.

Pick changes that meet three criteria:

1. They address something real, not something theoretical.
2. The team will feel the improvement quickly — within a few weeks, not next quarter.
3. They give you a chance to show how you work, so the team learns what to expect from you on bigger things later.

Common first-month picks I have used:

• Fixing the deploy pipeline if it is slow or unreliable. Engineers feel this every day. A faster, more reliable deploy is an immediate quality-of-life improvement.
• Tightening up the on-call rotation if it is chaotic. Clear rotation, clear runbooks, clear escalation. People stop dreading the pager.
• Rebuilding the planning cadence if it is broken. Often this just means killing meetings that don't add value and making the ones that remain more useful.
• Naming the technical strategy if there isn't one. A simple one-page document of where the architecture is going. Not a rewrite — just a direction.

Pick the ones that fit your situation. Do not pick all of them.

Hold the Line on Scope

The founder will try to add more. New problems will emerge. Engineers will surface things they want you to look at. This is normal. The discipline is to keep the scope tight.

When new things come up, the answer is usually: "I hear you. That is real. It is on the list for the next 30-day cycle. For now, we are focused on the three things we agreed on."

Founders sometimes find this frustrating. That is fine. The alternative is doing five things halfway, which is worse than doing two things well.

Hire or Free Up the Right People

By day 45 you should have a clear sense of which people on the team are the ones to bet on, which ones need development, and which ones are in the wrong seat. Start moving on this carefully.

This is not about firing in month two — that is almost always too soon. It is about identifying who you want close to the work, who needs more support, and what hire you most need to make in the next 90 days.

If there is a key hire to make — a senior engineer, an engineering manager, a head of platform — start that search now. Hires take three to six months. Starting on day 45 means the person is on board by day 180. Waiting until day 90 to start means you are still hiring at day 270.

Days 61 to 90: Show the Wins

The third month is when the work shows up.

Ship the Changes

By day 60 you should be visibly partway through the two or three things you picked. By day 90 you should have shipped at least one of them in a way the team can feel.

This is the part that matters most for the engagement. The founder hired you to make things better. By day 90 they should be able to point at specific things that are better. Not a vague "things feel different" — specific, named, measurable.

If you can't point to wins by day 90, the engagement is in trouble. Either the scope was wrong, the pace was wrong, or the wrong things were picked. This is the time to be honest about that, not to push it under the rug.

Do the First Real Review

Around day 75 or 80, run a structured review with the founder. Not a casual check-in — a real one.

Cover:

• What we agreed to do. Pull up the one-pager from day 30.
• What actually happened. Honest assessment. What landed. What didn't. Why.
• What we learned about the company. Things that look different now than they did on day one.
• What the next 90 days should focus on. This is where the engagement evolves. The work in months 4 to 6 is usually different — and often deeper — than the work in months 1 to 3.

This conversation re-anchors the engagement. Without it, fractional engagements drift. The founder forgets what they originally hired you for. You forget what you originally committed to. Neither side knows whether things are going well.

Make the Engagement Less Necessary

This is the most important habit and the one most fractional CTOs ignore.

From the first day of the engagement, you should be building capacity in the team, not creating dependency on yourself. Every decision you make alone should be a decision you teach the team to make next time. Every meeting you run should be a meeting an internal person could eventually run.

By the end of 90 days, you want the team to be slightly more independent than they were before you arrived. Not dependent on the next month of your time to keep functioning.

This sounds bad for business — "isn't the goal to keep the engagement going?" — but it is actually the opposite. Founders who feel the team is getting stronger keep you around longer. Founders who feel the team is getting weaker without you start to resent the cost.

Build capacity. Always.

Common Mistakes to Avoid

A few specific things go wrong often enough that they are worth naming.

Trying to be the smartest person in every room. You are not there to win arguments. You are there to make the team better. The best fractional CTOs spend more time asking questions than giving answers, especially in the first 60 days.

Promising a roadmap in the first week. You don't know enough yet. Anything you commit to in week one is going to be wrong by week four. Buy yourself the time to learn first.

Comparing this company to your last one. Every company is different. The thing that worked at your last company will probably break this one. Earn the right to make recommendations by understanding this company first.

Avoiding hard conversations. If the founder is the problem, you have to find a way to say it. If a senior engineer is blocking the team, you have to address it. Fractional CTOs who avoid hard conversations get hired again and again for the same engagement at companies that never actually get better.

Stretching one-day-a-week into half-day-spread-across-five-days. This kills focus and creates the illusion of more time than you actually have. Block real days. Be fully present on those days. Be honestly unavailable on the others.

What Good Looks Like at Day 90

If the first 90 days have gone well, three things should be true:

1. The team trusts you. They tell you the real truth, not the polished version. Engineers come to you with hard problems instead of working around you.
2. The founder sees concrete results. They can name specific things that are better than they were 90 days ago.
3. The next 90 days are clearer than the first 90 were. The engagement has a focused direction, not just an open-ended "keep helping us."

If all three are true, you have built the foundation for a long, useful engagement. If one or two are missing, this is the moment to address it — not three months from now.

A Closing Note

The first 90 days are not glamorous. There is no big architecture redesign. There is no dramatic turnaround. There is a lot of listening, a few carefully chosen changes, and a small number of visible wins.

That is the point. Fractional CTO engagements that try to do more in the first 90 days almost always do less in the first year. The engagements that pace themselves are the ones that compound.

If you want to talk through a fractional engagement at your company — or if you are an engineering leader stepping into one and want a sounding board — I'm happy to have that conversation. And if you are earlier in the decision, What is a Fractional CTO? and Fractional CTO vs Full-Time CTO are the right places to start.