"how do I know if my CTO is underperforming"

"The clearest signals are engineers losing confidence in technical direction, the CTO being consistently unable to explain decisions to you in plain terms, and repeated delivery failures with no coherent diagnosis. Normal growing pains look different — they're temporary, bounded, and the CTO can articulate what's causing them and what's being done about it."

How to Tell If Your CTO Is in Over Their Head

You’ve had this feeling for a few months. Things take longer than they should. Engineers seem frustrated but you can’t pin down why. Your CTO is defensive when you ask hard questions. You’re not sure if you’re missing something technical or if something is actually wrong.

This is one of the harder situations a CEO faces, because you’re trying to evaluate a domain you don’t fully understand. And the stakes are high — if you’re wrong in one direction, you blow up a good CTO relationship. If you’re wrong in the other direction, you let a real problem fester until it costs you significantly more to fix.

I’ve been asked to do informal assessments of CTOs more times than I can count. Here’s how to read the signals clearly.

The Signals That Actually Matter

Engineers are going around your CTO, not through them

When your best engineers are finding ways to bring technical decisions directly to you, or to product leadership, or to each other without including the CTO — that’s a trust signal. Engineers know. They work with this person daily. When they stop deferring to their technical leader, they’re voting with their behavior.

Ask yourself: when was the last time an engineer enthusiastically credited the CTO for a technical direction? If you can’t remember, that’s meaningful.

Your CTO can’t explain their decisions in plain terms

Technical complexity is real. But a strong CTO should be able to explain why a major decision was made — what was considered, what was traded off, why this path over that one — in terms you can understand and evaluate.

If the answer to your questions is consistently “it’s complicated” or jargon you’d need a CS degree to parse, that’s not depth. That’s either unclear thinking or an unwillingness to be accountable for decisions. Both are problems.

A CTO who understands what they’re doing can always explain it to a CEO who’s paying attention. “We chose to rebuild the service layer because the current architecture can’t support concurrent users past 10K, and we’re approaching that limit. The work will take six weeks and unblock three roadmap items.” That’s explainability. Compare it to: “We’re doing some refactoring on the service layer as part of our ongoing technical health work.” One of those is leadership. The other is deflection.

Delivery misses are unexplained or attributed to the wrong cause

Every engineering team misses estimates. That’s not a CTO performance problem by itself. The performance question is: can your CTO accurately diagnose why delivery is slow and demonstrate that they’re addressing the actual cause?

If the answer to every missed deadline is “the engineers need to work harder” or “the scope changed,” you have a problem. Those might be true sometimes. They’re never true every time. A CTO who can’t distinguish between a scope problem, an estimation problem, a technical debt problem, and a team capacity problem doesn’t actually understand what’s happening in their own organization.

You’re learning about technical problems from engineers, not your CTO

Bad news should travel up. If your engineers are telling you about production incidents, security issues, or architectural blockers before your CTO does — or instead of your CTO — you have a communication breakdown that reflects on leadership.

This isn’t just an information flow problem. It means your CTO either doesn’t have full situational awareness of their own organization, or they’re managing information in a way that prioritizes their own comfort over your ability to make good decisions. Both are disqualifying at the leadership level.

What Normal Growing Pains Look Like

Before you act, be honest about whether any of this is just the company scaling faster than the systems.

A good CTO at a fast-growing company will have some hard quarters. Recruiting will lag. Technical debt will accumulate faster than it gets paid. There will be a messy period after a reorg or a major product pivot. These things are normal.

The difference between a CTO who’s growing through hard things and one who’s in over their head is this: the growing CTO can tell you exactly what’s happening, why, and what the plan is to get through it. They’re ahead of the problem diagnostically, even if they’re behind operationally. And when they say “this will take three months to fix,” you believe them because their track record earns your trust.

If you don’t trust the diagnosis and the plan, that’s the real signal.

What To Do Once You’ve Confirmed It

Don’t let it linger. Every month of tolerated underperformance at the CTO level costs you in engineer retention, delayed features, bad decisions that compound, and the credibility hit when you finally act and your team wonders why you waited.

If you want to give it a chance to improve: be direct. Tell them exactly what you’re seeing and what needs to change in 90 days. Put it in writing. Get their response. You’ll learn a lot from how they react to directness — whether they own it or deflect tells you most of what you need to know.

If you’re past that point, plan the transition carefully. The worst outcome is a chaotic departure that panics the engineering team. Identify your interim plan before you have the conversation. Know how you’ll handle the first week without them.

This is one of the situations where a fractional CTO adds real value — both in helping you assess whether the concern is valid and in managing the transition if it is. If you’re trying to work through this right now, a 15-minute call is a good place to start.