10 Better Questions to Ask Your CTO

How the questions you ask shape the answers you get—and the relationship you build

Most CEO-CTO relationships break down not because of competence issues, but because of communication misfires. The CEO asks surface-level questions. The CTO gives surface-level answers. Both walk away frustrated, and the real issues stay buried.

Here’s the thing: your technology organization is a complex adaptive system. You can’t see everything happening inside it. But the questions you ask determine what you can see and whether your CTO feels safe enough to show you the truth.

The wrong questions trigger defensiveness. They push CTOs into justification mode, where they’re explaining symptoms rather than diagnosing causes. The right questions open doors. They invite collaboration instead of confrontation.

What follows are ten reframes—ten shifts from the questions CEOs typically ask to the questions that actually unlock insight. These aren’t just semantic tweaks. They represent a fundamentally different way of understanding technology organizations.

From Blame to Diagnosis

Instead of: “Why is this taking so long?”

Ask: “What’s creating friction in the system right now?”

“Why is this taking so long?” sounds like a reasonable question. It’s not. It’s an accusation dressed up as curiosity. Your CTO hears it as: What’s wrong with you and your team?

The defensive response kicks in. You get explanations about complexity, dependencies, unexpected issues. All true, but none of it helps you understand what’s actually happening or what to do about it.

“What’s creating friction in the system?” shifts the frame entirely. It assumes there is a system, that friction is a property of that system (not a character flaw of your engineers), and that understanding the friction is the path to reducing it.

You might learn that developers are spending 30% of their time on manual deployments that could be automated. Or that three teams are blocked waiting on one overloaded architect. Or that the codebase has accumulated so much technical debt that “simple” changes now require touching dozens of files.

None of these are excuses. They’re diagnostics. And they point toward actual solutions.

The Brooks’ Law Conversation

Instead of: “Can we just hire more developers?”

Ask: “What needs to change before adding people would help?”

Fred Brooks identified this pattern in 1975, and it’s been true ever since: adding people to a late software project makes it later. Yet CEOs keep reaching for headcount as the default solution to velocity problems.

Here’s why it backfires. Every new engineer needs to learn the codebase, the domain, the team’s processes, and the unwritten cultural norms that govern how work actually gets done. That learning takes months, and during that time, your existing engineers are pulled off productive work to do the teaching. You’ve increased your burn rate while temporarily decreasing your output.

Worse, more people means more communication overhead. A team of 5 has 10 communication pathways. A team of 10 has 45. A team of 20 has 190. That combinatorial explosion is why throwing bodies at problems rarely works.

“What needs to change before adding people would help?” acknowledges this reality. Maybe you need to split a monolithic codebase into independent services that separate teams can own. Maybe you need to invest in documentation so new hires can onboard themselves. Maybe you need to automate the deployment process that’s currently eating 20 hours a week of senior engineer time.

Sometimes hiring is the right answer. But it’s almost never the first answer.

Learning Over False Precision

Instead of: “What’s the timeline?”

Ask: “What are we learning, and how is that changing our approach?”

Complex projects don’t unfold linearly. They evolve. What you learn in week three changes what you build in week eight. Pretending otherwise like demanding precise timelines for inherently uncertain work, forces your CTO into a choice between honesty and job security.

Most choose the middle path: they give you a timeline they know is probably wrong, then spend the next several months managing your expectations downward through a series of increasingly uncomfortable conversations.

“What are we learning?” reframes the relationship. It says: I understand that building software involves discovery. I want to know what you’re discovering and how it’s shaping our path forward.

This isn’t about abandoning accountability. You still need to ship. You still need to manage resources and commitments. But you’re acknowledging that the project management fantasy of perfect predictability was always just that—a fantasy.

The best CTOs will tell you: “We learned that our assumption about the third-party API was wrong, so we’re building an abstraction layer that adds two weeks but protects us from vendor lock-in.” That’s not a delay. That’s intelligent adaptation.

System State, Not Individual Performance

Instead of: “Is the team productive?”

Ask: “Where is our system boiling or frozen right now?”

Productivity is an individual lens on a systemic phenomenon. When a team struggles, it’s almost never because the people suddenly became worse at their jobs. It’s because the system they’re working within has shifted into a dysfunctional state.

Think of it like water. A healthy organization operates in a liquid state: flowing, adaptable, efficient. But under pressure, systems can shift into one of two failure modes.

Boiling happens when complexity overwhelms coordination. Everyone’s working hard, but nothing’s getting done. Priorities conflict. Dependencies cascade. Communication breaks down. It feels like chaos because it is chaos.

Frozen happens when regulation overwhelms flexibility. Process overhead buries actual work. Every decision requires six approvals. Innovation dies because experimentation is too risky within the bureaucratic structure.

“Where is our system boiling or frozen?” gives your CTO language to describe what they’re seeing without having to point fingers at individuals. Maybe the platform team is frozen in process while the product team is boiling in conflicting priorities. That’s actionable information. “The team isn’t productive” is not.

From Blame to Learning

Instead of: “Why didn’t we catch this sooner?”

Ask: “What signals did we miss, and how do we detect them earlier next time?”

The first question is an autopsy. It assigns blame for past failures. The second question is an investment in future capability.

Every failure is a signal your system didn’t detect or didn’t respond to. The question isn’t who screwed up. It’s why your detection mechanisms failed and how to improve them.

