Guides

Interim CTO Checklist: First 30/60/90 Days

April 29, 2026 | 9 min read

Interim CTOFractional CTOTech LeadershipScaling BusinessesEngineering ManagementCTO

The brief is usually short and the timeline is short with it. The founding CTO has just left, or the company has raised a Series B and the board wants senior technology leadership before the next funding round, or an acquired business needs someone to run its tech function while the parent decides what to do with it. The phone call is some version of: we need a senior pair of hands, we need them now, and we need them to know what they are doing.

This is the brief I have walked into more than once. What follows is the checklist I use — the actual one, not a polished consultant version — for the first ninety days of an interim CTO engagement at a UK mid-market scale-up. It is written for founders and chairs deciding whether to bring an interim in, and for the interim themselves on day one looking for a sane structure to work from.

Why the 30/60/90 Cadence Works for Interim Engagements

The 30/60/90 split is a cliché in management writing, but for interim work it is genuinely the right structure. Each phase has a different objective, and trying to compress them — landing on day one with a reorg plan, for instance — tends to produce worse outcomes than the boring sequence.

Days 1–30: assess. The job is to understand the business, the team, the stack, and the commitments. Almost no decisions get made. The interim earns the right to lead by demonstrating they understand what they are leading.
Days 31–60: align. The job is to take the assessment, share it with the board and the team, and build a plan everyone can commit to. The two or three obviously broken things get fixed in this window because they are blocking everything else.
Days 61–90: deliver. The job is to install durable changes — hiring, architecture, cadence, succession — so the function works without the interim being in the room. Exit prep starts here, not in week eleven.

The discipline is in the order. An interim who jumps to delivery on day one delivers the wrong thing well. An interim who never leaves assessment delivers nothing.

Days 1–30: Assess Without Acting

The first month is mostly listening. The temptation to act is enormous — boards want to see momentum, engineers want to know who their new boss is, the founder wants reassurance they made the right call. Resisting that pressure is the single most important thing the interim does in this window.

The 1:1 sweep

In the first two weeks, every member of the engineering team gets a 30-minute 1:1. For teams over thirty people, the interim runs 1:1s with all team leads and a representative cross-section of engineers. Three questions, asked the same way every time:

What is working well that I should protect?
What is broken that I should fix?
What would you do if you had my job?

The answers compound. Patterns emerge by the end of the first week — the same architectural complaint from four engineers across two teams is real; a single complaint from one engineer is signal but not yet truth. By the end of week two the interim has a working map of the engineering organisation that no spreadsheet would have produced.

Stakeholder interviews

Outside of engineering, the interim runs equivalent 1:1s with the CEO, COO, CFO, CRO, head of product, head of customer success, and any board director who is technical. The questions adapt:

What are you counting on engineering to deliver this year?
Where has engineering let you down before?
What does success look like for your relationship with the next CTO?

These conversations expose the gap between what engineering thinks it is delivering and what the rest of the business needs. They also surface the political fault lines an interim has to navigate to be effective.

Stack and codebase audit

In parallel, the interim runs a structured audit of the technical estate. This is not an exhaustive code review — it is a focused technical due diligence pass on the same dimensions a buyer would check: architecture, infrastructure, security posture, data, observability, technical debt, key-person risk, third-party dependencies, and licence compliance. Two days with the senior engineers, walking through the system, produces a credible enough picture to plan from.

Numbers that matter

By the end of day 30, the interim should have hard numbers on:

Engineering headcount, structure, attrition over twelve months, and open roles
Burn rate of the engineering function and what proportion is people vs vendors vs cloud
Delivery cadence for the last two quarters — what shipped, what slipped, why
Outstanding board, customer, and contractual commitments tied to engineering output
Top five risks ranked by impact (key-person, security, scaling, vendor, regulatory)

The artefact at the end of the month is a written assessment, eight to fifteen pages, shared with the CEO and the board. It says what is working, what is broken, what the priorities are, and what the next sixty days look like. Writing it forces clarity. Sharing it gets buy-in.

Days 31–60: Align and Stabilise

The second month is when the interim earns their fee. The assessment becomes a plan, the plan gets sold internally, and the obviously broken things get fixed.

Build the plan, then sell it

The 60-day artefact is a written technology plan covering the next six to twelve months: priorities, hiring plan, architectural direction, key initiatives with owners and timelines, risks and mitigations, success metrics. It builds directly on the day-30 assessment and turns observation into commitment.

