CEO and CTO split ownership in a hard company turnaround

Why this gets messy fast

Turnarounds usually fail at the ownership line, not the effort line. The CEO sees runway shrinking and cuts spend. The CTO sees product debt, fragile systems, and customer promises, then keeps pushing work that still feels necessary. Both views can be right. That's why things get messy fast.

The team doesn't hear nuance. It hears two leaders working on two clocks. One says, "Stop spending." The other says, "We still need this release." People slow down because any choice can look wrong two days later.

It gets worse when support issues pile up. A customer is angry about bugs. Sales wants a promised feature before renewal talks. Engineering knows the code is fragile and one rushed change could make the outage worse. If nobody says which pain matters most, every queue starts to look urgent.

Then the company starts burning time instead of cash. Meetings get longer. Decisions bounce between leadership calls, Slack threads, and late night messages. Work starts, stops, and starts again for a different reason.

Turnarounds also strip away the usual buffer. There is less money, less patience, and fewer spare people. One resignation can break the plan. One bad deploy can wipe out a week.

The hardest part is simpler than people admit: nobody names who breaks ties. The CEO often assumes cash gives final say. The CTO often assumes technical risk does. Product or operations tries to smooth it over, but that usually delays the call instead of making it.

When the company does not define the split, the team invents its own version. That is when stalls, mixed priorities, and avoidable fights show up fast.

Pick one turnaround target first

Turnarounds usually fail when a company tries to fix cash, product, hiring, and tech debt at the same time. People work hard, but they pull in different directions. For the next 90 days, pick one target that beats the others.

That target needs one number. Not five. One. If runway is getting tight, the number might be monthly burn. If sales are still healthy but customers keep leaving, it might be retention. If delivery is broken, it might be release time or failed deployments.

Once that number is clear, arguments get shorter. Tradeoffs get cleaner. Everyone can test a decision against the same goal.

A good rule is simple: pick the target that keeps the company alive long enough to fix the next problem. In many rough turnarounds, that means cash first. Sometimes it means keeping one product line stable so customers do not leave. Growth can wait if the floor is collapsing.

Write the target on one page: the one number that matters for the next 90 days, the current baseline, the goal by day 90, the work that stops now, and the day each week when progress gets reviewed.

The stop list matters more than most teams expect. If you do not say what stops, old priorities creep back in. That usually means side projects, low value features, long hiring plans, and technical cleanup that does not move the number.

Set one fixed review day each week. Same day, same people, same metric. If the number is not moving after two or three reviews, change the plan fast. Do not wait for a neat quarter end story. In a turnaround, speed beats elegance.

Who owns cash calls

When money gets tight, shared control turns into confusion. The CEO should own the cash outcome. That means setting the runway target, the spending cap, and the date the company must reach it by. If the business needs eight more months of runway, the CEO should say that plainly.

The CTO owns the cost math behind technical work. That includes infrastructure, software tools, contractors, delivery effort, and the real cost of keeping the product stable. A good CTO should not stop at, "This costs $12,000 a month." The CTO should also explain what breaks if that number drops to $8,000.

That split matters because many cuts look cheap on paper and get expensive a month later. Canceling a monitoring tool, shrinking test coverage, or delaying a database upgrade may save cash now, but it can also raise outage risk or slow releases. The CTO needs to flag that risk early, in plain language, with a rough cost if things go wrong.

The CEO still makes the company call on hiring, vendor cuts, payment timing, and any freeze on new work. Those choices affect survival, morale, and investor trust, so the CEO decides after hearing the tradeoffs.

Say the CEO wants to cut cloud spend by 35% in 30 days. The CTO might come back with two options: save 20% with low risk, or save 35% by removing redundancy and slowing deployments. Now the tradeoff is visible. The CEO can choose with open eyes.

Name one person for the final cash call. In most turnarounds, that is the CEO. If the CTO can overrule one narrow area, such as security or uptime protection, write that exception down. Do not leave it vague.

Who owns roadmap calls

In a turnaround, the CEO owns the order of bets. That means deciding which customers matter most right now, which revenue goal comes first, and what the company needs the product to do next. If the business needs renewals more than new sales, the roadmap should show that clearly.

The CTO owns a different part of the same decision. The CTO decides whether the team can ship that plan without breaking the product, burning out the team, or taking on risk that will land a month later. A roadmap is not real if the team cannot deliver it safely.

