Early-stage CTO month one: what to say no to first

Why month one often goes off track

A new CTO can spot ten old problems in the first week. The code looks messy. The stack feels dated. People rely on tribal knowledge. The loudest problems often look like architecture problems, so they grab attention first.

Founders usually add pressure at the same time. They want more speed, fewer bugs, better planning, and cleaner releases right away. That creates a bad mix. The CTO starts trying to pay down old debt while pushing the team to ship faster than before.

Most small teams still release through habits nobody would choose on purpose. One engineer knows the deploy steps by memory. Someone else checks production by hand after every launch. Rollback takes too long, so people avoid shipping late in the day. From the outside, the product can look stable. Under the hood, the path to production is held together by workarounds.

That is where month one usually goes wrong. Big changes look productive because people can see them. A rewrite, a tool migration, a repo split, a cloud move, or a new platform project makes it feel like progress has started. In practice, those projects add more moving parts before the team fixes the delivery risk already sitting in production.

A team that cannot ship safely does not get safer because it picked newer tools. It usually gets slower first. People stop to learn new systems, old bugs stay open, and every release carries more stress because the basics are still shaky.

You can see this pattern in small SaaS teams all the time. A new CTO wants to replace an old framework in week two. The founders agree because the codebase looks ugly. Then a customer issue needs a hotfix, tests fail in one environment, and nobody trusts the deploy process enough to release quickly. The framework was not the first problem. The fragile path to production was.

If even one release still depends on a hero, month one should protect that release before it touches anything bigger.

What live delivery risk looks like

Live delivery risk shows up when the team treats broken releases as normal. People already expect that a deploy might fail, a fix might need another fix, or someone will stay online late "just in case." That is not a small process issue. Shipping is unstable.

One common sign is fuzzy ownership. No one can say who decides release timing, who can roll back safely, or who handles a hotfix when production breaks. Work still gets shipped, but it happens through habit and luck. When something goes wrong, the same question comes up again: "Who knows how this part works?"

Bug flow tells the same story. If new bugs arrive faster than the team closes them, delivery gets slower every week. Engineers spend their time reopening old issues, patching edge cases, and calming customers instead of finishing planned work. Once that starts to feel normal, leaders often make the wrong call and push for a rewrite.

Knowledge bottlenecks make the risk worse. One engineer knows the deploy steps. One person understands the billing service. One person can read the logs and tell whether the system is healthy. If that person is sick, asleep, or leaves, releases stop or turn into guesswork.

A small team can look fine on paper and still carry serious risk. Five engineers may ship every week, but if only one can deploy, only one knows rollback, and support keeps finding the same defects after every release, the team is fragile.

The check is simple. You should be able to name one owner for release timing. At least two people should be able to roll back without help. Hotfix steps should be written down and tested. Open bugs should not grow week after week. And the team should still be able to ship when one senior engineer is offline.

During the CTO's first 30 days, this matters more than tool debates. If the team cannot release safely this week, a migration or broad platform project will add stress, not control.

What to pause on day one

A new CTO usually spots a dozen things that look old, messy, or annoying. Most of them can wait. If releases slip, bugs sit too long, or the team cannot ship with confidence, the first job is to protect live delivery.

That means saying no to work that feels smart but does not solve a real production problem right now. Cleanup has its place. Month one is rarely that place.

Pause rewrites of code that already runs well enough in production. Pause tool moves when the current tools are ugly but still let the team ship. Pause broad platform projects that are not tied to a recent incident or a clear delivery problem. Pause org changes too. New reporting lines or new team splits create confusion fast, and shaky teams need clear priorities more than a fresh org chart.

Rewrites are the easiest trap. Engineers often want to replace an older service because they know they can build it better now. Maybe they can. But if customers are getting updates late, a rewrite steals attention from testing, release process, bug triage, and incident response. Old code that ships is often less risky than fresh code that is half done.

Tool migrations create the same drag. A team can lose two weeks moving issue tracking, CI, chat, docs, or cloud services, then discover that nothing ships faster. In the first 30 days, a tool should change only if the current one directly causes outages, blocks releases, or hides serious problems.

Broad platform work can sound responsible. Teams propose a new event system, a full data layer cleanup, a better internal framework, or a new observability stack. If there is no live incident behind it, push it back. Fix the release bottleneck first.

Use a plain filter: if the work will not lower delivery risk in the next few weeks, pause it. Write it down, keep the note, and come back once the team can ship without drama.

