CTO First 90 Days at a Mid-Size Company: The Practical Playbook

The first 90 days as CTO at a mid-size company (50-500 engineers) set the trajectory for the next several years. The CTO who uses the period well builds the relationships, gains the context, and makes the early decisions that compound. The CTO who doesn’t spends the next two years undoing first-impression mistakes.

This post walks through the discovery cadence and decisions that compound, based on multiple client engagements during executive transitions.

What the first 90 days are really for#

The first 90 days are not for substantial reorganization. They’re for context-building, relationship-establishment, and selective intervention on the most-urgent issues.

The new CTO who immediately reorganizes signals they don’t trust the existing team. The CTO who immediately picks technology fights makes enemies without yet earning credit. The CTO who immediately commits to new initiatives makes promises before understanding what’s possible.

The CTO who listens, learns, builds relationships, and intervenes only where intervention is genuinely urgent earns credibility that supports later substantive changes.

Week 1-2: Initial discovery#

Listening tour. Meet every direct report individually, plus key skip-levels, key cross-functional partners (CPO, CEO, CFO, head of sales), and key external partners. The questions:

• What’s working well that should continue?
• What’s not working that needs to change?
• What are you proud of?
• What worries you?
• What do you wish the previous CTO had done differently?

Take notes. Look for patterns. Identify who’s well-regarded, who’s struggling, where the energy is, where the dysfunction is.

Stakeholder relationship building. Establish working relationships with key partners. CEO weekly 1:1 should be solid by end of week 2. CPO relationship should be developing. CFO interaction patterns established.

Code base and architecture walk-through. Spend serious time understanding what’s actually deployed. Pair with senior engineers. Read recent design docs. Walk through the system from front to back.

Production observation. Sit in on incidents if any occur. Observe the on-call rotation. Read the most-recent retrospectives. Understand how operational quality actually is.

Don’t make commitments yet. Resist the temptation to say “we’ll do X” before you understand what’s possible.

Week 3-6: Deeper discovery#

Customer conversations. Talk to customers. Talk to the customer-facing teams. Understand what customers actually love and hate about the product. Listen for technical signals (perf issues, reliability complaints, feature gaps).

Detailed technical audit. Walk through the major systems with their owners. Understand the architecture, the technical debt, the operational characteristics, the cost structure. Look for systems that are too fragile, too expensive, or too slow.

Team and capability assessment. Identify the strong contributors at each level. Identify the gaps — capabilities the team needs but doesn’t have. Identify the people who are struggling, whether they need development, role changes, or transition.

Roadmap and commitment review. What has product been promised? What has been committed externally (board, customers, investors)? What’s the realistic engineering capacity to deliver these?

Cost analysis. What does the engineering organization actually cost? People, infrastructure, vendor tools, contractors. Where is the spend concentrated?

Week 7-12: Decision-making and selective intervention#

The critical priorities. Based on discovery, identify 3-5 critical priorities for the next 6-12 months. These are the things that matter most, that you’ll personally champion, and that you’ll allocate substantial resources toward.

Selective intervention. If there are urgent issues that require immediate action (critical outages, failing project, departing key person), address them. Don’t wait. But intervene only where intervention is genuinely urgent.

Quick wins. Identify a few quick wins — small but visible improvements that demonstrate forward motion. Builds credibility before substantive changes.

Communication to the team. End of 90 days, communicate your assessment and priorities to the engineering organization. Be honest about what’s working and what’s not. Be specific about priorities.

Communication to executive peers. Same communication to CEO, CPO, CFO. Make the priorities visible.

Begin substantive changes. With 90 days of context, begin the substantive changes that the discovery surfaced. This is where the next year of work starts.

What to avoid#

Several patterns consistently produce 90-day failures.

Reorganization within first 60 days. Without context, reorganizations are guesses. The new structure doesn’t match the actual work; people who were performing well get demoted; people who were marginal get promoted. The reorg destroys trust before any benefit accrues.

Technology fights. Picking battles over technology stack (Java vs Python, AWS vs GCP, microservices vs monolith) before understanding the context produces enemies without earning credit.

Public criticism of predecessor. Even if the predecessor was bad, public criticism makes the new CTO look insecure. Focus on forward direction.

Solo decision-making. New CTO making major decisions without input demonstrates they don’t trust the team. The decisions get worse outcomes than collaborative versions would.

Surface-level engagement. New CTO who skims rather than dives produces shallow context. The 90 days are an investment that pays off for years; substantial engagement is necessary.

The relationship dimensions#

Beyond technical context, several relationship dimensions matter.

CEO trust. The CTO-CEO relationship is the single most-important. Without CEO trust, every CTO decision is second-guessed. With it, the CTO has substantial latitude.

CPO relationship. The CTO-CPO relationship determines product-engineering trust (covered here). Substantial joint behavior signals to the organization.

Engineering leadership team. The relationship with direct reports determines whether they buy into the new CTO’s priorities or resist them.

Cross-functional peers. Sales, marketing, finance, operations — all relationships affect engineering outcomes.

Board relationship. Depending on company structure, the CTO may need direct board relationship. The 90 days establish whether this works.

The communication discipline#

Communication during the 90 days has specific patterns:

Listening more than talking. New CTO who talks more than listens learns less.

Asking specific questions rather than vague ones. “What specifically is blocking the database migration?” rather than “What’s going on with the database?”

Reflecting back understanding. “Let me make sure I understand — you’re saying X. Is that right?” Verifies context.

Documenting what you learn. Notes after each conversation. Patterns become visible across conversations.

Where pdpspectra fits#

Our architecture practice supports technology leadership transitions including diligence work, capability assessments, and operating-model engagements during 90-day periods and beyond.

Related reading: the tech stack audit post, the cross-functional trust post, and the communicating tech risk post.

---

The first 90 days compound for years. Talk to our team about your transition.