This is where the split often breaks down. A CEO can cut scope to hit a date. That is fair. But shortcuts still need names. If a release drops testing, delays a migration, or leaves a security gap, say it out loud.

The CTO also needs real authority. If a request puts uptime, data integrity, or the product's core behavior at risk, the CTO can reject it. That is not resistance. It is the job. A good CTO does not say "no" to protect pride. The CTO says "no" when the product could fail in a way the company cannot afford.

Each week, review any roadmap change with four blunt questions: what customer or revenue goal it supports, what got cut to make room, what risk was accepted and who approved it, and whether the team can ship it with the current people and timeline.

Picture a small SaaS company with six months of runway. The CEO may decide that enterprise renewals come before a new self service feature. The CTO may agree, but still reject a rushed release that skips access control fixes. That split works because each person owns a different call, and neither one hides the cost.

Who owns staffing moves

The CEO decides the headcount limit and the timing. If the company can only carry 18 salaries for the next four months, that line belongs to the CEO. Staffing starts as a cash decision.

The CTO decides which people the company cannot lose without hurting uptime, delivery, or both. That usually includes the engineer who knows the billing mess, the person who can ship customer fixes fast, and the operator who keeps production calm when things go wrong. Those calls belong to the CTO because they depend on system knowledge, not org charts.

Teams get into trouble when they cut people before they cut work. If three projects are late, one is noisy, and none of them help cash soon, stop or pause the projects first. Keep the people who hold fragile system knowledge until the systems are safer and easier to hand over.

A useful rule in a turnaround is to move your strongest builders onto work that protects cash now. That often means fixing product issues that block renewals or sales, improving support for paying customers, repairing internal tools that waste hours every week, and reducing outages, failed deploys, and slow incident response.

This can feel unfair to teams that were building new features last month. It is still the right move. In a rough quarter, repair work and revenue work beat nice to have roadmap work.

Managers also need clear authority. The CEO and CTO should tell them, in plain words, who can reassign people today, who must approve exceptions, and which teams are frozen. If managers wait for permission on every move, the company burns time it does not have.

One workable split is simple: the CEO sets the people budget, the CTO ranks who protects the business, and managers execute the moves that same week. That keeps staffing tied to cash without breaking the systems that still have to run.

Who owns technical risk

Technical risk starts with the CTO, but it does not end there. The CTO names the risks, explains them in plain language, and keeps the list short enough that the CEO can use it. If the list has 27 items, it is useless. A turnaround needs a live page or simple document with the current risks, what each one could break, and how soon it could hurt the business.

The CEO owns the business pain threshold. That means deciding how much delay, downtime, or product limitation the company can carry while it tries to stay alive. The CTO should not guess that number. A two hour outage might be annoying in one company and fatal in another.

Some risks sound scary but can wait. Others look boring and can stop sales next week. Put anything that could cut revenue soon, break customer trust, or stop delivery at the top of the list. Keep lower impact issues on a watch list. If the company accepts a risk for now, write that down with a review date.

That part matters more than most teams admit. If you choose to live with an old database, thin test coverage, or a manual release step for 60 days, write it down. Then nobody can claim the risk was invisible when it bites later.

A good CTO will usually want to fix more than the company can afford. That is normal. The CEO should ask one hard question: which two or three issues could damage trust or block sales if we do nothing? Fix those first. Everything else needs a date, a monitor, or an explicit decision to live with it for now.

Set the split in one week

A messy turnaround gets worse when the same argument repeats in three meetings and still ends with no clear owner. Fix that first. You do not need a big reorg. You need five working days, one shared document, and two people willing to make the split explicit.

On day one, write down the decisions that keep turning into fights. Be plain about them. "Cut this vendor or keep paying?" "Delay this feature?" "Freeze hiring?" "Ship with known risk?" If a decision keeps coming back, it belongs on the list.

On day two, sort every item into four buckets: cash, roadmap, staffing, and technical risk. Keep the buckets simple. If a topic touches two buckets, put it where the final call should live.

Day three is where most teams wobble. Assign one owner and one reviewer to each bucket. One owner means one person makes the call after hearing input. One reviewer means the other leader gets a real chance to challenge it before execution. If both people "own" the same bucket, the old fight comes back.

On day four, test the split on a real decision that already feels uncomfortable. Do not use a fake scenario. Use something live, like whether to cut a contractor, delay a release, or keep funding a shaky project. You will spot blurry rules fast.

