90 Day Plan for a New CTO: Week-by-Week Priorities, People and Metrics

11 min read ยท 2026-10-25

A 90 day plan for new CTO roles splits your first three months into three jobs: learn how the company and its technology really work (days 1-30), decide what to fix and in what order (days 31-60), and commit to a technology strategy the CEO and your team can hold you to (days 61-90). The plan below goes week by week, with a milestone you can check at the end of each phase.

A CTO plan is not an engineering manager plan with a bigger title. You own technical risk, the budget conversation and the long-term architecture, and the CEO expects a clear view on all three. So this guide covers what generic templates skip: the first-week safety check, the people to meet and what to ask them, quick wins that build credibility without breaking things, the metrics to baseline, and how to present the plan to your CEO, your board or an interview panel.

The roadmap at a glance

Goal: By day 90, you have the trust of the CEO and the engineering team, a baseline for delivery, reliability and people metrics, and an approved 12-month technology strategy with owners and dates. Duration: 13 weeks (90 days)

  1. Access, people and safety check (Week 1)

    Meet the people who matter most and confirm nothing critical is about to break.

    • Sit down with the CEO to agree what success looks like at day 90 and which decisions are yours, such as hiring, vendors and architecture.
    • Get access to the code repositories, the cloud console, the incident tool, the on-call schedule, vendor contracts and the engineering budget.
    • Read the last six months of incident postmortems, security findings and open audit items.
    • Introduce yourself at an engineering all-hands and say plainly that you will listen for 30 days before making big changes.
    • Book 1:1s with every direct report and a skip-level slot with each team.

    Milestone: A one-page list of the top five operational risks, each with a named owner, and a written day-90 success definition the CEO agrees with.

  2. Listen and map (Weeks 2-4)

    Understand the team, the architecture and the business pressure before you form opinions.

    • Run 1:1s with every engineer in a team under 50 people, or with every manager, staff engineer and tech lead in a larger one, using the same five questions.
    • Draw the current architecture with your senior engineers: main services, data stores, third-party dependencies and single points of failure.
    • Join an on-call shift or an incident review to see how the team works under pressure.
    • Meet the heads of product, sales, customer success, finance and security, and list every promise engineering has made to customers.
    • Collect baseline numbers: the four DORA metrics, incidents per month, open roles, regretted attrition and the cloud spend trend.

    Milestone: A listening summary (themes, not names) shared with the CEO and engineering leads, and a baseline sheet with every metric filled in.

  3. Diagnose and ship quick wins (Weeks 5-8)

    Decide what to keep, fix or replace, and show you can improve things fast.

    • Rate each part of the stack as keep, fix or replace with your staff engineers, and write down why.
    • Check team structure against the product roadmap: team boundaries, spans of control, missing skills and key-person risk.
    • Ship two or three quick wins the team asked for, such as fixing the noisiest alert or a flaky deployment step.
    • Agree on how technical decisions get made, for example a short RFC for big changes and an architecture decision record for each one.
    • Review security basics with your security lead: access reviews, secrets handling and a tested backup restore.

    Milestone: Quick wins shipped and announced to the team, and a diagnosis document reviewed by all engineering leads.

  4. Write the technology strategy (Weeks 9-11)

    Turn your diagnosis into a 12-month plan the business can fund and track.

    • Pick three to five strategy themes, such as reliability, platform modernization, data, security and team growth.
    • Size the tech debt and platform work, and propose a capacity split between roadmap features and engineering investment.
    • Agree with the head of product on how that split changes next quarter's roadmap.
    • Draft the hiring plan and any org changes, with a reason for each role.
    • Walk the CEO, the head of product and the CFO through the draft one by one before any group meeting.

    Milestone: A strategy draft that the CEO, head of product and CFO have each reviewed, with their comments resolved.

  5. Present, commit and set the rhythm (Weeks 12-13)

    Get the strategy approved and set up the routines that will run engineering from here.

    • Present the strategy to the executive team, and to the board if the CEO wants it there.
    • Share it at an engineering all-hands and take open questions.
    • Publish a metrics dashboard that tracks the baseline you set in weeks 2-4.
    • Set the operating rhythm: weekly engineering staff meeting, monthly operations review, quarterly planning.
    • Ask the CEO and your direct reports for honest feedback on your first 90 days.

    Milestone: Strategy approved by the executive team, dashboard live, and next quarter's engineering goals agreed with owners.

