Interim CTO vs VP of engineering in a startup crisis

Why founders get stuck on this hire

Founders usually start asking whether they need an interim CTO or a VP of engineering after the same week repeats itself. Dates slip. Bugs stay open. Engineers blame specs, code, or each other. The product lead can't get a clear answer. Everyone looks busy, but users still feel the mess.

At that point, "more leadership" sounds like the answer. It isn't specific enough. These are two different jobs.

One person owns technical judgment. They decide what to build, what to rebuild, and which bets are too risky. The other person makes the team work in a steady way. They reduce friction, improve planning, and get releases out on time.

The wrong hire usually fixes the loudest problem, not the real one. A strong VP of engineering can clean up planning and team habits while avoiding hard architecture calls. An interim CTO can reset technical direction while leaving a shaky team without daily management. You solve one gap and keep the other.

Stage matters more than title. Before product-market fit, most startups need fast architecture decisions, less wasted work, and a product that can still change. In early growth, team stability starts to matter just as much. Once scale hurts, both jobs matter, even if one person covers both for a short period.

If a startup has six engineers, missed launches, and a codebase nobody trusts, the first question is not seniority. It is simpler than that: is the bigger risk bad technical direction or a team that cannot deliver together?

What an interim CTO owns

An interim CTO should own the decisions that shape the next few months. When the product keeps changing, the stack feels messy, or the team has lost confidence in earlier choices, someone has to set direction and make it stick.

That does not mean redesigning everything. It means deciding what must stay stable so the team can move again. In most startups, that means the data model, service boundaries, deployment path, and a short set of engineering rules that stop churn.

A good interim CTO also decides what needs attention now and what can wait. If one billing service causes outages every week, fix that first. If an internal tool is clumsy but still works, leave it alone until revenue and delivery are back on track.

In practice, this role comes down to a few clear responsibilities:

• Choose the architecture bets the company will keep for the next stage.
• Cut or pause systems that waste time without helping customers.
• Back tech leads through tradeoffs on speed, quality, and risk.
• Tell founders what each option costs in time, money, and focus.
• Explain the technical recovery plan to investors or the board when trust has dropped.

That last point gets overlooked. When delivery slips for long enough, people stop believing broad promises. The interim CTO has to explain, in plain language, what broke, why it broke, and what recovery will actually take.

This is where the split becomes obvious. An interim CTO should make the judgment-heavy calls. They should not spend most of the week running standups, fixing reporting lines, or filling every hiring gap. In a crisis, the company needs someone who can say "keep this, cut that, fix this first" and give the team a path it can follow.

What a VP of engineering owns

A VP of engineering owns the team's ability to ship every week, not once in a while. Founders or product leaders may set goals, but the VP turns those goals into a plan with owners, dates, and tradeoffs the team can handle.

This role is usually less about long-term technical direction and more about making delivery steady again. If the architecture choices already exist, the VP makes sure the team understands them, breaks work into smaller pieces, and gets releases out without constant drama.

The work is practical. A VP of engineering sets planning cadence, clears up handoffs between product, design, engineering, and QA, supports managers, handles hiring plans and performance feedback, and gives the company release forecasts people can trust.

A good VP also spots when the problem is not code at all. Maybe one manager avoids hard conversations. Maybe two senior engineers keep fighting over priorities. Maybe half the team works on urgent requests with no owner. Delivery slips because the operating rhythm is broken. The VP fixes that first.

This role should lower stress, too. Engineers should know what matters this week, who approves scope changes, and what can wait. That sounds basic. Many troubled startups still don't have it.

Picture a team of eight engineers missing every promised release. A good VP does not start with a grand reorg. They cut active work in half, assign one owner per project, set a release rhythm, and ask managers to surface risks before the deadline slips. Within a month, the team may ship less overall but finish more of what it starts.

The VP also has to push back on fake certainty. If a founder asks for three major features in two weeks, the answer should be a real capacity view, not wishful thinking. Predictable dates beat aggressive dates nobody believes.

If the company already knows what it wants to build but the team cannot deliver it calmly and consistently, a VP of engineering is usually the right hire.

Before product-market fit

Before product-market fit, an interim CTO usually makes more sense than a VP of engineering. The company is still learning what customers want, what they will pay for, and which parts of the product matter. Technical decisions should support fast learning, not polished structure.

That usually means one person needs to own technical choices with a short time horizon. Pick tools the team can ship with now. Keep the stack simple. Avoid big rebuilds, heavy platform work, and long arguments about scale that may never arrive.