What to fix before any big change

For a small-team CTO, month one is mostly about making releases boring again. A rewrite will not save a team that cannot ship small changes safely. When delivery risk is high, new tools and platform work usually add one more moving part to an already shaky process.

Start with the deploy steps. Write them down in plain language, in the exact order the team uses today. Then shorten the path. Remove handoffs, one-off commands, and steps that live only in one person's memory. Another teammate should be able to deploy a small fix without asking for help.

Next, give every app area a clear owner. That does not mean silos. It means one person owns checkout, one person owns the email worker, one person owns billing. On a small team, one person may own more than one service. That is still better than shared confusion when something breaks late in the day.

Then add basic alerts. Keep them boring and useful. The team needs to know when the app is down, when errors jump, and when background jobs stop or back up. If the first alert comes from a customer, the team is guessing instead of operating.

Rollback needs practice too. Pick a small release and run the rollback steps from start to finish. Time it. Many teams think they can roll back in five minutes, then spend half an hour hunting for the old build, the right config, or the last safe database change. That gap matters more than a new stack.

Cut scope on unstable features until releases calm down. If a new onboarding flow breaks every other deploy, stop adding edge cases and polish for now. Trim it to the smallest version that works, fix the repeat failures, and watch two or three quiet releases go out.

None of this is flashy. It pays off fast. Once deploys are short, ownership is clear, alerts fire, and rollback works, bigger changes stop feeling like bets.

A simple order for the first 30 days

The first month should calm the release path, not chase a large rebuild. If the team cannot ship without stress, any rewrite or migration will pile new risk on top of old risk.

In week one, watch real work move from ticket to production. Sit in on planning, review how engineers hand work to each other, and follow one or two changes all the way to release. Look for where work waits, where context gets lost, and where nobody knows who owns the next step.

Week two should look backward. Pull a few recent releases and write down the three failures that caused the most pain. Keep it plain. Maybe deploys failed because tests ran too late. Maybe approvals sat for two days. Maybe a hotfix skipped review and created another outage the next morning.

By week three, pick one repeated problem and remove it. Just one. A small fix that changes daily work is better than a large project that sounds smart in a meeting. That fix might be a release checklist, one clear deploy owner, a rollback note for every production change, or a rule that nobody merges on Friday without a real reason.

Week four is when bigger ideas deserve a second look. Review the rewrite, tool migration, or platform project you wanted to approve on day one. Some will still make sense. Others will look much less urgent once the team can ship cleanly again.

This order feels almost too simple, which is why people skip it. For the first month, simple is often the right call. A calmer release process gives you better data, a more honest view of the team, and fewer expensive guesses about what to change next.

A realistic example from a small SaaS team

A six-person SaaS team had a frontend that nobody loved. Pages felt clunky, the code was messy, and two engineers wanted to move to a new stack right away. They had fair reasons. New hires would ramp up faster, and the team thought it could clean up years of shortcuts.

At the same time, support tickets told a more urgent story. Customers hit checkout errors after Friday deploys. Some saw failed payments. Others got charged but did not see their account update until Monday, when someone pushed a hotfix. Revenue did not stop, but trust took a hit every weekend.

The new CTO said no to the migration for now.

That answer annoyed the team for a week, but it was the right call. A stack migration would create more moving parts while the checkout flow already broke under normal release pressure. Fixing live delivery risk mattered more than improving developer comfort.

The CTO narrowed the work to three changes: add automated tests for the checkout path, including discounts, failed payments, and account activation; set up a simple rollback so the team could undo a bad deploy in minutes; and give one person clear release ownership, with a rule that nobody ships checkout changes late on Friday.

None of that looked exciting. It did stop the weekly damage.

Within two release cycles, Friday deploys became boring again. Support volume dropped. The team could see which changes caused trouble, and rollback was no longer a scramble in a group chat. Engineers also stopped guessing who should fix what because ownership was clear.

Only then did the CTO reopen the migration discussion. The team reviewed the same frontend move with better information: how often it deployed, where bugs appeared, how much test coverage it had, and whether the new stack would solve a real product problem.

Sometimes the answer is still yes. The difference is timing. In month one, saying no does not kill a good idea. It keeps a small team from rebuilding the house while the front door still will not lock.

Mistakes that waste the first month

