5 Things I’d Stop Doing Immediately as a New CTO

5 things I’d stop doing immediately as a new CTO

In your first 90 days, it’s easy to burn weeks on work that feels responsible but quietly slows the company down. I’ve watched new CTOs spend 30 to 50 percent of their time stuck in approval loops, roadmap debates, and “quick fixes” that turn into permanent tax. The bill shows up fast: slower shipping, rising cloud spend, and teams that wait for permission.

My thesis is simple: stop five common habits early so you can build the systems, lead the people, and keep change from flattening you.

What should a new CTO stop doing in the first 90 days

Most CTOs I talk to fall into the same trap. They treat the job like “head engineer plus meetings.” It’s not. It’s an executive role where your output is other people’s output.

Here’s the frame I use in week one. I call it the Stop List.

• Stop work that makes you the bottleneck.
• Stop work that hides business trade-offs.
• Stop work that creates debt with no owner.
• Stop work that moves cost around instead of removing it.
• Stop work that treats AI like a demo team.

This lines up with a point I agree with from CIO.com. The CTO role can’t be “chief approval officer” anymore, and the discipline is knowing when speed becomes the enemy of good decisions at scale The CTO is dead. Long live the CTO.

It also matches what Will Larson tells new CTOs and VPEs: first figure out if something is truly dire, then keep one eye on the long game while you fight fires Your first 90 days as CTO or VP Engineering.

So what are the five stops? Let’s get concrete.

Stop treating technology as separate from the business

If you do one thing in month one, do this: tie every major engineering bet to a business outcome.

Nick Young put it bluntly. If your roadmap isn’t tied to revenue, customer experience, or cost, you’re solving IT problems instead of business problems Nick Young on CTO stop-doing list.

What this looks like in real life

A new CTO inherits a roadmap with 47 epics. Half are “platform improvements.” None have a number attached.

So the team ships.

• Sales still loses deals due to missing SSO.
• Support still escalates the same top 10 tickets.
• Cloud spend still grows 12 percent month over month.

The roadmap was busy. The business didn’t improve.

What to do instead: the Outcome Map

I use a simple artifact called an Outcome Map. It’s one page, and it forces trade-offs.

Rules that make it work:

• One metric per outcome. If you need three, you don’t have clarity.
• One accountable owner. Not a committee.
• One tech bet. Not a shopping list.

This is also where our Build vs Buy Matrix (/tools/build-vs-buy-matrix) earns its keep. Use it to force a decision on things like SSO, feature flags, and observability. Don’t let “we’ll build it later” become the default.

Internal links that pair well with this:

• Read our guide to build vs buy decisions that don’t rot (/tools/build-vs-buy-matrix).
• Pair it with architecture governance that doesn’t slow teams down (our ArchiMate Modeler at /tools/archimate).

Stop analysis paralysis and endless “alignment” meetings

New CTOs often over-correct. They see chaos and try to design the perfect plan. Then the plan becomes the work.

Nick Young calls this out as analysis paralysis: set outcomes, pick the fit-for-purpose option, and move Nick Young on CTO stop-doing list.

CIO.com makes the same point from a different angle: build systems that scale your judgment, and stop personally reviewing every ADR and RFC The CTO is dead. Long live the CTO.

The hidden cost: you become the queue

If every decision routes through you, you create a single-threaded org.

You’ll see it in:

• Cycle time rising week over week.
• PR size growing because teams batch changes.
• Incident load increasing because changes ship late and big.

If you don’t measure those, you’re guessing. Use our Engineering Metrics Dashboard (/tools/engineering-metrics-dashboard) to track DORA metrics and review them weekly with your staff.

What to do instead: the 70 percent decision rule

I use a rule that keeps teams moving without being reckless.

• Reversible decisions: decide at 70 percent confidence in 48 hours.
• Hard-to-reverse decisions: decide at 70 percent confidence in 2 to 4 weeks.

The catch: you have to define “reversible” in your context.

• Reversible: library choice, CI runner, internal API style.
• Hard-to-reverse: data model, cloud region strategy, identity provider.

Then build a decision system people can run without you.

• Decision record template: one page, problem, options, choice, risks.
• Guardrails: security, privacy, SLOs, cost limits.
• Escalation path: only for hard-to-reverse calls.

That’s what “build systems, not checklists” looks like in practice The CTO is dead. Long live the CTO.

Internal links that pair well with this:

• Use Command Center (/command-center) to track decisions, risks, and migrations.
• Use our incident postmortem guide (/tools/incident-postmortem) to turn mistakes into guardrails.

Stop lift-and-shift cloud migrations with no modernization plan

A lift-and-shift can be the right first move, but only if you treat it as a bridge. If you stop there, you’ve moved your legacy problems into a more expensive place.

Nick Young calls out cloud lift-and-shifts that skip modernization. They don’t fix the core issues, and they raise cost Nick Young on CTO stop-doing list.

The pattern I see

A company migrates a 10 year old monolith to Kubernetes.

• They keep the same chatty database calls.
• They keep the same batch jobs.
• They add a service mesh.

Six months later:

• Infra spend doubles.
• Reliability gets worse because you’ve introduced new failure modes.
• The team still can’t ship faster.

The migration became a resume project.

What to do instead: the Modernize or Stop matrix

Here’s a decision matrix you can reuse with your team. It’s blunt on purpose.

Rules:

• High value plus high risk: modernize in place first.
• Low value: stop, buy, or freeze.
• High change rate: rebuild only with strong ownership.

Then put numbers on it.

• Cost per request for customer facing services.
• Cost per pipeline run for data jobs.
• Error budget burn for reliability.

Our Cloud Cost Estimator (/tools/cloud-cost-estimator) helps you model the spend before you migrate. It also helps you explain trade-offs to finance without hand waving.

