Founders bring in a fractional CTO expecting a plan by Friday: a roadmap, a hiring list, maybe a verdict on whether to rewrite the thing everyone's been complaining about since March. Almost none of that happens in week one, and if it does, be suspicious of it. Week one is quieter than that. It's mostly reading, asking, and getting access — the unglamorous part nobody puts in the pitch deck.
Get access before opinions
The first day is logins, not strategy. GitHub, the hosting account, the CI pipeline, the error tracker, the database (read-only is fine to start), whatever ticketing system the team actually uses versus the one they're supposed to use. Half the value of this step is what it reveals before a single line of code gets read: does deploy require one command or a Slack thread with three people? Is there a staging environment, or does "testing" mean pushing to production and watching Sentry? These answers say more about the state of the engineering org than any conversation will.
Read the incidents, not the docs
Documentation tells you what the team wants to believe about the system. Incident history tells you what's actually true. Pull the last six months of outages, failed deploys, and "quick fixes" that turned into three-day fire drills. The pattern that shows up — the same service failing, the same person getting paged at 2am, the same "we'll fix it properly later" — is usually the real map of where the risk lives, and it's rarely where the loudest complaints point.
Talk to the engineers before the founder's theory of the problem
Founders usually walk in with a diagnosis already: "our backend is a mess," "we need to migrate off X," "the last CTO left things half-built." Sometimes that's right. Often it's one symptom mistaken for the whole disease. Twenty minutes each with the two or three engineers who've been there longest surfaces something different — not the official narrative, but what they actually avoid touching, and why. That's the real backlog, even if it never made it into a ticket.
Say no to the rewrite, at least for now
Every codebase a fractional CTO walks into has at least one component someone wants torn out and redone. Week one is not the time to greenlight that, no matter how bad it looks on first read. A rewrite decided before understanding why the thing was built that way — what deadline, what missing information, what tradeoff someone made under pressure — is how a second bad system gets built to replace the first one. The right week-one answer to "should we rewrite this" is almost always "not yet, and here's what I need to know before I can answer that."
Ship one small, visible fix
Trust doesn't come from a strategy doc. It comes from something the team can see working by Friday — a flaky test suite that finally passes reliably, a deploy step that used to take forty minutes now taking four, a monitoring alert that stops crying wolf. It doesn't need to be the biggest problem in the codebase. It needs to prove that things can actually get better here, because a team that's been burned by six months of promises needs evidence before it needs a plan.
What week one is actually for
By the end of it, a fractional CTO shouldn't have a finished roadmap. They should have a short, honest list: what's actually broken, what's just ugly but fine, what the team is quietly afraid to touch, and what one thing is worth fixing first. Everything after that — the hiring plan, the architecture calls, the roadmap the founder was hoping for on day one — depends entirely on getting that list right. Skip the reading and asking to get to the plan faster, and the plan ends up solving the wrong problem, confidently.