A fractional CTO's first 90 days: listen, map, measure, then change the few things that matter

Why the first 90 days matter more for a fractional CTO

A full-time CTO can take six months to find their feet. A fractional CTO typically works a few days a month, often alongside a founder, a head of engineering or a small team. That changes the job. There is no room for long discovery, and no point in decisions that only live in the CTO's head, because the CTO is not there most of the week. The first 90 days have to produce three things: an honest picture of where the technology stands, a small number of changes that reduce real risk, and a way of working the team can run without you. If you are still deciding whether you need one, start with when do you need a fractional CTO.

Days 1 to 30: listen and map

Listen first. Talk to the founders, every engineer, product, support and a few customers if possible. Ask the same questions each time: what slows you down, what breaks, what worries you, and what you would change first. Patterns appear quickly, and the team learns you are there to help rather than to judge.

Map the system. Draw what actually runs: services, data stores, third parties, how code reaches production and who can change what. Mark the risks: single points of failure, unpatched edges, secrets in the wrong places, data with no owner. A one-page map beats a perfect one.

Get basic visibility. If there is little monitoring, start small. The OpenTelemetry community's account of how Skyscanner runs its collectors makes the same point: start with a simple setup and evolve it gradually⁵. A gateway collector for application telemetry and an agent for infrastructure metrics is often enough to begin with; see OpenTelemetry collector patterns.

Take a baseline. Measure delivery with the four DORA measures, which track how often you deploy, how long changes take to reach production, how often changes fail and how quickly you recover¹. Add one or two reliability measures tied to what customers feel. Do not set targets yet; just record where you are. See DORA metrics with AI-assisted engineering.

Days 31 to 60: fix and decide

Close the riskiest gaps. Pick the few risks that could hurt the business most this year, usually security exposure, a fragile deployment process or missing backups, and fix them. Resist the urge to start a rewrite. Small, visible fixes build trust and buy room for bigger changes later.

Write decisions down. Every significant decision gets a short architecture decision record: the context, the decision and its consequences, in the format Michael Nygard described³. For a fractional CTO this is not paperwork; it is how decisions survive the days you are not there. See architecture decision records for fractional CTOs.

Agree reliability expectations. Decide with the founders how much unreliability is acceptable and what happens when it is exceeded. Google's SRE guidance frames this as an error budget: a shared, explicit amount of risk that balances shipping features against stability². See SLOs and error budgets for small teams.

Shape the team. Look at how work flows between people. Team Topologies offers a useful vocabulary: stream-aligned teams that own a flow of change end to end, supported by platform and enabling teams, with clear interaction modes between them⁴. Small companies rarely need the full model, but the question of who owns what end to end matters at any size; see Team Topologies for AI teams.

Days 61 to 90: plan and hand over

Write a short roadmap. One page: the next two or three quarters, the few big bets, what you will not do and why, and how progress will be measured against the baseline. Build it with the team, so it is theirs.

Set an operating rhythm. Agree what happens without you: weekly delivery review, monthly look at the measures, a regular architecture review where new decision records are discussed. Then agree what happens when you are there: the decisions and reviews that need your time.

Be explicit about ownership. List the areas the team owns fully, the ones you co-own, and the ones that still need you. The goal is for the last list to shrink every quarter.

Who does what

Common mistakes

• Starting with a rewrite. It consumes the engagement and rarely finishes. Fix the riskiest gaps first.
• Keeping decisions in your head. If it is not written down, it will be reopened the week you are away.
• Measuring everything. Four delivery measures and one or two reliability ones are enough to steer by.
• Becoming the bottleneck. If every decision waits for your next visit, you have made the company slower.
• Ignoring the business. Technology priorities that do not connect to revenue, risk or customers will not survive the next budget conversation.

How I work

This is the shape of most of my engagements, whether the company is a start-up preparing for due diligence, a scale-up whose systems are straining, or a regulated business adopting AI. I am based in India, the United States and the UAE, working globally. See how I work and fractional CTO services, or analyse your challenge and bring the result to a call.