The first month gets wasted when a CTO solves the most interesting problem instead of the most painful one. Teams often talk about new tools, cleaner architecture, or a better stack because those topics are easier than facing broken release habits. If code reaches production late, ships with avoidable bugs, or depends on one tired person to deploy it, that is the work to fix first.

One mistake is picking tools before finding the delivery bottleneck. A new ticket system, CI setup, or cloud service can wait a few weeks. Start with recent releases instead. Read the incident notes, pull request history, and deployment steps. If nobody can explain why the last two releases slipped, tool shopping is just motion.

Another bad move is opening architecture work before tracking real release failures. Teams love to debate service boundaries, rewrite plans, and package choices. Meanwhile, the last release may have failed for a simple reason: no rollback plan, slow reviews, weak testing, or unclear ownership. You do not need a grand redesign to fix that. You need facts from the work that already shipped.

Training the team on new systems during a fire drill is another month killer. If production is shaky, this is the wrong time to move everyone to a new repo flow, a new deployment tool, or a new observability setup. Learning curves are real. Even strong engineers slow down when they have to ship and relearn their basic workflow at the same time.

There is also a softer mistake: confusing engineering taste with business need. A team may hate the current codebase and still be able to ship safely with a few guardrails. The business usually cares about release speed, fewer customer-facing issues, and clear priorities. It rarely needs a cleaner stack this week.

Platform cleanup can become a polite way to avoid shipping. It feels neat, rational, and easy to defend. But if cleanup work does not reduce failed releases, shorten review time, or make on-call less chaotic, it probably belongs later.

Month one should feel a little boring. That is usually a good sign. Release tracking, incident review, ownership fixes, and simple deployment rules save more time than a flashy rebuild.

Quick checks before you approve a big project

Big projects look clean on a roadmap. They often make delivery worse before they make anything better.

If the team is still fighting failed releases, surprise outages, or hotfixes every Friday, a rewrite or tool move is usually the wrong bet. Before you approve anything large, ask five plain questions:

• Does this work remove a failure the team has right now? "We want to modernize the stack" is weak. "Deploys fail twice a week because the build takes 70 minutes and rollback breaks" is real.
• Can someone explain the rollback in one minute? If the answer needs a diagram and a meeting, the team is not ready to ship it safely.
• Will customers feel the change within 90 days? If users will not notice faster pages, fewer bugs, or fewer support issues, the work can probably wait.
• Can the same people keep shipping while this runs? A project that pulls every strong engineer away from production work is a risk, not progress.
• Did the last two releases go out calmly? If both releases needed late-night fixes, do not add more moving parts.

One familiar small-team pattern comes up again and again. The team wants to switch CI, move clouds, and split the app into services. Meanwhile, it still cannot predict whether Friday's deploy will succeed. In that case, the first approval should go to release safety: shorter builds, health checks, rollback steps, and one owner for every deploy.

This filter saves money too. The same lesson shows up in Oleg Sotnikov's work with lean infrastructure and small engineering teams: do not start with broad platform work just because it sounds cleaner. Start where live delivery breaks. Once the team ships twice in a row without drama, bigger bets are much easier to judge.

What to do next after month one

Month one should leave you with fewer surprises, cleaner releases, and a much clearer view of where delivery breaks down. After that, the job changes. You stop reacting to every fire and start making selective bets.

Keep a short delivery risk list and review it every week. It should stay small enough to read in a minute. If the same risk shows up three weeks in a row, treat that as a management problem, not a note-taking habit.

Do not rush into broad platform work just because the team feels more stable. Wait until releases feel boring. That usually means the team can ship on schedule, roll back safely, and explain incidents without guesswork. Drama is expensive.

When a rewrite or tool migration comes back onto the table, tie it to a clear problem. Good reasons are specific: a product change you cannot ship on the current stack, a cost that is clearly too high, or an operational pain that keeps hitting the team every week. "The code feels old" is not enough.

Ask a few plain questions. What product or cost problem does this change fix? What happens if you do nothing for 90 days? Can the team ship normal releases while doing it? What is the smallest version worth trying first? If those answers are vague, the project is probably too early.

This is also the point where month one turns into a real operating rhythm. Weekly risk review, steady releases, and tighter approval for big technical work save more time than any new tool.

Some founders want a second opinion before they approve a rewrite, migration, or larger architecture push. That can help, especially when the team is tired and every option sounds urgent. Oleg Sotnikov at oleg.is reviews delivery risk, release habits, and near-term technical decisions as a fractional CTO advisor. A short outside review can stop an expensive detour before it starts.