The plan only works if the team owns it. The interim takes the draft to engineering leads, works through their objections, and incorporates the version they will defend. Teams sabotage plans imposed on them — quietly, by missing dates and blaming circumstances. They deliver plans they helped write.

The same plan, in a board-readable format, goes to the CEO and chair. The interim should leave that conversation with explicit support for the priorities, the hiring plan, and the budget implied. Without that support the rest of the engagement is theatre.

Fix the two or three things that are obviously broken

Every interim engagement reveals two or three things that are clearly wrong and have been left alone because the previous regime did not have the political capital to fix them. These are the interim’s gift — they can be fixed quickly, they create visible momentum, and the political cost lands on the interim who is leaving anyway.

Common candidates:

A vendor relationship that is bleeding money for no return — renegotiate or terminate
A team structure that has the wrong person managing the wrong group — restructure with care
A piece of infrastructure that is one outage away from a serious incident — invest the engineering time to harden it
A senior engineer who is destroying team morale — performance manage or part ways
A project that everyone knows is failing but no-one is willing to kill — kill it cleanly

The interim should pick two or three, fix them properly, and not try to fix everything. Triaging fast, fixing well, and resisting the urge to do more is the discipline.

Establish delivery cadence

By day 60 the engineering function should be running on a visible delivery cadence — weekly engineering review, biweekly product-engineering sync, monthly board-readable dashboard. This is not new process for its own sake; it is the visible signal to the rest of the business that engineering is being run.

If the team has good cadence already, the interim leaves it alone. If it is missing, the interim installs the lightest version that works and refines from there. Heavy process introduced by an interim rarely survives them.

Days 61–90: Deliver and Hand Over

The final month is about installing durable changes and preparing the handover. By day 90 the engagement has either been extended, the permanent CTO is being onboarded, or the senior engineering leader internally is being set up to step into the role.

Hiring decisions

Senior hiring takes 60–120 days for a UK scale-up. If the team needs a head of platform, a head of engineering, or a permanent CTO successor, the interim should have started the search by day 30 — by day 60 the shortlist is forming, and by day 90 offers are landing. Interims who wait until day 60 to start hiring miss the window.

The interim runs the hiring process directly: writing the role spec, sourcing through their network, interviewing at the senior level, making the offer. This is one of the highest-value things an interim does — they have the credibility to attract senior talent that a junior internal hiring process would not, and they make better senior hiring calls than the founder typically does.

Architectural direction

By day 90 the team should be aligned on the architectural direction for the next twelve months — the platform decisions that have been pending get made, the technical-debt items that are blocking delivery have a plan, and the position on key vendor and platform questions is documented. The interim does not do all the work — they make the calls and get them written down so the successor can execute against them.

The successor plan

The hardest part of an interim engagement is leaving cleanly. The interim should have spent the full 90 days identifying who runs the function next — either externally hired or internally promoted — and the last 30 days handing over to them. By the end of the engagement, the successor should be running the operational rhythm with the interim observing, not the other way round.

If the successor is not yet identified by day 90, the engagement gets extended in a defined way (usually another 60 days) with the explicit goal of completing the succession. Open-ended interim engagements without succession criteria turn into expensive permanent placements that are still labelled interim.

Common Pitfalls

Five patterns that derail interim CTO engagements, drawn from engagements I have run and conversations with peers who run them:

Acting before assessing. The interim makes structural changes in the first two weeks based on what the founder told them in the brief. The team reads it as a stitch-up and stops trusting the interim. Recovery from this is harder than starting again.
Treating the engagement like a permanent role. The interim falls in love with the company, loses sight of the exit, and ends up running the function for two years without a succession plan. The board ends up dependent on the interim, who is not committed to the company long-term.
Refusing to make hard calls. The interim is liked by the team, avoids the painful decisions on people, projects, or vendors that the previous CTO also avoided, and leaves the same problems for the successor. The engagement was a placeholder, not a transition.
Over-investing in process. The interim installs heavy reporting, ceremony, and tooling because it shows visible activity, then leaves and the team reverts. Process should be the lightest version that works; anything more dies on contact with the successor.
Skipping the board relationship. The interim runs the engineering function well but never builds a relationship with the chair or the lead investor. When the conversation about the permanent hire happens, the interim has no voice in it, and the appointment is made without their input.

When You Need an Interim CTO

Bringing in an interim is the right call when at least two of the following are true:

The previous CTO has just left and the role cannot stay empty for the six to nine months a permanent search will take
A funding round, acquisition, or major customer commitment requires senior tech credibility now
The engineering function is stalled and needs an outside perspective with the authority to make changes
The board is unsure what the permanent CTO role should look like and wants someone to define it before hiring
A permanent CTO has been hired but cannot start for several months

