What Should a New CTO Do in the First 90 Days: A Survival Guide

Every new CTO — hired externally, promoted internally, or fractional — walks into a system they don't fully understand, a team they don't yet know, and a set of expectations that may not match reality. The first 90 days determine whether you build credibility and momentum or create resistance and confusion.

I've done this transition many times, both as the incoming leader and as the advisor coaching someone through it. Here's the framework that works.

Days 1-30: Listen

The single most important thing you can do in the first month is resist the urge to change anything. You don't understand the system yet. You don't understand the team dynamics. You don't understand why things were built the way they were built. Every early change risks undoing something that was done for a reason you don't yet appreciate.

Meet every engineer 1-on-1. Not a group meeting. Not a town hall. Thirty minutes, one-on-one, with every person on the engineering team. Ask the same questions: What's working well? What's frustrating? If you could change one thing, what would it be? What should I know that nobody's going to volunteer?

The answers will cluster. Three to five themes will emerge consistently. Those themes are your initial priority candidates — not because you've validated them yet, but because they represent the team's lived experience of what's broken.

Read the code, but don't judge it. Pull up the core modules. Read the deployment pipeline. Review the last 20 pull requests. Look at the test coverage. Read the incident history for the past 6 months. You're building a mental model of the system, not evaluating quality yet. Every codebase looks terrible to fresh eyes. Understanding why it looks the way it does is more important than cataloging what's wrong.

Shadow the deployment process. Watch a deployment happen. Don't just read the documentation — sit with the person who deploys and watch every step. How long does it take? How much is automated? Where are the manual steps? What does the team do when a deployment fails? This single observation tells you more about the team's engineering maturity than any assessment framework.

Days 31-60: Assess

Now you have enough context to form opinions. Distill what you've learned into three documents:

Top 3 risks. What could go wrong that would damage the business? Security vulnerabilities, single points of failure, key-person dependencies, compliance gaps, scalability limits. These are the things that need to be addressed urgently, regardless of the roadmap.

Top 3 opportunities. Where can technology investment create the most business value in the next 6 months? This might be deployment automation (shipping faster), monitoring improvements (finding problems before customers do), or architectural changes that unblock a specific business capability.

Team capability assessment. What can this team actually do? Not what the org chart says, not what the job titles imply, but what the team's demonstrated capabilities are based on what they've shipped, how they've shipped it, and how they've handled incidents. Where are the skill gaps? Where are the hidden strengths?

Days 61-90: Act

Present your assessment to the CEO and your proposed 6-month plan. The plan should include: immediate risk mitigations (things that need to happen in the next 30 days), organizational changes (hiring, team restructuring, process changes), and the first 2-3 initiatives that demonstrate progress.

The first visible wins matter enormously. Pick 1-2 improvements that the team has been asking for and that you can deliver quickly. Fix the CI pipeline that everyone complains about. Automate the deployment step that requires 3 people. Resolve the monitoring gap that caused the last customer escalation. These wins build credibility and demonstrate that the new leadership actually listens and acts.

The Traps

Don't rewrite the stack. Every new CTO looks at the existing code and thinks "I would have done this differently." That's not a reason to rewrite. The existing system works well enough to have gotten the company to where it is. Improve it incrementally, or replace specific components when there's a clear business justification.

Don't hire your friends immediately. The temptation to bring in "your people" is strong, and sometimes it's the right call. But hiring your former colleagues in the first 60 days, before you've assessed the existing team, signals that you don't trust the people who built the company. Give the current team a fair chance. You might be surprised.

Don't skip the listening phase. If you're feeling pressure to "show results quickly," remember that uninformed action is worse than no action. A wrong architectural decision made in week two because you didn't understand the constraints will cost more to fix than whatever you would have gained by moving faster.