Amy Edmondson’s research on psychological safety shows that organizations learn fastest when people feel safe reporting problems early. “Why didn’t we catch this?” destroys that safety. It trains people to hide problems longer, which makes the eventual failures bigger and more costly.

“What signals did we miss?” treats the failure as data. Maybe you need better monitoring. Maybe information is getting stuck in silos and not reaching the people who could act on it. Maybe the signals were there, but competing priorities drowned them out.

These are system problems with system solutions. Blame solves nothing.

Strategic Capability Choices

Instead of: “Is our technology competitive?”

Ask: “What capabilities are we building vs. buying vs. ignoring?”

“Competitive” is too vague to be useful. Competitive with whom? On what dimension? By what measure?

The real strategic question is: where are you investing engineering effort? Every technology organization makes implicit choices about what to build in-house, what to buy from vendors, and what to simply not do. Making those choices explicit and intentional is a huge leverage point.

Building in-house gives you control and customization. It also costs more and takes longer. It makes sense for capabilities that differentiate you in the market.

Buying lets you move faster and focus engineering effort elsewhere. It also creates dependencies and limits flexibility. It makes sense for commoditized capabilities where being the same as competitors is fine.

Ignoring is a legitimate choice. You can’t do everything. What are you consciously choosing not to invest in, and what’s the risk profile of that choice?

This question opens a strategic conversation that “is our technology competitive?” simply can’t.

System Issues, Not People Issues

Instead of: “Do we have the right people?”

Ask: “Do we have the right boundaries and clarity for people to succeed?”

When performance problems emerge, the natural instinct is to question the performers. But most performance issues are system issues, not people issues.

Consider: the same engineer who’s struggling on Team A might thrive on Team B. What changed? Not their skills or work ethic. The context changed. The team dynamics, the clarity of ownership, the quality of processes, the alignment of priorities.

“Do we have the right boundaries?” asks whether teams have clear ownership and autonomy. Overlapping responsibilities create confusion and conflict. Unclear boundaries mean everyone’s stepping on everyone’s toes.

“Do we have the right clarity?” asks whether people understand what success looks like. Do they know what they’re supposed to be building? Do they understand priorities? Can they make decisions without escalating everything?

These are leadership and organizational design questions. The answer is almost never “fire everyone and start over.”

Optionality Over ROI

Instead of: “What’s the ROI on this project?”

Ask: “What options does this create or close for us?”

Technology investments are notoriously difficult to evaluate on pure ROI terms. The value often isn’t in the direct return. It’s in the strategic options the investment creates.

Rebuilding your architecture to be more modular might not have a clear ROI. But it might make you acquisition-ready. It might let you enter new markets faster. It might reduce your dependency on a single vendor who could raise prices or go out of business.

Conversely, some investments close options. Deep integration with a specific platform might deliver near-term efficiency while locking you into a relationship you can’t exit.

“What options does this create or close?” forces a strategic conversation about flexibility, risk, and positioning. The answer might be: “This investment creates the option to scale to 10x our current load, which we’ll need if the enterprise deal closes.” That’s a much richer conversation than arguing about payback periods.

The Hidden Debt Reveal

Instead of: “Are we on track?”

Ask: “What would you do differently if we paused features for two weeks?”

This question is a magic wand for surfacing hidden technical debt.

Every CTO is managing a backlog of deferred maintenance. Things they’d fix if they had time, but which keep getting pushed aside in favor of feature work. Asking “are we on track?” gives you no visibility into this invisible burden.

“What would you do with two weeks?” reveals it all. You might hear: “I’d fix the deployment pipeline that’s costing us eight hours of manual work every release.” Or: “I’d refactor the authentication system that’s a security risk and a development bottleneck.” Or: “I’d document the three services that only Sarah understands, so we’re not paralyzed when she takes vacation.”

This question also signals that you understand the tradeoffs. Feature velocity comes at a cost. Knowing what’s being sacrificed helps you make better decisions about when to pay down that debt.

Creating Psychological Safety

Instead of: “What do you need?”

Ask: “What do you need from me that you haven’t been able to ask for?”

“What do you need?” is a fine question, but it rarely surfaces the real blockers. Your CTO will give you the safe answer: more budget, more headcount, more time. The stuff that’s easy to ask for.

The harder stuff stays hidden. Maybe they need you to stop changing priorities every two weeks. Maybe they need air cover to push back on the sales team. Maybe they need you to trust them enough to stop micromanaging. Maybe they need you to fire the toxic senior engineer everyone’s afraid to confront.

“What do you need from me that you haven’t been able to ask for?” acknowledges that some requests feel too risky. It creates space for honesty about the real obstacles—which are often political, interpersonal, or cultural rather than resource-related.

This question takes courage to ask because you might not like the answer. But the blockers it surfaces are usually the ones that matter most.

The Questions Shape the Relationship

These ten reframes aren’t just conversation techniques. They represent a different mental model for how technology organizations work.

The old model treats technology like a factory. You put requirements in, features come out, and if the output is slow or defective, you fix the machine or replace the workers.

The new model treats technology like an ecosystem. Complex, adaptive, unpredictable but influenceable if you understand its dynamics. The CEO’s job isn’t to control the system (you can’t), but to create conditions where it can thrive.

The questions you ask reveal which model you’re operating from. And they shape whether your CTO sees you as a partner or an obstacle.

Choose wisely.

This article draws from concepts in Liquid: Navigating Complexity as Your Technology Business Grows.