Your first-week checklist

Week one is not about strategy. It is about access, people and risk. Many new CTOs lose their first week to laptops and onboarding sessions, then find out in week three that a certificate was about to expire or a key engineer had already resigned. Use the list below and tick it off by Friday.

Keep a running notes file of everything you notice. Do not act on most of it yet. Write it down with the date and come back to it in week five, when you have context.

  • Agree with the CEO on your decision rights, who owns the engineering budget and how often you will meet (weekly is a good default).
  • Confirm who holds admin access to production, the cloud account, the domain registrar and the code host, and remove anyone who has left.
  • Check that backups exist and that someone has tested a restore recently.
  • List the incidents of the last six months and the ones still open.
  • Read the current product roadmap and the dates sales has given customers.
  • Ask HR for open roles, recent departures and any active performance cases in engineering.

Who to meet in the first 30 days, and what to ask

A new CTO needs a map of people as much as a map of systems. With engineers, ask the same five questions every time so you can compare answers: What is working well? What slows you down? What would you change first if you were me? What is the riskiest part of the system? Who should I talk to next?

When you report back, write down themes, not names. Engineers are more open when they trust that their words will not be quoted in a leadership meeting.

  • CEO: priorities, the history of past technical leaders, what the board worries about.
  • Head of product or CPO: roadmap pressure, and what product thinks engineering does well and badly.
  • Engineering managers and staff engineers: team health, architecture pain, who the key people are.
  • CFO or finance lead: engineering budget, cloud spend trend, vendor renewals coming up.
  • Sales and customer success leads: escalations, promises made to customers, deals blocked by missing features.
  • Security or compliance lead: open findings, upcoming audits, customer security questionnaires.
  • Two or three customers: what breaks for them and what they want next. Ask the account manager to set up the call.

Quick wins that fit a CTO

A quick win for a CTO is not a new feature. It is a visible fix that tells the team you listened and tells the CEO you can deliver. Pick fixes the team raised in your 1:1s, that a small group can finish in two to three weeks, and that do not need a big architecture decision you are not ready to make.

Announce each one with a short note that credits the engineers who did the work. Avoid quick wins that reverse a decision a senior person made before you arrived, unless you have talked to them first.

  • Silence the noisiest false alert so on-call engineers can sleep.
  • Fix a flaky test or deployment step that blocks releases every week.
  • Unblock a stalled hire by joining the final interview and deciding fast.
  • Cancel a recurring meeting that engineers called useless in their 1:1s.
  • Turn off unused cloud resources found during the architecture review.

Metrics to track from day one

You cannot show progress at day 90, or at day 365, without a baseline. Collect these numbers in weeks 2-4 even if they are rough. A rough baseline in month one is worth more than a perfect one in month six.

Keep the dashboard small. Leadership will read five numbers, not 25. Report each one as a trend, with a short note on why it moved.

  • Deployment frequency and lead time for changes: pull them from your CI/CD tool, or count production deploys and the time from merge to production.
  • Change failure rate and time to restore service: take them from your incident tool and deploy logs.
  • Incidents by severity per month: count them from postmortems, and note how many repeat a known cause.
  • Regretted attrition and time to fill open roles: get both from HR every month.
  • Cloud spend trend: track it against a business number, such as spend per active customer, so growth does not hide waste.
  • Roadmap predictability: compare what each team committed to at the start of the quarter with what it shipped.

Example: a filled-in 90 day plan for a scale-up CTO

Picture a CTO joining a B2B SaaS company with about 40 engineers in five teams, a monolith that slows releases, and a large customer who wants a security review before renewing. Here is how the plan could look.

