Interim CTO: When a Company Needs One and What Happens in the First 90 Days

A company doesn't usually plan for an interim CTO. The CTO resigns with six weeks' notice, or a founder who has been quietly running engineering realizes the business has outgrown what one person can hold in their head, or an acquisition closes and nobody technical is left in the room. Hiring a permanent CTO takes three to six months once you count the search, interviews and notice period. An interim CTO exists for exactly that gap: someone who can run engineering now, while the company works out what it actually needs for the long term.

When companies actually reach for an interim CTO

Four situations come up again and again. The CTO leaves and there's no obvious internal successor, so someone needs to keep releases going and give the team a steady point of contact while the search runs. A technical founder has been doing the CTO job without the title, usually because the company was small enough that it worked, until growth or a funding round means it stops working. A company gets acquired, or is partway through being acquired, and the buyer wants an independent technical read on what they're actually inheriting before and during the transition. Or a big project visibly failed, a launch broke, timelines slipped past the point of excuses, the board lost confidence in whoever was accountable, and an outside set of eyes comes in to work out what went wrong and fix it.

None of these are small decisions, and none of them are permanent ones. That's the point of hiring an interim CTO rather than rushing a full-time search: the company buys time to think clearly while someone experienced keeps things running.

The first 30 days: finding out what's true

The first month of an interim CTO engagement isn't about big changes. It's about working out what's actually going on, which is usually different from what the org chart or the last status report suggested. That means sitting down with every engineer, not just the leads, reading the deployment pipeline instead of asking someone to describe it, checking who still has production access from roles they left months ago, and looking at the real state of the codebase rather than the roadmap slide that describes it.

A few things tend to surface in week one: a security gap nobody flagged, a single person who can deploy to production and happens to be on vacation next week, or a dependency on a contractor who already left and took the only documentation with him. Fixing those doesn't wait for day 30. Everything else usually does, because changing process or structure before you understand why things are the way they are just creates a second mess on top of the first.

Days 31 to 60: building the plan, shipping a few wins

By the second month, the interim CTO should have a real picture of the team, the technology and the risk, and can start making decisions instead of only observing. This is usually when a short roadmap gets rewritten around what's actually achievable, some process changes land, a code review requirement that gets followed, a release checklist, an on-call rotation that exists somewhere other than someone's memory, and a handful of visible fixes ship so the team and the board can see movement rather than take it on faith.

It's also when hiring decisions tend to get made: sometimes to replace the person who left, sometimes to fill a gap that was always there and simply never got named until an outsider looked closely enough to notice it.

Days 61 to 90: handing over or settling in

What happens at day 90 depends on why the company brought someone in. If the goal was to cover a search for a permanent CTO, this is when that search should be close to finished, and the interim CTO shifts to documenting decisions, introducing the incoming hire to the team, and making sure nothing important depends on knowledge that only exists in one person's head. A handover that skips this step is the single most common way these engagements leave a mess behind.

If the engagement runs longer than planned, which happens more often than either side expects, the conversation usually turns to whether this becomes an ongoing fractional arrangement instead of staying full time and temporary.

Day rate against contingent billing

Most interim CTO engagements run on a day rate: a fixed daily or weekly fee for an agreed number of days per week, set for a defined term, usually three to six months with the option to extend. That's different from an hourly or contingent model, where the company pays only for hours actually worked and the engagement scales up or down from one week to the next.

Day rate billing is more common for interim CTO work because the company usually needs someone reliably present and accountable during a defined window, not someone dipping in and out as capacity allows. Hourly or contingent billing tends to fit narrower, lower-stakes advisory work better, where the company wants an opinion on something specific rather than someone running engineering day to day.

Interim CTO, fractional CTO, or interim developer

These three get confused constantly, and the confusion costs companies both money and time. An interim CTO is full time or close to it, for a fixed period, usually brought in for a specific crisis or transition, and priced for that intensity. A fractional CTO works a set number of days a month on an ongoing basis, for a company that needs senior technical judgment without a full headcount, and the engagement can run for years rather than months. We've written about how to choose between the two in our fractional CTO playbook for European startups and in a direct comparison of interim developers and fractional CTOs.

An interim developer is a different thing again: someone who writes code, reviews pull requests and ships features, rather than managing people or setting strategy. For a lot of companies that ask about an interim CTO, that's what they actually need.

Why a five-person engineering team rarely needs a CTO

A company with one to five developers usually doesn't need a CTO, interim or otherwise. What it needs is someone who can review the architecture, write code when the team gets stuck, and make a handful of technical decisions well, without the overhead of a leadership title or the cost that comes with it. Calling that role a CTO doesn't change what the work actually is, and paying CTO day rates for work that's really developer-level is a common way companies overspend during a transition.

When an interim developer beats hiring covers this trade-off in more detail, and it's worth reading before starting an interim CTO search if the team is still this size. The title on the contract should match the work that actually needs doing, not the title the company feels it should be buying.

Where this fits for Wolf-Tech clients

Most of the companies we talk to about this sit somewhere in between: too small for a full-time CTO, past the point where ad hoc technical decisions by a non-technical founder are sustainable, and not yet sure whether they need someone for 90 days or three years. We'll say plainly which situation we think a company is in before proposing anything, including when the honest answer is a fractional arrangement, a hands-on developer, or a focused tech stack review instead of a full interim CTO engagement.

If you're weighing this decision, write to hello@wolf-tech.io or have a look at wolf-tech.io. We would rather talk a company out of the wrong engagement than sell them one that doesn't fit.