SalesArmor
Try Free

Discovery Questions

Discovery Questions for a CTO: 25 Questions That Get Real Signal (2026)

CTOs are technical, and they detect generic discovery in seconds. “What are your priorities this year?” gets you a polite non-answer and a shorter call. The right questions surface architectural pain, vendor frustration, and engineering-team load — the things a CTO actually thinks about between meetings. Below are 25 questions, grouped by category, that get real signal. Use them as a toolkit, not a script. Pick the four or five that fit the conversation, and earn the right to ask the harder ones with your follow-ups.

Why CTO Discovery Is Different

CTOs evaluate the rep on technical literacy in the first three questions. If your opener could have been asked of any executive in any function, the CTO has already filed you under “commodity vendor” and is mentally drafting the polite exit. Asking “tell me about your stack” wastes time when BuiltWith, Wappalyzer, or a five-minute look at their engineering blog would have shown you. Asking “are you using AI?” in 2026 is a punchline.

The good questions are about what the stack diagram doesn't show — pain, on-call burden, technical debt, vendor regret, the integration that keeps breaking, the project the CTO would do over if they could. CTOs respect specificity and they respect being asked things their direct reports actually argue about. Your job is to get them talking about the parts of the org they don't put in the all-hands slides.

The 25 Questions, By Category

Five categories, five questions each. Don't use them all in one call. Pick the category that maps to your product and lead with two or three; the others are follow-ups when the conversation opens up.

Architecture and Technical Debt

  1. Which part of your current architecture creates the most on-call pages?
  2. What's the largest piece of technical debt you'd retire if you had a quiet quarter?
  3. Where's your stack least defensible if a competitor catches up?
  4. Which system would you rebuild from scratch if you could?
  5. What's the integration that breaks the most often?

Engineering Productivity and Team Load

  1. How many eng-hours per month does your current solution eat in maintenance?
  2. What percentage of your team's capacity goes to glue code vs. shipping product?
  3. Where does engineering get pulled in to fix something that should self-serve?
  4. If you could give your senior engineers one hour back per week, what would it be worth?
  5. What's the bottleneck in shipping — code review, testing, deploys, or something else?

Vendor and Build vs. Buy

  1. What was the last “build vs. buy” decision your team made and how did it land?
  2. Which vendor in your stack do you most regret choosing — and why?
  3. Where are you building something internally that you wish you weren't?
  4. What's your tolerance for vendor lock-in vs. portability?
  5. How do you decide when to deprecate a vendor relationship?

Security and Compliance

  1. What compliance certifications are required for any vendor you onboard?
  2. Where in your stack are you most exposed if there's a security incident?
  3. How long does a typical security review take with a new vendor?
  4. What was your last close call on a security or data issue?
  5. What does your data residency requirement look like?

Decision and Timeline

  1. Who else on your team needs to weigh in before a tool gets adopted?
  2. What's your standard evaluation process for a new vendor of our size?
  3. When you've adopted similar tools before, what made adoption succeed or fail?
  4. What's the trigger event that would move this from “nice to have” to “this quarter”?
  5. If we did a proof-of-concept, what would success look like at week 4?

How to Use These Without Sounding Like a Checklist

The fastest way to ruin good questions is to read them in order. CTOs can hear a rep working down a list, and the moment they hear it, they stop giving you real answers. Pick a category, ask one strong question, then weave the next two or three around what they actually said. If they tell you their biggest on-call source is a flaky third-party integration, your follow-up isn't the next question on the page — it's “how often does that wake somebody up, and who owns the runbook?” The list is the toolkit. The conversation is the work.

Demonstrate technical literacy in your follow-ups, not your openers. If they mention they're running on Kubernetes and the cost has been creeping, you don't need to recite the CNCF landscape — just ask whether the creep is compute, egress, or storage, and whether they've tried right-sizing or moved to spot. That single follow-up tells the CTO you've been near a real production system. One specific question beats five general ones.

Don't fake expertise you don't have. CTOs would rather work with a curious non-engineer than a rep cosplaying as one. If they say something you don't fully understand, the right move is “I want to make sure I'm tracking — when you say [X], do you mean [Y] or [Z]?” That's how engineers talk to each other. Pretending costs you the deal the second they probe.

What NOT to Ask a CTO

  • ✗ “Tell me about your tech stack.” Do your homework. BuiltWith, their engineering blog, and their job postings tell you 80% of what you need before the call.
  • ✗ “Are you the decision maker?” Insulting and lazy. Ask who else weighs in instead — same information, no offense.
  • ✗ “What keeps you up at night?” The cliché every CTO has heard 200 times. They'll give you a vague answer and check the clock.
  • ✗ “How much do you spend on X?” They won't answer this cold. Earn the budget conversation by demonstrating value first.
  • ✗ “Are you using AI?” In 2026, this is the question every commodity rep opens with. Ask something specific or skip.

Practice These Questions on an AI CTO

Run a live voice roleplay against an AI CTO who pushes back on lazy questions and rewards specificity. Free to try — no credit card.

Practice These Questions on an AI CTO →