What a Fractional CTO Actually Does, Week by Week

Most content about fractional CTOs reads like a job description written by a committee. "Provides technical leadership." "Aligns engineering with business strategy." "Mentors development teams." It's the LinkedIn version — clean, polished, and almost completely useless if you're trying to understand what the work actually feels like on a Tuesday.

I've been doing this for a few years now. Embedded with early-stage startups, 1–2 days a week per company, owning architecture, sitting in on hiring calls, unblocking teams, and occasionally telling founders things they don't want to hear. Here's what it actually looks like.

The LinkedIn Version vs. The Reality

The LinkedIn version of a fractional CTO is basically a part-time CTO who shows up to give wise counsel, makes bold strategic calls, and leaves the team inspired and aligned. Everyone nods. Nobody argues. The roadmap is clear.

The reality is messier.

You're joining mid-flight. The codebase has decisions baked into it from before you arrived — some of them good, most of them made under pressure with incomplete information. There are three competing opinions about what the MVP should have been. The lead developer is quietly considering leaving. The founder wants to add an AI feature because they saw something on Twitter and a competitor just shipped something vaguely similar.

Your job isn't to arrive with answers. It's to get up to speed fast enough to ask the right questions, and then to hold the line on the decisions that matter while moving quickly on the ones that don't.

That's a different skill set than being a full-time CTO. It requires faster calibration, higher tolerance for ambiguity, and the ability to build trust in compressed time. It also requires letting go of the things you can't control — which, when you're only there two days a week, is most things.

What a Typical Week Actually Looks Like

I usually carry two or three companies at a time. Here's an honest account of how those days break down.

Monday

Monday morning is almost always code review. I block the first couple of hours to go through whatever shipped or was submitted for review over the weekend. This is where I earn my keep more than anywhere else — not because I'm a faster reviewer than the developers, but because I'm looking at the codebase across time and across the whole system. I'm catching patterns that are starting to drift, spotting dependencies that are about to become problems, and asking why before it becomes a postmortem.

After that, it's architecture. Not in the sense of grand diagrams in a slide deck — in the sense of sitting down with whoever owns a specific part of the system and working through a decision that's been waiting. Should we move this service to its own deployment? What happens to our current database schema when we need to add multi-tenancy? Do we need a queue here or are we over-engineering?

These conversations are the core of the job. They're not glamorous. They rarely produce a clear conclusion in the first session. But they're what separates a product that can scale from one that has to be rebuilt at the worst possible moment.

Wednesday

Wednesday is usually the people day. Hiring interviews, founder syncs, and any external calls that need technical input — a vendor evaluation, a due diligence session, a conversation with an investor who wants to understand the tech stack.

Hiring is underrated as a fractional CTO activity. Founders often don't realize how much technical judgment goes into evaluating a senior engineer or a tech lead. I review take-home assignments, join second-round calls, and give my read on whether someone's experience maps to what the team actually needs right now — not just whether they can answer algorithm questions.

The founder sync on Wednesday is non-negotiable. It's usually 45 minutes. We go through what's blocking the team, what's coming up in the next two weeks that needs a technical call, and whether anything has changed in the business that affects the technical direction. This is where I do most of my translate-technical-to-business work. The founder needs to understand trade-offs, not implementation details. I've gotten better at this over time.

Friday

Friday is async-heavy. I'm reviewing documentation, checking on anything that got shipped during the week, and writing up decisions that were made verbally earlier in the week so there's a record. Decision documentation is unglamorous but critical — when you're not there every day, written context is the only way the team can keep moving without waiting for you.

I also try to ship something on Fridays. It doesn't have to be big. A proof of concept for an architecture decision we've been debating. A small feature that's been stuck in limbo because nobody wanted to make a call. A CI configuration fix that's been annoying the team for weeks. Shipping keeps me sharp and keeps my credibility with the developers intact. The moment a CTO stops writing code, they stop understanding what's hard.

The Decisions That Actually Matter

Not all decisions are equal. Most of them don't matter much. Here are the ones that do.

Stack selection. The first major technical choice sets constraints that last for years. I push back hard on fashionable choices that don't fit the team or the problem. I've seen startups pick a trendy framework because the CTO read about it on Hacker News and spend the next eighteen months fighting it. The right stack is the one your team can move fastest in today, with a credible path to the requirements you'll have in two years.

Build vs. buy. This is the most consistently mishandled decision in early-stage startups. The default should almost always be buy or use a managed service — especially for anything that isn't your core product. Auth, payments, observability, search. If you're building those from scratch, you're burning engineering time on solved problems. The exception is when a third-party dependency creates a real strategic risk or when the economics at scale genuinely favor building. Most startups never reach that scale.

