When an acting CTO should write code and step back

Why founders get stuck

Founders often ask whether an acting CTO should write code. It sounds like a simple yes or no question, but it usually points to three different problems.

Sometimes the business needs rescue work because production keeps breaking. Sometimes the product has grown into a messy system and needs architecture cleanup. And sometimes the codebase is mostly fine, but the team ships too slowly and needs coaching.

From the founder's seat, these can look almost identical. Revenue feels exposed, the roadmap slips, and everyone says they're busy. So one senior person gets hired to fix bugs, set direction, and improve the team at the same time. That can work briefly. Then the trade-offs show up.

Urgent bugs are where the line gets blurry. When customers are blocked, nobody wants a long discussion about hiring plans, code review habits, or service boundaries. The new CTO opens the editor, patches the outage, and becomes the fastest engineer in the room. That feels productive. It can also push planning off the calendar again and again.

There's another trap. A CTO who codes every day can shield the team from weak habits. If pull requests are unclear, tests are thin, or nobody owns deployment quality, a strong senior person can drag the work forward by force. The product moves. The team doesn't improve much.

The opposite mistake happens too. A CTO who stays out of the code can sound thoughtful and calm while missing the real bottleneck. A few hours in the repository often tell the truth faster than a stack of meetings: tangled modules, risky release steps, or a build that takes 40 minutes. You won't spot that on a slide.

So founders aren't really choosing between coding and leadership. They're deciding where senior attention should go first, and which problem hurts the company most right now.

When rescue work makes sense

An acting CTO should write code when the business has an immediate failure, not when the team just feels slow. If customers can't use the product, payments fail, or support fills up with the same complaint, waiting for the perfect plan is a mistake.

This is emergency work. The goal isn't to rebuild the product or prove technical skill. The goal is to stop the damage, get customers unstuck, and buy the company some breathing room.

Direct coding usually makes sense in a few cases:

• Production problems keep blocking normal customer use.
• The release process is so broken that even small fixes can't ship.
• A senior engineer leaves and takes too much system knowledge with them.
• The team needs a fast patch before it can make calmer decisions.

Picture a common startup mess. A bad release goes out on Friday, signups break, and the one engineer who understood deployments left last month. The team spends hours guessing. In that moment, coaching the team for the long term is too early. Someone needs to get into the code, fix the release path, and restore service.

Short rescue coding works because it buys time. It might remove one failing dependency, add a missing test around the broken flow, or simplify a risky deploy script so the team can ship again. A few days of direct work can save weeks of chaos.

But rescue work goes bad when it has no boundary. If the acting CTO keeps coding after the fire is out, the company usually gets a new bottleneck. The team waits for the rescuer to make every hard call, and the original weakness stays in place.

Set the end date on day one. That might mean one week, two sprints, or one release cycle. Define the finish line in plain language: customers can use the product, urgent fixes can ship, and the team understands the patch well enough to own it.

That's the right use of rescue work. Stop the bleeding, then step back.

When architecture cleanup matters more

If founders assume an acting CTO should write code every time the product feels shaky, they often miss the real problem. Repeated outages rarely come from one slow engineer or one missing feature. They come from design debt: weak boundaries between services, fragile deploy steps, unclear data flow, and too many moving parts.

A short coding sprint can hide that pain for a week or two. Then the same bug returns in a new form. The team spends Monday fixing production, Tuesday arguing about ownership, and Wednesday delaying work customers actually asked for.

Architecture cleanup matters more when the system creates repeat friction. You can usually spot it when the same class of outage keeps coming back, releases need too many manual steps, nobody clearly owns a service or table, and small changes keep breaking unrelated parts of the product.

That kind of mess doesn't need a hero coder first. It needs someone to change the structure. A good acting CTO cuts the number of services, removes duplicate tools, simplifies releases, and makes ownership obvious. Those changes look less dramatic than shipping a feature, but they save more time.

Too many tools are a common cause. Teams add one service for logs, another for jobs, another for feature flags, another for internal scripts, and before long every fix depends on five subscriptions and a lot of tribal knowledge. More software can create more work. Cleanup often means deleting things, not buying more.

Ownership problems make everything slower. When a checkout bug touches API code, cloud settings, and a half-maintained worker, people start blaming each other because nobody has the full picture. A CTO should name owners, reduce overlap, and set clear rules for who changes what.

This is the kind of work Oleg Sotnikov has done at production scale: cutting redundant services, tightening CI/CD, and keeping uptime high with a much smaller operation. That's what cleanup is for. Remove the repeat pain first. Then the team can ship new work without stepping on the same rake every week.

When team coaching works better

A startup team can know the product well and still miss dates because nobody breaks work into pieces that are small enough. Pull requests sit too long. Reviews drift into style comments while bugs slip through. The code doesn't need a rescuer. The team needs better habits.