One more point from SimpleCTO that’s worth repeating: don’t start greenfield projects with microservices by default. You pay the coordination tax before you earn the scale benefits 5 Things I Will Never Do Again as a CTO.

Stop shipping systems with no owner after go-live

Unowned software turns into debt fast. It also turns into politics.

Nick Young calls this out directly: if there is no owner after go-live, you created technical debt on day one Nick Young on CTO stop-doing list.

The failure mode: “platform by abandonment”

A team builds an internal tool.

• The lead engineer leaves.
• The product manager moves on.
• Nobody owns uptime, cost, or security patches.

Then an incident hits at 2 a.m. The on-call can’t even find the runbook.

What to do instead: Service Ownership Contract

This is my link-worthy element. It’s a short checklist you can paste into your RFC template.

Service Ownership Contract, v1

• Named owner: one team, one manager.
• On-call: rotation exists, paging works, runbooks exist.
• SLO: one or two SLOs, error budget tracked.
• Dependencies: upstream and downstream listed.
• Cost center: tagged spend, monthly review owner.
• Security: patch cadence, secrets handling, data classification.
• Sunset plan: what “done” means, and how to retire it.

If a project can’t meet this bar, don’t ship it. Or ship it as a prototype with an explicit expiry date.

This connects to Will Larson’s advice to pay attention to roles like SRE and TPM. They often see ownership gaps first, and they’ll tell you if you make it safe to do so Your first 90 days as CTO or VP Engineering.

Internal links that pair well with this:

• Use Command Center (/command-center) to track service owners, SLOs, and risks.
• Use our incident postmortem template (/tools/incident-postmortem) to lock in ownership changes after incidents.

Stop treating AI as a side project or a demo factory

AI work fails in two predictable ways.

• It stays a toy project.
• It becomes a risky production system with no controls.

Nick Young’s point is simple: AI isn’t optional homework for R and D. Competitors already use it to deliver value Nick Young on CTO stop-doing list.

CIO.com makes a sharper point: a lot of leaders stay in the AI fun zone and avoid applying AI to fundamentals like cloud cost, SDLC, QA, and team design The CTO is dead. Long live the CTO.

What to do instead: AI as operations, not theater

Pick two AI use cases that hit core execution.

• Support deflection: reduce tickets per 1,000 users by 15 percent.
• Engineering throughput: reduce PR review time by 20 percent.
• FinOps: find idle spend and cut 8 percent in 60 days.

Then treat the work like any other production system.

• Data boundaries: what data can enter prompts.
• Auditability: log prompts and outputs for key workflows.
• Fallback paths: what happens when the model fails.
• Human review: where it matters, like refunds and access changes.

And don’t do it alone. The AmazingCTO survival guide calls out a common mistake: new CTOs don’t ask for help, and they try to carry everything themselves First-Time CTO: Survival Guide.

I’ve seen peer groups and fractional leaders work well here. They shorten the learning curve and reduce the odds you ship a risky AI workflow without guardrails.

Enterprise implications for CTOs

These five stops sound personal, but they show up in enterprise outcomes.

1. You reduce single points of failure in decision making. Stop being the approval queue and teams ship smaller changes and recover faster. You’ll see it in cycle time and incident rate.

2. You make cost a first class engineering constraint. Lift-and-shift without modernization turns into a cloud bill problem that finance escalates. Tie migrations to cost per request and error budget.

3. You shrink the blast radius of ownership gaps. Unowned services create surprise outages and surprise compliance work. A service ownership contract makes accountability visible.

4. You turn AI into measurable execution gains. AI demos don’t change the business. AI applied to QA, support, and FinOps changes margin and customer experience.

CTO recommendations you can apply this week

Immediate actions

1. Publish your Stop List: share the five stops in writing, and explain why.
2. Create an Outcome Map: pick 3 outcomes, 3 metrics, 3 owners, and 3 tech bets.
3. Audit decision queues: list every meeting where you approve work, then delete or delegate half.
4. Tag cloud spend: require cost allocation tags for the top 20 services by spend.
5. Name owners for top systems: pick the 10 systems tied to revenue, and assign owners.

Policy framework

1. Decision records: require a one page record for hard-to-reverse decisions.
2. Service ownership contract: block launches that lack on-call, SLO, and cost owner.
3. Migration gate: no cloud migration without a modernization step and a cost model.

Architecture principles

1. Start with a monolith unless scale forces change: avoid microservices as a default 5 Things I Will Never Do Again as a CTO.
2. Measure before you rewrite: use DORA metrics and error budget burn to pick targets.
3. Build systems that scale judgment: automate checks, and keep humans for edge cases The CTO is dead. Long live the CTO.

Bigger picture: subtraction is the job

The CTO mandate has shifted. Tools got stronger, markets got faster, and the cost of a wrong bet went up. That’s why stop-doing lists matter. They create space for the work that compounds.

I also like a reminder from SimpleCTO: don’t try to be the culture agent for the whole company. The CEO owns company culture. You own engineering culture and execution, and that’s plenty 5 Things I Will Never Do Again as a CTO.

Will Larson’s 90 day advice is a good guardrail too. If the org is in a dire state, fix the dire thing first. Just don’t get addicted to firefighting Your first 90 days as CTO or VP Engineering.

What would break in your org if you stopped being the approval path for every technical decision?

It’ll feel uncomfortable for two weeks. Then your leaders will grow into the space.

Sources

1. Nick Young LinkedIn post on top 5 things CTOs should stop doing
2. CIO.com, The CTO is dead. Long live the CTO
3. SimpleCTO, 5 Things I Will Never Do Again as a CTO or Senior manager
4. Will Larson, Your first 90 days as CTO or VP Engineering
5. AmazingCTO, First-Time CTO: Survival Guide for New CTOs