The First 90 Days as a Startup CTO: A Playbook

You just became CTO of a startup. Maybe you were promoted from the engineering team. Maybe you were hired externally. Maybe you co-founded the company and the title just became real. Whatever the path, the first 90 days will define your credibility, your relationships, and the technical direction of the company.

Here is the playbook.

Days 1-30: Listen and learn

The biggest mistake new CTOs make is changing things too fast. You do not understand the system yet. You do not understand the team dynamics. You do not understand the business constraints that led to the decisions you are about to judge.

Week 1: Meet everyone. Schedule 30-minute 1-on-1s with every engineer, every product manager, and every member of the leadership team. Ask the same questions: What is working well? What is broken? If you could change one thing, what would it be? What should I know that nobody will tell me unless I ask?

Week 2: Understand the system. Read the codebase. Not all of it, but enough to understand the architecture, the patterns, and the quality. Deploy the application locally. Walk through the CI/CD pipeline. Review the monitoring dashboards. Understand the infrastructure. You need hands-on familiarity with the system you are responsible for.

Week 3: Understand the business. Sit in on sales calls. Read customer support tickets. Understand the pricing model, the competitive landscape, and the fundraising timeline. Technical decisions exist in a business context, and the best CTOs make decisions that serve both technical excellence and business outcomes.

Week 4: Synthesize. At the end of month one, you should be able to articulate: the top 3 technical risks, the top 3 team challenges, the top 3 opportunities for improvement, and the things that are working well and should not be changed.

Days 30-60: Quick wins and foundation

Now you have enough context to start making changes. But start small. Quick wins build credibility. Big reorganizations on day 31 signal that you were not listening during month one.

Fix something visible. Pick the most annoying problem the team mentioned in your 1-on-1s and fix it. Maybe it is a flaky CI pipeline. Maybe it is a missing staging environment. Maybe it is a broken deployment process. Fix it. Ship the fix. Let the team see that their feedback led to action.

Establish your communication cadence. Set up: weekly 1-on-1s with every direct report, a weekly engineering meeting (30 minutes, updates and coordination), a weekly leadership meeting with the CEO and other executives, and a monthly engineering all-hands (optional at small scale).

Audit the fundamentals. Review: backup and recovery procedures (test a restore), security posture (MFA, encryption, access controls), monitoring and alerting (is it working? are alerts actionable?), and incident response (does a plan exist? has it been tested?).

Start building the roadmap. Based on your assessment, create a 90-day technical roadmap. Share it with the CEO and the team. It should cover: the top 3 technical investments you plan to make, the business outcomes each one enables, and the resources required.

Days 60-90: Build momentum

Execute the roadmap. You should be delivering against the roadmap by now. Whether it is migrating to infrastructure as code, implementing CI/CD, setting up monitoring, or paying down critical tech debt, the team should see tangible progress.

Define engineering culture. Write down the principles that guide engineering decisions at the company. Keep it to 5-7 principles. Examples: "We ship small, frequent changes," "We write tests before we write code," "We own what we build," "We document decisions." Share these with the team and reference them when making decisions.

Build the hiring plan. Based on the product roadmap and the technical roadmap, create a hiring plan for the next 6-12 months. Include: roles needed, level requirements, timeline, and budget. Present this to the CEO as part of your business case for the engineering investment needed to hit company goals.

Establish your relationship with the CEO. By day 90, you and the CEO should have a productive working rhythm. They should trust your technical judgment. You should understand their business priorities. You should be able to have honest conversations about tradeoffs between speed, quality, and cost.

What to avoid

• Rewriting the codebase. The urge to rewrite everything is strong. Resist it. Improve incrementally. Rewrites are almost always more expensive and more risky than the team estimates.
• Changing the tech stack. Switching from Python to Go because you prefer Go is not leadership. It is personal preference at the company is expense. Change the stack only when there is a clear business justification.
• Ignoring the people side. Your job is not just technical decisions. It is building and leading a team. If you spend all your time on architecture and none on people, you will build great systems with a team that is falling apart.
• Over-engineering. You were hired to build for the company is current stage, not for the stage it might reach in 3 years. Build for 10x current scale, not 1000x.