That's when coaching beats heroics. If a fractional CTO drops in and writes a week of code, the team may ship one feature faster. Then the same planning mistakes, weak reviews, and vague tickets show up again. The company paid for extra hands when it really needed better judgment.

Pairing sessions often fix more than solo coding. In 60 minutes, a CTO can show an engineer how to split a risky change, where to add tests, and which parts deserve the closest review. One session like that can stop the same mistake from spreading across five more tickets.

Clear standards help junior developers most. They don't need constant rescue. They need simple rules they can use without waiting for a senior person to save the day. A short shared checklist goes a long way: what "done" means, when to split a pull request, what tests are required, and when to ask for help.

Planning usually improves too. Teams miss deadlines because tickets hide too much work. "Build settings page" sounds small until it includes permissions, validation, edge cases, data changes, and support issues. A coached team learns to break work into pieces that fit real estimates.

How code still helps

In this situation, the acting CTO should still write code in short bursts and explain each choice. The code matters, but mostly as a teaching tool.

That usually means a few focused moves instead of owning whole features:

• Pair on one hard change instead of taking over the full feature.
• Rewrite one messy function together and talk through the trade-offs.
• Set review rules the team can follow next week.
• Turn one missed sprint into better task breakdown for the next one.

This is often how Oleg Sotnikov works with startup teams: hands-on enough to teach, but not so hands-on that the team stops thinking for itself. If your engineers know the product and can build, coaching usually gives a better return than dropping in a temporary lead developer.

How to decide in the first week

The first week should answer a business question before anyone argues about frameworks or coding style. Where is the company losing money, time, or trust right now?

If customers hit bugs that block sales, rescue work comes first. If releases crawl and every change causes fresh damage, architecture cleanup likely matters more. If the code is mostly fine but the team keeps repeating the same mistakes, coaching will do more than another senior pair of hands.

Start with business risk, not the tech stack. Founders often react to ugly code because they can see it. The bigger problem may be elsewhere: a broken signup flow, a release process that takes three days, or engineers who wait for one person to approve every move.

Write down today's problems in plain language:

• Revenue risk: broken flows, outages, churn after bugs.
• Delivery risk: slow releases, rework, unclear ownership.
• Hiring risk: weak onboarding, juniors without support, seniors stuck firefighting.
• Founder risk: too many product and technical calls landing on one person.

Then check why the team is stuck. Do they lack skill, time, or direction? Skill problems call for coaching, code review, and tighter standards. Time problems may justify short-term hands-on work from the CTO. Direction problems need priorities, architecture decisions, and clearer ownership.

Pick one primary mode for the next 30 days. That part matters. A founder who asks for rescue work, architecture cleanup, and team coaching at the same time usually gets a little progress on all three and a real fix on none.

Review the choice every week. Startup facts change fast. A system that looked stable on Monday can turn into rescue work by Friday. A team that needed coding help last week may need coaching next week once the urgent bugs are gone. Good CTO support isn't rigid. It shifts when the evidence shifts.

A simple startup example

A small SaaS company missed release dates for six weeks. Every Friday looked the same: the code seemed close, tests failed, last-minute fixes piled up, and nobody knew who could approve the final merge.

The founder asked the acting CTO to rewrite the backend. That's a common reaction. When a team feels stuck, a rewrite looks cleaner than untangling a messy process.

The CTO did a short audit first. He traced the release path, watched one standup, read recent pull requests, and followed a failed build from start to finish. The backend had rough spots, but it wasn't the reason the team kept missing releases.

Two problems caused most of the delay. The test suite failed at random, so engineers stopped trusting it. Ownership was also unclear. One engineer changed billing logic, another touched the same service, and no one felt responsible for the final release.

So he wrote some code, but only where it removed friction fast. He fixed the build scripts, removed a few flaky tests, tightened the release steps, and added a small set of checks the team could trust. This is often when an acting CTO should write code: to clear a blocker the team can't safely clear on its own.

He didn't stop there. He coached the two engineers working on the services behind most of the missed deadlines. One owned billing. The other owned the API layer. They reviewed changes together for a week and wrote down who decides what during a release.

By the second week, the team shipped again. The product didn't get a dramatic new backend. It got something better: releases moved, engineers had clear ownership, and the founder avoided a risky rewrite.

That's why fractional CTO rescue work often overlaps with cleanup and coaching. The fastest fix isn't always new code. Sometimes the best help is a small repair, a cleaner release path, and a team that can run it without outside rescue next month.

Mistakes founders make

Founders often ask whether an acting CTO should write code, but they usually ask it at the wrong moment. The first mistake is jumping to a rewrite before anyone measures the real problem. Slow releases, bugs, and team stress don't always come from bad architecture. Sometimes the issue is weak planning, unclear ownership, or a broken review process.