A VP of engineering starts to help when there is already a real team to manage. If the startup has six to ten engineers, multiple workstreams, and coordination problems, that can be the right move. If there are only two or three builders and the founder still reviews most product decisions, a VP often adds a layer the company does not need.

At this stage, founders should stay close to scope, cash burn, and customer feedback. If users keep asking for faster setup, fix setup before building internal dashboards or cleaner deployment flows. Nice process can wait. Learning what drives demand cannot.

An interim CTO should also protect the team from work that sounds smart but teaches nothing. Most pre-fit startups do not need formal planning rituals, deep org charts, or architecture designed for a future team. A simple backlog, direct customer notes, and weekly releases are usually enough.

A fractional CTO can work well here. The job is to make architecture calls, cut wasted work, and keep delivery tight while the founder stays close to users. Later, when the company grows into a larger engineering organization, a VP of engineering starts to make more sense.

Early growth

Early growth changes the pressure. The team is no longer just building new features. It also has to protect a product that real customers already depend on.

At this stage, a VP of engineering should usually take over the delivery rhythm. That means planning weekly work, making sure managers run one-on-ones, catching blocked teams early, and keeping dates honest. A good VP turns chaotic shipping into a routine the team can trust.

The interim CTO still owns the bigger technical calls. Should the team keep patching the current backend or replace one weak part now? How much tech debt can the company carry for the next two quarters? Which outages point to a real platform problem, and which ones are noise? Those choices shape cost, speed, and hiring later.

One habit helps fast: separate repair work from roadmap work. If bug fixes, infrastructure cleanup, and new features all fight in one pile, feature work usually wins until production breaks. Give repair work its own lane, a fixed share of engineering time, and a clear owner.

A startup with ten engineers might keep one squad focused on roadmap items and reserve part of another squad's week for reliability, tooling, and cleanup. It feels slower at first. It usually prevents a much bigger slowdown a month later.

A few operating rules can calm things down quickly:

• Put one person on call for each shift and name a backup ahead of time.
• Set a review time limit so pull requests do not sit for days.
• Release on a schedule instead of shipping whenever someone feels ready.
• When production breaks, fix it first and create the follow-up task the same day.

In early growth, many startups need both jobs with clear boundaries. The VP keeps delivery steady. The interim CTO decides which shortcuts are still acceptable and which ones now cost too much.

When scale starts to hurt

Scale changes the work again. Early on, one person can bounce between product, hiring, incidents, and architecture. As the team grows, that stops working.

At this stage, a VP of engineering and a CTO should not share the same decisions. If they do, teams wait, priorities drift, and recovery slows down.

The VP of engineering usually owns the machine that ships work: team design, staffing, planning, and the weekly rhythm of delivery. If one squad keeps missing deadlines, another is burning out, and support tickets keep piling up, the VP fixes the structure first.

The CTO should make fewer decisions, but those decisions should carry more weight. This role sets the hard-to-reverse bets: platform direction, security model, data boundaries, integration patterns, and reliability rules.

A simple split works well. The VP owns team shape, hiring order, delivery plans, and manager expectations. The CTO decides where the system needs simplification, what gets rebuilt, and what technical risk the company will accept. Platform, security, and data ownership should all be explicit. If nobody owns them, every urgent issue turns into a group debate.

Recovery work also needs a business scorecard. Tie every large engineering task to one of three outcomes: protected revenue, better uptime, or lower support load. If a project does none of those, it can wait.

A common example is a startup with 25 engineers, slowing releases, and larger customers complaining about outages. The VP reorganizes teams, cuts planning noise, and fills the biggest staffing gap. The CTO simplifies the deployment path, reduces data coupling, and tightens security ownership. Fewer overlapping decisions usually means faster recovery.

How to decide in one week

You do not need a month-long search committee to make this call. A week is enough if you look at recent damage instead of job titles.

Start with the last five misses from the past two or three months. Use real events: a missed release, a painful outage, a senior engineer quitting, a rewrite that went nowhere, or a roadmap promise that slipped twice. Those tell you more than any interview scorecard.

For each miss, label the main cause:

• Architecture: bad technical choices, fragile systems, unclear direction
• Management: weak planning, poor follow-through, team conflict, no accountability
• Product scope: priorities kept changing or too much work entered the sprint

This is where many founders get tripped up. They ask whether they need an interim CTO or a VP of engineering when the real problem is product churn. If four of the last five misses came from changing priorities, neither hire will help much until product rules get tighter.

Then check trust inside the team. When a hard call lands on the table, who do people already look to? If engineers need someone to settle architecture decisions, stop rewrites, and cut dead code paths, you need an interim CTO. If the team needs steadier planning, clearer ownership, and better follow-through, you need a VP of engineering.

