You just walked into a codebase you didn't build, a team you didn't hire, and years of decisions you weren't part of. Everyone has opinions about what's wrong. You have no independent way to verify any of it.
This is the inheritance problem. Every new CTO faces it. The wiki is out of date. The architecture diagram on the wall describes a system from two years ago. Three senior engineers hold all the institutional knowledge, and each one has a different version of history.
You're expected to form a strategy. Build a roadmap. Make investment decisions. And you're doing it based on tribal knowledge, good intentions, and whatever the previous CTO left behind.
The listening phase
Days 1 through 30. You're doing the right things. Meeting people. Sitting in stand-ups. Reading code. Building trust. Every experienced CTO knows this phase matters. You can't lead a team you don't understand.
But there's a trap in the listening phase. You're collecting opinions. The front-end team thinks the API layer is the problem. The back-end team thinks the front-end is the bottleneck. The product team thinks engineering is slow. Engineering thinks product keeps changing requirements.
Everyone is telling you what they believe. Nobody is showing you evidence. And you don't have enough context yet to know who's right.
The temptation
Around week four, the temptation arrives. You've heard enough to form an opinion. The architecture has obvious issues. The deployment process is manual. The test coverage is thin. There's a framework migration someone started and never finished.
The temptation: big rewrite. New framework. Platform modernization. Start fresh.
It feels decisive. It signals change. It's also the highest-risk move you can make in your first 90 days. Because you don't know enough yet. You don't know which parts of the system are genuinely broken and which ones are ugly but stable. You don't know which technical decisions had business reasons you haven't heard yet. You don't know where the real constraints are.
New CTOs who launch major rewrites in the first quarter have a pattern: they solve the wrong problems first and discover the real problems later.
What you actually need
An independent read of what you inherited. Not opinions. Not the team's version or the board's version or the previous CTO's version. Evidence.
What's the real architecture? Not the diagram. The actual dependency graph, the actual data flow, the actual deployment topology. Where is knowledge concentrated? Which systems are understood by one person? Where is the drift between what was intended and what was built?
The five questions for your first 90 days
- Where is knowledge concentrated? Map who built what, who maintains what, who gets called when it breaks. Git history tells this story precisely. If three people account for 80% of commits to critical systems, that's your biggest operational risk. Not because they're bad engineers. Because if any of them leave, you lose capability you can't replace quickly.
- What's the real architecture? Not the slide deck. The actual system. How do services communicate? Where does data flow? Which components are tightly coupled? Where are the bottlenecks? You need a map that reflects reality, not aspiration.
- How much drift exists? Drift between the stated architecture and the actual architecture. Drift between the compliance requirements and the implementation. Drift between where the team says they spend time and where the commit history shows they spend time. Drift is normal. Unmeasured drift is dangerous.
- Where does the team actually spend time? This is the maintenance ratio question. What percentage of effort goes to new capability versus keeping existing systems running? The board thinks engineering is building the future. The commit log often tells a different story. You need to know the real number before you can plan anything.
- What are the hidden liabilities? Open-source license exposure. Security vulnerabilities in the dependency tree. Compliance gaps between policy and implementation. Dead code that's still in production. These don't show up in sprint demos. They show up in audits, breaches, and acquisition due diligence.
The value of an external view
Getting an independent assessment in your first 90 days isn't a vote of no confidence in the team. It's intelligence for leadership.
The team built the system. They know its strengths and weaknesses better than anyone. But they also have blind spots. They've normalized workarounds. They've accepted constraints they no longer question. They have opinions shaped by years of context you don't share.
An external assessment gives you something the team can't: a view unclouded by history. Here's what the code says. Here's where the risk is. Here's what it would cost to address. No politics. No turf. Just evidence.
"The best new CTOs don't come in with answers. They come in with the right questions and an independent way to verify the answers."
The 90-day baseline
Here's the pattern we see with new CTOs who get it right. In the first 90 days, they establish a baseline. Not a strategy. Not a roadmap. A baseline.
They know where knowledge is concentrated. They know the real architecture. They know the maintenance ratio. They know the compliance gaps. They have this in writing, with evidence, not as tribal knowledge.
From that baseline, everything else follows. The roadmap becomes credible because it's based on reality. The investment asks are defensible because the risks are quantified. The relationship with the board is grounded in evidence, not reassurance.
New CTOs who get an independent baseline in the first 90 days make better decisions for the next two years. Not because the assessment tells them what to do. Because it tells them what's actually true. And you can't lead effectively from a foundation of assumptions.
We give new technology leaders an independent view of what they've inherited. Risk, exposure, knowledge concentration, architecture reality, compliance gaps. Evidence they can act on. So the first big decisions are the right ones.