A common pattern looks like this: the app feels messy, a senior engineer complains about "technical debt," and the founder decides the whole stack needs to change. That can burn months and cash. If nobody has checked error rates, delivery speed, support load, and the parts that actually break, a rewrite is just a guess.

The second mistake is using the CTO like a permanent extra senior engineer. Short rescue work can help when production is on fire or a release is blocked. Keeping that person in the codebase every week for ordinary tickets is different. Then the company pays for leadership and gets another pair of hands. The team may even wait for the CTO to solve hard problems instead of growing.

Founders also mix firefighting with roadmap work every day. In the morning, the CTO fixes an outage. After lunch, the CTO is expected to plan hiring, review architecture, and make product trade-offs. By evening, none of those jobs has full attention. Constant switching makes even smart people sloppy.

Another mistake is ignoring who will maintain the new code. A CTO can clean up a hard subsystem fast, but speed isn't the only test. If the team can't read it, deploy it, and change it next month, the company inherits a new problem. Fast work that only one person understands gets expensive later.

The last mistake is role drift. Founders say they need rescue work for two weeks, then keep adding side jobs. Soon the CTO handles outages, roadmap planning, vendor calls, interviews, and feature delivery with no clear end point.

Two questions fix a lot of this:

• What specific problem must change in the next 30 days?
• How will we know the CTO should step back?

If founders can't answer both, the role will blur, the team will lean too hard on one person, and the company will buy the wrong kind of help.

A quick checklist before you decide

Founders often ask for code when they really need a decision. Whether an acting CTO should write code depends less on preference and more on what breaks if nobody acts today.

Use this check before you hand over access, assign a cleanup project, or ask for team coaching:

• Is one live system problem hurting revenue right now? If customers can't pay, log in, or use the product, direct rescue work usually comes first.
• Can your team maintain any code the CTO writes next week? If the answer is no, fast coding can leave you with one more thing nobody owns.
• Will architecture cleanup stop the same outage or slowdown from coming back next month? If it fixes the root cause, cleanup often beats another patch.
• Would coaching help your team solve this class of problem on its own? If yes, hands-on guidance may do more than a few days of expert coding.
• Did you agree on the goal, the owner, and the end date? If those are fuzzy, people will argue later about what success meant.

This list sounds simple, but it filters out most bad hires and rushed decisions. A founder under pressure may ask for a senior person to "just fix it." That can work in a true emergency. It works badly when the real issue is weak team process, unclear architecture, or missing ownership.

One warning: rescue work feels productive because you can point to a bug fix or deployment by the end of the day. Coaching feels slower. Cleanup feels even slower. But if the same payment bug appears every Friday, the fast answer wasn't the right answer.

If you bring in a fractional CTO, set the mode from day one. Say whether the job is rescue, cleanup, or coaching. Then put a stop point on it. For example, "stabilize checkout in three days" or "coach the team through two releases and then step back." Clear limits keep outside help useful instead of permanent.

What to do next

Start with one page, not a long brief. Write down the first problem you need solved in plain words. "The product is down twice a week" is clear. "We need better tech leadership" is too vague.

Then pick the kind of help that matches that problem. If revenue is at risk because the app is unstable, you likely need rescue work. If the team ships but every release hurts, choose architecture cleanup. If the product is mostly fine and the team keeps stalling on decisions, coaching will usually do more than extra coding.

A simple filter helps:

• Choose rescue work when something is broken now and the business can't wait.
• Choose cleanup when the code works, but the structure slows every change.
• Choose coaching when the team can build, but they need better judgment, process, and technical direction.
• Choose a mix only if the CTO can explain where each hour goes.

Ask any acting CTO how much time they expect to spend writing code in the first month. Don't accept a fuzzy answer. A good answer sounds like, "I'll code about 60% for two weeks to stop the fires, then drop to 20% while I document risks and coach the team." That shows they know why they're hands-on and when they'll step back.

Keep the first engagement short. Two to six weeks is often enough to learn whether the fit is right. Set one or two measurable outcomes: fewer incidents, faster deploys, a hiring plan, clearer ownership, or a roadmap the team can actually follow.

If you're unsure what your company needs, ask for a diagnosis before you ask for a long contract. Founders often buy coding when they need clarity, or buy advice when they need someone to fix a live system tonight.

If you want an outside view, Oleg Sotnikov at oleg.is helps founders sort this out. His work spans rescue fixes, architecture, infrastructure, and fractional CTO support, so the first step can stay small and practical.

Make the first decision specific and easy to judge. That saves money, lowers risk, and tells you quickly whether you need a coder, a fixer, or a coach.