Day five, tell the full leadership team how this works: which bucket each decision fits into, who owns the call, who reviews it, how fast disagreements get resolved, and where the decision gets written down.

That is enough to make the split work under pressure. If the rules fit on one page and people can use them by Friday, they are probably clear enough.

A simple turnaround example

A software company loses two midsize customers in one quarter. Revenue drops, and the runway falls to six months. Then sales gets a shot at one large deal, but the buyer asks for two custom features before signing.

The CEO wants both features built right away. From that seat, the logic is simple: close the deal, add cash, and buy time. The CTO sees a different picture. One feature fits the current product and the team can ship it in a few weeks. The second touches billing, permissions, and reporting, so a rushed build could break the next release.

This is where the split becomes practical. The CEO owns the cash goal and decides whether the deal matters enough to change priorities. The CTO owns the technical risk call and decides what the team can ship without causing a bigger failure next month.

They meet once, make the tradeoff, and put one written plan in front of the whole team: build the safer feature for the large customer, cut the risky feature for now, pause a low value project with weak usage, and keep two senior engineers focused on stability work.

That choice is not dramatic, but it is clean. Sales gets a real commitment instead of a vague promise. Engineering protects the release and avoids a scramble of bug fixes, delays, and late night patching.

The biggest win is not the feature decision itself. Everyone hears the same plan from both leaders on the same day. That stops mixed signals, side promises, and quiet resentment before they spread through the company.

Mistakes that break the split

Turnarounds fail less from bad intent than from blurred ownership. When the CEO and CTO both think they own the same call, the team slows down, waits, and then gets pulled in two directions.

The most common problem is quiet overlap. The CEO changes priorities because cash is tight. The CTO changes priorities because the product feels risky. Each move can make sense on its own, but together they create confusion. Each hard tradeoff needs one decider and one adviser.

Dates are another common failure point. A CEO promises a launch, a customer delivery, or a recovery timeline before asking how much work it will take. That can sound strong in the room, but it usually creates debt a week later. Engineers rush, testing shrinks, and support inherits the mess.

CTOs have their own blind spot. Some protect code quality without naming the business cost of that choice. If a CTO says, "We need to fix this first," that is only half the job. They also need to explain what delay costs, what risk grows if the team waits, and what smaller fix might buy 30 days.

Staffing cuts create another trap. Leaders under pressure often remove people by salary, title, or recent visibility. That is how companies lose the one engineer who knows the fragile billing logic, the deployment script, or the odd integration that breaks every Friday.

Meetings can wreck the split too. A weekly turnaround meeting that ends without a decision is not neutral. It tells the team that debate matters more than ownership. Every open issue needs a named decider, a deadline, and a clear tradeoff on the record.

A short weekly checklist

A turnaround gets worse when ownership blurs again after the first hard week. Put this review on the calendar at the same time every week. Keep it to 20 minutes and force clear answers.

• Each hard call had one owner.
• Spending moved toward the runway target.
• Roadmap changes matched current sales reality.
• Staffing moves protected the most fragile systems.
• The CTO raised new risks early.

Do not turn this into a long status meeting. A turnaround checklist works only if it forces action. When an item gets a "no," assign one person to fix it and set a deadline before the meeting ends.

If the same item fails two weeks in a row, the split is still muddy. Rewrite the decision table, name the owner again, and remove any shared gray area.

This review also shows whether the company is telling itself the truth. If cash is tightening, sales are weaker, and the roadmap still looks untouched, the plan is fiction.

What to do next

Put the split on one page today, not next quarter. Keep it plain: who owns cash, roadmap, staffing, and technical risk, and when the other person must be consulted. Then use that page for 30 days without rewriting it after every tense meeting.

That is when the split stops being a talking point and becomes a working rule. If a decision still bounces back and forth, the rule is not clear enough.

Each week, list the three hardest decisions made, write one owner next to each, mark any call that stalled between the CEO and CTO, and give every open issue one next action with a date.

Look for repeat friction, not perfect agreement. If staffing calls keep turning into product debates, or technical risk keeps getting pushed into budget meetings, fix the split and test it again the next week.

If trust is low or the same tradeoffs keep stalling, a short outside review can help. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and that kind of support can help a company sort technical, product, and staffing decisions without hiring a full time executive.

End each week with three decisions, one owner for each, and one next action. Hold that rhythm for a month and the company usually starts moving again.