After that, write one 30-day recovery goal and give it one owner. Keep it narrow. "Restore weekly releases without rollback" is useful. "Fix engineering" is not.

The test is simple. If the biggest gap is technical judgment, hire the interim CTO first. If the biggest gap is team stability and delivery rhythm, hire the VP of engineering first.

Do not hire for the org chart you hope to have next year. Hire the person who can stop the current loss in the next 30 days.

A simple recovery example

A SaaS startup has 14 engineers, missed two releases in a row, and just lost a tech lead. Sales is waiting on a feature tied to renewals, but the team keeps reopening old code because nobody trusts the current design. Every sprint starts with a plan and ends with extra work.

The founder is dealing with two different problems. The codebase needs fewer rewrites and better technical choices. The team also needs steadier planning, clearer ownership, and meetings that end with decisions.

If technical risk is the main pain, an interim CTO should spend the first month on triage. They trace the parts of the product that keep breaking delivery, cut risky architecture work, freeze low-value rewrites, and decide what must ship now versus what can wait. They should also review system ownership, because losing one tech lead often leaves several areas without a clear owner.

If team execution is the bigger problem, a VP of engineering starts somewhere else. They work with managers, reset planning, shorten meetings, and add simple delivery rules the team can follow every week. In week one, they care less about redesigning systems and more about making the next release predictable.

The choice gets clearer if you frame it in revenue terms. If one delayed feature may cost renewals because the current stack keeps forcing rework, fix architecture first. If the feature is already clear but nobody can move it across the line after the tech lead left, fix delivery management first.

Mistakes that slow recovery

Most startup recoveries stall for ordinary reasons. Founders hire a title that looks good in an investor update instead of hiring the person who can fix the mess in front of them.

Another common mistake is giving one hire an impossible brief. No single person will clean up the codebase, reset the roadmap, calm the team, recruit replacements, and fix product strategy in the first week. One leader can drive the turnaround, but only with a clear first mandate.

Big redesigns also waste time when delivery is already late. A startup in trouble rarely needs a grand rebuild on day one. It needs fewer fires, fewer blockers, and a path to ship again. Fix the worst bottlenecks first. Cut low-value work. Make only the technical changes that support near-term delivery.

Process can become a distraction too. Founders add status meetings, approval steps, and reporting layers because they want more control. That does not solve fuzzy ownership. Decide who makes architecture calls, who runs delivery, and who sets product priorities before adding more ceremony.

Weak managers slow recovery more than most founders want to admit. Keeping them feels safer than replacing them, especially when morale is fragile. The team usually already knows where the weak spots are. If a manager avoids hard calls, protects confusion, or cannot earn trust, recovery drags on.

A startup gets out of trouble when leadership cuts scope, restores accountability, and ships something useful again within weeks, not quarters.

A short hiring checklist

A bad hire in a crisis costs more than salary. It often costs another quarter of delay, more team stress, and one more round of founder second-guessing.

Before you open a search, check five things:

• Where do the hardest calls sit right now: system design or team execution?
• Why do deadlines keep moving: changing scope, bad architecture, or weak follow-through?
• Can your current leads run planning and reviews without the founder stepping in?
• What caused the last few outages or failed releases?
• Who owns days 1 through 30 after the hire starts?

One pattern shows up again and again. If a startup has good engineers but no clear technical map, bring in an interim CTO first. If the architecture is decent and the team still misses every date, hire the VP of engineering first.

What to do next

A startup in trouble does not need more debate. It needs named owners, a short time frame, and a few numbers everyone agrees to watch.

For the next 30 days, pick one person to own architecture calls. That person can ask for input, but they make the final decision on stack changes, rewrites, technical debt, and system boundaries. If nobody owns that, every hard choice becomes a meeting.

Pick one person to own delivery recovery over the same period. This person sets scope, removes blockers, and decides what ships now versus later. Teams get stuck when both roles touch delivery but nobody clearly drives it.

Track only three numbers at first:

• release dates met or missed
• incident count
• team churn

Those three numbers tell you plenty. If release dates keep slipping, the plan is still too big. If incidents rise, architecture or process is still unstable. If people start leaving, the problem is bigger than sprint planning.

If founders and leads still disagree after a few days, bring in an outside review. A fresh operator can look at the org chart, codebase shape, delivery plan, and team stress without getting pulled into old arguments. Oleg Sotnikov at oleg.is does this kind of Fractional CTO and startup advisory work, which can help separate architecture problems from management problems before a company loses another month.

The goal is simple: decide who owns technical judgment, who owns delivery, and what has to improve in the next 30 days. That is usually enough to tell you which hire comes first.