If only one of those is true, lighter options often fit better. A fractional CTO arrangement can stabilise a function without the cost or disruption of a full-time interim. A short technical advisory engagement can answer specific questions without taking ownership of the role. We cover the trade-offs in when to hire vs fractionally borrow a startup CTO.

For a London-based scale-up considering an interim CTO London engagement, the practical first step is a conversation about whether interim is genuinely the right shape, or whether something lighter fits the situation. The wrong shape costs more than the wrong individual.

Getting Help

We run interim and fractional CTO services for UK scale-ups in the £10–100m revenue range, typically through transitions like founder-CTO exits, post-funding scaling, and acquisition integrations. If you are weighing an interim engagement and want to test the brief before committing, get in touch. The early conversation is usually more useful than any framework.

Frequently asked questions

What does an interim CTO actually do? +

An interim CTO is a senior technology leader brought in for a defined period — typically three to twelve months — to run engineering during a transition. Common scenarios include the founding CTO leaving, a fundraise that needs senior tech credibility, an acquisition or carve-out, a stalled engineering team that needs reset, or a permanent CTO search that will take six to nine months. The interim runs the function as if they were the permanent CTO, makes the calls a permanent CTO would make, and builds the foundations a successor can inherit.

How is an interim CTO different from a fractional CTO? +

An interim CTO is full-time and time-bounded — they own the role for a defined period and step out when the transition is complete or the permanent hire arrives. A fractional CTO is part-time and ongoing — typically one or two days a week, sustained for as long as the business needs senior input without a full-time hire. Interims solve transitions; fractionals solve perpetual capacity gaps. We cover the distinction in detail in our [fractional vs interim vs CTO-as-a-service guide](/insights/fractional-cto-vs-interim-cto-vs-cto-as-a-service).

How long should an interim CTO engagement last? +

Three to nine months is the normal range. Shorter than three months is rarely useful — the first thirty days are spent on assessment, and there is no time to install durable changes. Longer than nine months tends to mean the business is using the interim as a substitute for hiring a permanent CTO, which creates dependency and slows the permanent search. The interim should arrive with a defined exit and a written plan for what success looks like by the end.

What does an interim CTO cost? +

UK interim CTO day rates in 2026 sit between £1,200 and £2,500 depending on stack, sector, and seniority. A full-time interim engagement is typically structured as a fixed monthly fee, often £20,000 to £40,000 per month, with the rate depending on whether the interim is also providing a small support team. Compared to the cost of a wrong permanent hire — usually £200,000 to £400,000 in salary, recruitment, ramp-up, and exit cost — an interim is normally the cheaper option even before counting the operational risk avoided.

When should a scaling business bring in an interim CTO instead of hiring permanent? +

Bring in an interim when the role is genuinely transitional — you need senior leadership now but the permanent hire is six to nine months away, or you want the interim to define the role before you hire. Hire permanent when the business is stable, the role is clear, and you are ready for someone to commit to the company for years. The mistake to avoid is hiring permanent in panic mode after a CTO exit; you tend to over-index on whoever is available rather than the right long-term fit. An interim buys you time to hire well.

Should the interim CTO write code? +

Sometimes, sparingly. The interim's value is judgement, not output — if they are absorbed in the codebase they cannot do the role. That said, an interim who never reads code or pairs with engineers loses credibility with the team and misses signals about real architecture problems. The realistic balance: the interim spends most of their time on people, roadmap, and stakeholders, but stays close enough to the technical detail to spot when something is wrong and to coach engineers through hard problems.

What does success look like for an interim CTO engagement? +

Three things, measured at the end of the engagement: the engineering team is stable or stronger than at day one (no avoidable churn, key people retained, gaps filled or hiring in motion), the technical roadmap is credible and delivering against commitments to the board and customers, and there is a successor plan — either a permanent hire identified or the senior engineering leader internally promoted with the support to take the role. If those three are in place, the interim has done their job.

What is the biggest mistake interim CTOs make in their first 30 days? +

Acting too fast. The pressure to demonstrate value early pushes interims to make visible changes — restructuring teams, killing projects, swapping vendors — before they understand the business. The damage is rarely the change itself; it is the loss of trust. Engineers stop telling you what is really going on because they assume the next change is coming for them. The right move in the first thirty days is to listen actively, map the situation, and earn the right to make changes by showing you understand what you are touching.

Want the Fractional CTO Playbook?

Download the playbook we use for this. Free, no credit card.

Get the playbook