Each phase names an owner besides the CTO. You cannot run everything yourself, and the plan shows your team who you trust with what.

  • Week 1: risk list done, and an admin account of a former employee closed the same day. Owner: CTO with the platform lead. Milestone: five risks logged with owners.
  • Weeks 2-4: 1:1s with all five engineering managers and eight senior engineers, plus a call with the customer. Owner: CTO. Milestone: listening summary shared with the CEO.
  • Weeks 5-8: release pipeline fixed so deploys go out daily instead of weekly, and the security questionnaire answered. Owners: platform lead and security lead. Milestone: first week of daily releases, questionnaire sent.
  • Weeks 9-11: strategy with four themes: split billing out of the monolith, reliability targets per service, a data platform, two new team leads. Owner: CTO with the staff engineers. Milestone: CEO, CPO and CFO reviews done.
  • Weeks 12-13: board presentation and engineering all-hands. Owner: CTO. Milestone: strategy approved and quarterly goals set.

How to present the plan to your CEO, the board or an interview panel

For the CEO, bring a one-page summary to your day-30, day-60 and day-90 check-ins: what you learned, what you decided, what you shipped and what you need. Lead with business risk and customer impact, not frameworks. The CEO wants to know whether the platform will hold up as the company grows, and what that will take.

For the board, keep it to four slides and leave out tool names and architecture diagrams unless someone asks. In an interview, build a 30-60-90 version from what you can see from outside: the product, the job post, public engineering posts and what the interviewers tell you. Say clearly what you would verify in your first weeks. Panels trust a candidate who checks before changing far more than one who arrives with a rewrite plan.

  • Slide 1: what I found, with three risks and three strengths.
  • Slide 2: strategy themes for the next 12 months, with one outcome each.
  • Slide 3: metrics baseline and targets.
  • Slide 4: the decisions and support I need from this group.

How to adapt it to your company

At an early-stage startup, the CTO often still writes code and may be the first engineering leader. Shorten the listening phase to two weeks, spend more time with customers and founders, and focus the strategy on hiring the first team and choosing a stack you can keep for a few years.

At a large company, you may lead hundreds of engineers through VPs and directors. You will not meet everyone, so run group listening sessions, add a short anonymous survey, and spend more time on budget, vendor contracts and architecture governance. In a regulated industry, meet risk and compliance in week one and review audit findings before you change anything in production.

Common mistakes to avoid

  • Announcing a rewrite or reorg in your first month burns trust before you understand the system, so hold big changes until your diagnosis is reviewed in weeks 5-8.
  • Meeting only engineers leaves you blind to business pressure, so book product, sales, finance and customer meetings in the first 30 days.
  • Skipping the baseline means you cannot prove progress later, so capture the DORA metrics, incidents and attrition in weeks 2-4 even if the numbers are rough.
  • Picking quick wins only you care about looks like vanity, so choose fixes the team raised in their 1:1s and credit the people who did them.
  • Presenting the strategy to a group before talking to each executive invites surprise objections, so review the draft one by one with the CEO, head of product and CFO.
  • Trying to stay the best coder in the room pulls you away from the job, so hand hands-on work to staff engineers and keep your time for people, risk and direction.

Frequently asked questions

What should a new CTO do in the first 90 days?

Spend the first 30 days learning: meet the CEO, product, finance and every engineering lead, and check for operational risk. Use days 31-60 to diagnose the stack and the team and ship a few quick wins. Use days 61-90 to write a 12-month technology strategy with metrics and get it approved.

How do I write a 30-60-90 day plan for a CTO interview?

Build it from what you can see from outside: the product, the job post, public engineering posts and what interviewers tell you. Keep the first 30 days about listening and risk, and list what you would verify before changing anything. End with how you would measure success at day 90.

What metrics should a new CTO report?

Start with delivery and reliability: the four DORA metrics and incidents by severity. Add people metrics such as regretted attrition and time to fill roles, plus cloud spend tied to a business number. Report trends against the baseline you set in your first month.

When should a new CTO make big changes?

Fix urgent risks such as open admin access or untested backups right away. Hold reorgs, rewrites and major vendor changes until you have finished listening and your engineering leads have reviewed your diagnosis, usually in the second or third month.

How is a CTO 90 day plan different from a VP of engineering plan?

A VP of engineering plan focuses on delivery, team health, hiring and process. A CTO plan adds technology strategy, architecture direction, security posture and the conversation with the CEO and board about long-term technical risk. In smaller companies one person often does both jobs, so the plan covers both.

Generate this roadmap with AI