The First 90 Days as a Fractional CTO

My first 90 days with any new company follows a simple, repeatable pattern: Diagnose, Plan, Execute. It’s a 30-60-90 plan, but not the kind you get in a corporate welcome packet. This is a focused campaign to find the points of highest use in your technology, team, and process, and to apply force exactly where it will do the most good. My goal is to deliver tangible results within one quarter.

Founders hire me because they have a technology problem they can’t solve. Maybe growth has stalled, the product is buggy, the engineering team is unhappy, or they just have a sinking feeling that things are slower and more expensive than they should be. They're anxious. My job is to replace that anxiety with a clear plan and measurable progress. This framework is how I do it, every single time.

Phase 1: Diagnose (Days 1 to 30)

My primary rule for the first month is simple: I observe. I don't change anything. The biggest mistake a new technical leader can make is to start rearranging the furniture before they know which room is which. The urge to show value immediately is strong, but premature action often creates more problems than it solves. My job is to listen and learn. I have a mental checklist of what I'm looking for.

The People

I schedule a 30 minute one on one with every single person on the engineering team, and with key people from product, design, and marketing. I ask the same simple questions: What’s working well here? What’s frustrating? If you had a magic wand, what’s the one thing you would change? I’m listening for patterns. Is everyone complaining about the slow test suite? Does the name of one particularly painful part of the codebase come up over and over? I’m also assessing skill levels, team dynamics, and who the informal leaders are. The person everyone goes to for help isn't always the one with the fanciest title.

The Process

I want to understand how an idea becomes a feature that a customer can use. I trace the entire path. How are tickets created? How is work prioritized? What does a pull request look like? Is there a review process? How is code tested? How is it deployed? I look at the actual tools: the Jira backlog, the GitHub pull request history, the CI/CD pipeline logs. I’m looking for friction. A 45 minute deployment pipeline is friction. A pull request that sits for three days waiting for review is friction. A manual testing process that takes a whole day is massive friction.

The Product and The Business

Technology doesn't exist in a vacuum. I need to understand the business as well as the founder does. What are the company's goals for the next six months? The next year? Who are your most important customers? What are the most critical user journeys in the application? If the payment screen goes down, it’s a crisis. If an internal admin page has a typo, it’s not. Understanding this context is crucial for making smart trade offs later. I can't prioritize technical work if I don't understand the business impact.

The Codebase

I'm a technical leader, so yes, I look at the code. But I'm not looking for style violations or minor imperfections. I’m looking for risk. Where is the code complex and hard to understand? Is there a good test suite that gives the team confidence to make changes? How old are the key dependencies? An application running on a version of a framework that lost security support two years ago is a ticking time bomb. I use tools to analyze code churn and complexity. A file that is changed constantly by many different people is often a sign of a design problem. The goal isn't to judge the past, but to understand the current reality of the system we have to work with.

At the end of this 30 day period, I produce a document. It's usually a 3 to 5 page summary for the founder. It's a “State of the Union” for the technology organization. Here’s what’s working, here’s what’s fragile, and here’s what’s scary. No solutions yet. Just the facts.

Phase 2: Plan (Days 31 to 60)

With the diagnosis complete, we can now form a plan. This is where I transition from observer to strategist. The goal is not to create a giant, multi-year roadmap. The goal is to identify the most important work for the next quarter. We do this by sorting all the problems and opportunities we found in Phase 1 onto a simple 2x2 matrix: Impact versus Effort.

This exercise is critical, and I always do it with the founder. It forces an honest conversation about priorities. My job is to explain the effort (this is a 2 week fix, this is a 6 month architectural project). The founder's job is to clarify the business impact.

From this exercise, three categories of work emerge:

Quick Wins

These are the low effort, high impact tasks. We should identify 2 or 3 of these to tackle immediately. Examples might include fixing the flaky test suite that everyone complains about, automating a manual deployment step to make shipping easier, or upgrading a critical library that has a known security vulnerability. These wins are important because they build momentum. The team sees that things are improving, and the founder sees a return on their investment in me.

The Big Rocks

These are the high effort, high impact initiatives. They are the major projects that will meaningfully change the trajectory of the business. We can typically only take on one or two of these per quarter. A Big Rock could be a major refactor of a problematic part of the codebase, a migration to a more scalable database, or building the infrastructure to support a new product line. These require careful planning and dedicated resources.

The “Do Not Touch” List

This is the most important part of the plan, and often the hardest for founders to accept. These are the things we are explicitly deciding not to work on. This could be low impact work, or it could be high impact but astronomically high effort. For example, a complete rewrite of the entire application is almost always on this list. Yes, the current codebase has what we call technical debt^[1], but it works and it's making money. We will consciously choose to accept the pain of working with it in exchange for shipping features that customers want. Saying no is a core function of leadership. Without a “Do Not Touch” list, you don’t have a strategy, you just have a list of wishes.

The deliverable for this phase is a one or two page document outlining the plan for the next 90 days. It lists the Quick Wins and the Big Rocks, with clear owners and success metrics. We agree on it, and then we commit to it.

Phase 3: Execute (Days 61 to 90)

Now the work begins. My role shifts again, from strategist to leader and manager. My job is to make the team successful and to ensure we deliver on the plan we created.

Unblock and Protect the Team

My calendar is filled with meetings so the engineers' calendars can be empty. I run interference with other departments, I clarify requirements, and I push back against distractions. My primary job is to create an environment where engineers can get into a state of flow and do the deep work that shipping great software requires.

Establish Rhythms

I work with the team to implement or refine simple, predictable processes. This isn't about bureaucracy. It’s about creating a rhythm. This might mean a weekly planning meeting, daily standups that are actually short, and regular demo days where the team can show off their work. The goal is to make progress visible and predictable. For teams struggling with chaos, I often introduce a lightweight system like Shape Up^[2], which focuses on shipping a meaningful chunk of work in a fixed time-box (like six weeks).

Measure What Matters

We can't improve what we don't measure. I introduce a few key metrics to track our progress. I’m a big fan of the four DORA metrics, which are industry benchmarks for high performing teams:

1. Deployment Frequency: How often do we ship code to production? (More is better)
2. Lead Time for Changes: How long does it take from a developer committing code to that code being in production? (Shorter is better)
3. Change Failure Rate: What percentage of our deployments cause a problem for users? (Lower is better)
4. Time to Restore Service: When a failure happens, how long does it take us to recover? (Shorter is better)

Tracking these numbers tells us if our process improvements are actually working. At the end of the 90 days, I report back on the plan. We celebrate our wins, learn from our misses, and create the plan for the next 90 days. The cycle begins again, but this time from a much stronger position.

When This Framework Breaks

No framework is perfect. There are situations where this deliberate 30-60-90 day approach doesn't apply.

The House is on Fire: Sometimes I walk into a true crisis. The site is down, you’re bleeding customers, or you just got a notice about a major security breach. In this scenario, the Diagnose phase is compressed from 30 days to 30 minutes. My role is to be the incident commander. We triage, stabilize, and contain the damage. The deep diagnosis has to wait until the fire is out.

The Pre-Product, Pre-Team Startup: If it’s just a founder with an idea and a slide deck, my role is different. There's no team to diagnose and no code to analyze. The 90 day plan is not about fixing process, it's about building the first version of the product. My job is to define the architecture, maybe write the first lines of code, and help the founder hire the first engineer.

Finally, the biggest downside of my approach is that it can feel slow to an anxious founder. The first month involves a lot of talking and not a lot of visible code changes. It requires a founder to trust that this deliberate approach will lead to a better, faster, and more sustainable outcome in the long run. It always does.