When to hire. The timing of a full-time engineering hire is a high-stakes decision with compounding consequences. Too early and you're paying full-time salaries before you have product-market fit. Too late and your velocity collapses. I'm usually the one who surfaces the hiring conversation when I start to see the team consistently hitting capacity constraints — and I'm also the one who pushes back when a founder wants to hire before the team structure is ready to absorb someone new.

When to say no. This is the most valuable thing I do and the hardest to demonstrate. Saying no to a feature request that would add three months of complexity for unclear value. Saying no to a rewrite proposed by a developer who's frustrated with legacy code but hasn't modeled what a rewrite actually costs. Saying no to an integration that a potential enterprise client wants but would only ever benefit that one client. Every no is protecting runway and focus. Founders often need someone outside the daily pressure to help them hold that line.

What I Code vs. What I Delegate

I write code. Not as much as a staff engineer, but enough to keep my judgment honest. I do spikes — exploratory implementations to validate an architectural approach before the team commits to it. I write integration tests for things that are scary to break. I prototype new technical capabilities — an LLM integration, a new data pipeline pattern, a queueing mechanism — so the team has a working reference before they build the real thing.

What I don't do: feature development that doesn't require architecture decisions, repetitive refactoring work, or anything that a developer on the team can do as well as I can with less context-switching overhead. My time is too expensive for that, and frankly, taking that work away from developers is bad for their growth.

The line I use internally: I code when the code is also a decision. If I'm writing it to prove something is possible, to set a pattern, or to unblock a conversation — that's appropriate. If I'm writing it because it needs to get done — that's usually not.

The Hardest Part: Context-Switching

Nothing I've said so far captures how cognitively expensive it is to carry multiple companies simultaneously.

Each company has its own codebase, its own team dynamics, its own set of in-flight decisions. When I finish a Wednesday afternoon session with one company and jump into a code review for another, the context switch is real and it has a cost. I've gotten better at managing it — obsessive documentation, clear end-of-session notes, distinct working folders, no shared tools across clients — but it never fully goes away.

The honest answer is that I can do this work well across two companies. Three is possible if one of them is relatively stable. Four is where the quality starts to degrade in ways that are invisible to the founder but visible to me — slower calibration, less precise feedback, decisions that are right but not quite right for the specific context. I've learned to say no to the fourth engagement. That boundary matters.

When It Works and When It Doesn't

This model works best with pre-Series A companies that have a small engineering team — typically two to five developers — and a non-technical or lightly technical founder. The founder needs senior technical judgment but doesn't yet have the budget or the traction to justify a full-time technical executive. They want someone who can own the architecture, run the hiring process for engineers, and be a genuine thinking partner on product and technical strategy. That's the sweet spot.

It also works well with companies that have a technical co-founder who is a strong builder but hasn't managed teams or made architectural decisions at scale before. In that case, I'm less a substitute CTO and more a senior sounding board — someone who has seen these decisions play out before and can help them think through options without needing to own the execution.

When it doesn't work: a company that actually needs a full-time CTO but is using a fractional arrangement to avoid making that hire. This usually shows up as a company with more than eight or ten engineers, significant technical complexity, and a pace of decision-making that requires daily presence. At that point, the fractional model is a bottleneck. You need someone in the building every day. The right thing for me to do in that situation — and I've done it — is say so and help them find the right full-time hire.

It also doesn't work if the founder isn't prepared to genuinely delegate technical decisions. I've had engagements where every call was an exercise in convincing the founder to accept a recommendation they'd already emotionally rejected. That's not technical leadership; it's expensive negotiation. Fractional CTO work requires a founder who trusts technical judgment enough to act on it.

How Engagements Start and How They End

I always start with a four-week test. Not a trial period with reduced commitment — a real engagement at full depth. I dive into the codebase, meet the team, join the standups, and start making actual decisions. The goal is to produce something tangible: an architecture review, a hiring assessment, a tech debt map with priorities. This tests whether the working relationship has the right shape before either side commits to something longer.

The exit is something I plan from the first week. My job is to make myself unnecessary. That means documenting decisions, building systems that don't depend on me to function, growing whoever on the team has the capacity to step into a technical lead role, and giving the founder a clear signal about when they're ready for a full-time hire. If I'm doing the work right, the end of an engagement should feel like a graduation, not a gap.

If this sounds like the kind of engagement you're looking for, here's what my Fractional CTO work actually looks like — embedded 1–2 days a week, owning architecture, hiring reviews, and shipping velocity.

See what this produces: Ericeira Review case study → — a full product built end-to-end, stack choices explained, and first-month numbers on the table.

Much of the week-to-week work in 2026 is picking and shipping the right AI automations for business — the research agents, outreach pipelines, and support triage workflows that replace manual hours for teams.