The first 90 days of a fractional CTO engagement is not a solutions phase. It is a discovery phase. Most of what an incoming technology leader needs to know cannot be learned from a data room, a technology inventory spreadsheet, or a briefing from the outgoing engineer. It has to be discovered in the work — through the architecture diagrams that don’t match the actual codebase, the vendor contracts that no longer reflect actual usage, and the team dynamics that don’t appear on an org chart.
That discovery process has a structure. Understanding it in advance helps organizations calibrate their expectations and get more out of the engagement.
timeline
title Fractional CTO Engagement — First 90 Days
Days 1-30 : Access and inventory
: Architecture vs. production reality
: Deferred decisions mapped
Days 30-60 : Stuck decisions closed
: Vendor accountability established
: Quick wins documented
Days 60-90 : Operating rhythm installed
: Technology roadmap drafted
: Board reporting cadence set
Days 1–30: Map What’s Real, Not What’s Documented
The first month is about building an accurate picture of the technology landscape as it actually exists — not as it’s described in onboarding materials or presented in the leadership briefing.
The gap between documented state and production reality is almost always larger than anyone on the leadership team realizes. Systems that are “99% done” are often 70% done with the hardest 30% still outstanding. Architecture diagrams describe the system as designed, not as modified over two years of feature development and deadline-driven shortcuts. Vendor contracts often reflect agreements signed under different assumptions — different usage volumes, different capability requirements, different team sizes. The engineers closest to the codebase know all of this. The executives managing them usually don’t.
The fractional CTO’s first job is to close that gap. That requires access: direct access to the codebase, direct conversations with engineers without managers in the room, and direct review of vendor agreements rather than summaries of them. The things that actually shape the technology strategy — the real technical debt, the deferred architectural decisions, the engineers who are quietly carrying systems that nobody else understands — are not in the slides.
The most important output of the first 30 days is an accurate AS-IS map. It’s also the output that most often surprises clients, because the real picture is almost always more complex, more expensive to remediate, and more urgent than the picture they were working with.
Days 30–60: Close the Stuck Decisions
Every technology organization has decisions that should have been made months or years ago but weren’t. Which vendor to stay with and which to exit. Whether to rebuild a core system or extend its life with APIs. How to structure the engineering team as the company has grown past the size where the original team design still made sense.
These decisions didn’t get made because they are hard, politically sensitive, or require trade-offs that no one wanted to be accountable for. The fractional CTO’s job in this phase is to force them — to gather the relevant information, lay out the trade-offs clearly, make a recommendation, and drive it to a decision. Not to deliberate indefinitely, not to schedule another review, but to close it.
At Oakwood Worldwide — the largest corporate housing company in the United States at the time, with more than 80 applications across global locations — the challenge was exactly this. The organization had deep integration complexity: tightly coupled systems where moving data from one application to another required navigating dependencies that had accumulated over years. Progress had been blocked not by technical difficulty but by the absence of a consistent driving force with the authority and organizational standing to push decisions through. Once that force was in place, the integration enhancements that had been stalled for quarters began moving. The consistent driving force is the function. The decisions follow from it.
Quick wins matter in this phase too — not because they’re the most strategically important actions, but because they build credibility. A vendor contract renegotiated, a deployment bottleneck cleared, a technical debt item resolved that the team had been working around for a year: these are visible, concrete, and they demonstrate that the engagement is producing results.
Days 60–90: Install the Operating Rhythm
The third phase is about making the engagement’s impact durable — not just in the decisions made and the technical progress delivered, but in the organizational infrastructure that keeps decisions getting made after the engagement evolves.
An operating rhythm means a defined cadence for technology reporting to the executive team or board: not ad-hoc updates when something goes wrong, but a regular review of technology program status, key metrics, and the current risk register. It means a process for technical decision-making that doesn’t require CEO involvement for every significant choice. It means a technology roadmap that executives can actually plan against — not a wish list, but a prioritized sequence of investments with realistic timelines and explicit trade-off reasoning.
By the end of 90 days, the organization should have a clear view of the next 12 months of technology investment, a governance structure for AI and technology decisions, and a way to hold the engineering team accountable that doesn’t depend on the fractional CTO being in the room.
What the Organization Should Expect at 90 Days
The clearest signal that the first 90 days have worked is that the executive team is no longer operating on an optimistic fiction about the technology organization. They know what they actually have — the real capability, the real debt, the real vendor dependencies, the real critical path. From there, decisions get made differently: more honestly, more concretely, with a clearer view of what’s actually possible in the next 12 months.
That’s not a glamorous outcome. But it’s the foundation everything else rests on.
