30-60-90 day plan for CTOs

A 30-60-90 day plan for a new CTO should learn the architecture, the incident history and the engineering team in the first 30 days, baseline delivery, reliability, security and cost, then use days 31-60 to fix the most urgent risks and the hiring process, and finish at day 90 with a technical strategy the CEO and product leadership have agreed. The CTO's plan is about the product's technology and the team that builds it, which is what separates it from a CIO's plan for internal systems. Security standards and customer security reviews, as of October 2026, belong in the first month, not a later phase.

This plan is for a CEO, founder or board hiring a chief technology officer at a software or technology-enabled company. For the CIO version, see the 30-60-90 day plan for CIOs; for the managers who will report to the new CTO, see the 30-60-90 day plan for engineering managers. The executive listening tour is covered in the 30-60-90 day plan for executives.

What does a new CTO need to learn before changing the architecture?

Every production system carries decisions that made sense at the time. A new CTO who proposes changes before learning those reasons tends to repeat old mistakes or break something that was load-bearing. The first month should cover:

• The system map: services, data stores, third-party dependencies, how a request travels end to end, and where data about customers lives.
• The incident record: the last six to twelve months of incident reviews, what recurred, and which fixes were promised but not done.
• The delivery path: how code gets from a laptop to production, how long it takes, who can approve it, and how rollbacks work.
• The cost: the cloud and tooling bill by service, and what drives it.
• The people: who holds knowledge no one else has, who is carrying on-call, and who is close to leaving.
• The promises: security commitments in customer contracts, roadmap dates sales has given customers, and service levels.

The 30-60-90 day plan

30-60-90 day plan — [Name], Chief Technology Officer, [company]
Reports to: [CEO]    Start date: [date]
Engineering: [N] engineers in [N] teams; managers: [names]
Stack: [languages, cloud, data stores]    On-call: [rotation]
Customer security commitments: [SOC 2 report / questionnaires / none]

DAYS 1-30 — Learn the system and the team; baseline
Goals:
- One-to-one with every engineering manager and senior engineer;
  skip-levels with a sample of the rest
- Read the architecture docs and the last 6-12 months of incident
  reviews; join live incident calls and shadow one on-call shift
- Ship one small change through the full pipeline yourself
- Baseline delivery and stability (DORA measures), incidents,
  cloud cost, open security findings, hiring pipeline
- Meet the CPO or head of product, the head of sales and two or
  three customers with complex technical requirements
Deliverables by day 30:
- A system and risk map: top risks with owners and dates
- A baseline of the measures above, with how each is calculated

DAYS 31-60 — Fix what is urgent; set the operating rhythm
Goals:
- Close or schedule the highest security and reliability risks
- Agree how product and engineering plan together: one roadmap,
  capacity for maintenance and security, who decides tradeoffs
- Review the hiring process and engineering levels; fix the loop
  for the roles open now
- Set an architecture review practice for significant changes
Deliverables by day 60:
- Risk progress report; a written product-engineering agreement
- Hiring plan for the next two quarters, with the interview loop

DAYS 61-90 — Agree the technical strategy
Goals:
- Present a technical strategy: the few architectural problems that
  limit the business, with evidence and an incremental plan
- Propose team structure changes, if any, with the reasons
- Set targets for the baseline measures with the CEO
Deliverables by day 90:
- Technical strategy reviewed by the CEO and product leadership
- Targets agreed; first quarterly engineering review held

Check-ins: weekly with the CEO; day 30, 60 and 90 reviews.

Which delivery and reliability measures should a CTO baseline?

Use measures the team can calculate the same way every month. DORA's research program publishes five software delivery performance metrics, as of October 2026: change lead time, deployment frequency and failed deployment recovery time (grouped as throughput), and change fail rate and deployment rework rate (grouped as instability). Add the business side: incidents customers noticed, and cost. The standards in the last column are examples only.

Which security standards will a CTO be asked about?

At a B2B software company, customers' security reviews arrive in the first month whether the CTO is ready or not. Know which of these the company already uses, and which commitments are in signed contracts, as of October 2026:

• SOC 2. An attestation report from an independent CPA firm on a service organization's controls, measured against the AICPA's Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. Find out the report period, the auditor, open exceptions and who owns evidence collection.
• NIST Secure Software Development Framework. SP 800-218 sets out secure development practices; version 1.1 is final, and a revision (version 1.2) was released as a draft in December 2025. It is a useful checklist for the development pipeline and for customers who ask how software is built.
• OWASP Top 10. The OWASP Top 10 (2025 edition) lists common web application security risks and is a common baseline for code review and testing.
• Public companies: the SEC's cybersecurity disclosure rules require a Form 8-K within four business days after an incident is determined to be material. Learn the escalation path in the first month.

Privacy laws, sector rules and contracts add their own duties; confirm them with counsel and the security lead. This is not legal advice.

How should a new CTO handle engineering hiring?

Hiring is often the CTO's slowest lever and the one the CEO notices most. In the first 60 days, read the job descriptions and leveling guide, sit in on interviews for open roles, and check whether each interviewer knows what they are assessing. A loop where every interviewer asks their favorite questions produces debates about impressions rather than evidence. The interview guide for software engineers gives a structure to start from: one competency per interviewer, the same core questions for every candidate, and scores written before the debrief.

What does "on track" look like at day 30, 60 and 90?

A filled example

How should a CEO use this plan in the final interview?

Give CTO finalists the same brief: team size, stack, the product's biggest reliability or scaling issue you are willing to share, and the company stage. The guide on how to evaluate a 30-60-90 day plan in an interview explains how to score it. A strong plan learns before it rewrites, names the product leader as a partner, includes security and hiring, and measures delivery before setting targets. Questions that test it:

• "Our biggest customer's security review is due in week two. What do you do?"
• "Tell me about an architecture decision you reversed, and what told you to reverse it."
• "How would you decide between a reliability project and a feature sales has promised?"
• "Our best engineer is the only one who understands billing. What happens in your first 60 days?"

If the CEO is not technical, add an experienced engineer or another CTO to the panel; the guide on interviewing for technical roles as a non-technical recruiter explains how to evaluate answers you cannot check line by line.

What should the CEO ask at the 30, 60 and 90-day check-ins?

• Day 30: Which part of the system scares you most, and why? Who on the team would we be in trouble without?
• Day 60: What did you decide not to fix yet? Where do you and the head of product disagree?
• Day 90: What will the strategy cost in feature delivery this year? How will we know in six months whether it is working?

Common mistakes

• The early rewrite. Announced in the first month, it signals that the CTO does not respect the system the team built and usually underestimates the work.
• Staying the best engineer. A CTO who writes most of the critical code becomes the bottleneck the team needed them to remove.
• Security as a later phase. Customer reviews, contract commitments and open findings do not wait for day 90.
• Targets before baselines. Imported targets from a previous company say little about this team's starting point.

Adapting the plan

• Early-stage, hands-on CTO: expect to write code and carry on-call; keep the baseline light and put hiring the first engineering manager in days 31-90.
• Scale-up: weight days 31-60 toward hiring, levels and the product-engineering agreement.
• Replacing a founding CTO: agree the founder's ongoing role in week one, and treat their knowledge as a risk to capture, not a rival plan.
• CTO who also owns internal IT: add the portfolio and spend mapping from the CIO plan.

The general structure for any role is in the 30-60-90 day plan template for new hires.