Questions to Ask CTO
Questions for talking to the CTO at your own company: a skip-level one-to-one, a new joiner's intro chat, or the half hour you get after a review. They are aimed at understanding how decisions really get made and what the person is worried about, not at making an impression.
The questions
Open any question for the note
What are you spending most of your own time on this quarter?
Why ask it
This is a better opener than asking about strategy, because it shows you where their attention actually goes: hiring, a single customer, a migration, or board work. If the answer is far from what the team thinks the priority is, that gap explains a lot of the friction you have been feeling.
What are we saying yes to this year that we said no to last year?
Why ask it
Framing it as a change forces a specific answer instead of a restatement of the roadmap. It also reveals whether the shift came from a customer, the board or a competitor, which is usually more useful than the shift itself.
Which of our systems worries you most?
Why ask it
Most CTOs have a private list and will share it if asked plainly. Hearing it lets you judge whether the thing your team complains about weekly is on their radar, and it is often the fastest route to work that will be supported.
How do architecture decisions get made now that the team is this size?
Why ask it
Companies outgrow their decision-making quietly, and the CTO usually knows the current process is strained before anyone says so. A clear answer names a person or a forum; a vague one is an invitation to propose something.
How do you find out when something is going wrong, and how long does that usually take?
Why ask it
The route information travels tells you whether bad news reaches them through dashboards, managers, or a customer complaint. A CTO who says they usually hear late is telling you something important about the reporting culture, and about how much they would value hearing from you directly.
Where are we spending engineering effort you would not choose to spend again?
Why ask it
This is the sunk-cost question, and the answer is often a project everyone privately doubts. It is also a rare chance to hear a leader be candid about a mistake still in progress, which tells you how safe candour is here.
Which decision from earlier in the company's life are we still paying for?
Why ask it
Every codebase carries one, and the story behind it usually explains constraints that look arbitrary from the inside. Notice whether they describe the original decision as reasonable at the time, because leaders who cannot do that tend to repeat the pattern in reverse.
What is the strongest case against our current roadmap?
Why ask it
Asking for the counterargument rather than the rationale tests whether they have genuinely considered one. A CTO who can state the opposing case well is someone worth bringing problems to; one who cannot has probably stopped hearing dissent.
What is the story you tell the board about engineering, and where is it thinnest?
Why ask it
This gets you the external narrative and its weak point in a single answer, which is exactly the information you need to make your own work legible. The thin part is usually where extra evidence would be genuinely welcome.
Does anyone own the infrastructure bill, and how much of it do you think is waste?
Why ask it
Cost is often nobody's job until it becomes a crisis, and the honest answer is frequently that they do not know. If that is the case, you have found an unclaimed piece of work with visible results, which is rarer than it sounds.
What does the executive team argue about most?
Why ask it
This is asking for the shape of the disagreement, not for gossip, and most CTOs will answer at the level of themes: pace against reliability, or which segment to serve. Knowing the live argument tells you which proposals will be easy and which will stall regardless of merit.
Which part of the company do you understand least well?
Why ask it
It is a disarming question and the answer is usually honest, often support, finance or a particular market. It also tells you where an explanation from your side would land as useful rather than as noise.
What do you wish engineers brought to you more often, and what less?
Why ask it
The second half is the useful half, because it is the only polite way to find out whether the thing you were planning to raise is the thing they are tired of hearing. Expect the answer to distinguish between problems with a proposal attached and problems without one.
How would you like people to disagree with you?
Why ask it
Leaders differ genuinely here: some want it in the room, some in writing beforehand, some privately afterwards. Asking removes the guesswork, and it is worth checking the answer later against what actually happens when someone does disagree.
What do you look for when you decide someone is ready for more scope?
Why ask it
This is more useful than asking about promotion criteria, because it gets at the informal judgement that precedes any formal process. Listen for whether the signals are about output, about other people improving around them, or about how someone handled one bad situation.
How do you decide who gets the interesting projects?
Why ask it
Every engineering organisation allocates the good work somehow, and it is rarely written down anywhere. An honest answer might be uncomfortable, mentioning proximity or past delivery, and that is still better to know than to guess at.
What do people here believe about you that is not true?
Why ask it
Leaders are usually aware of at least one persistent misreading of themselves, and correcting it is a relief. The answer often explains behaviour that looks like indifference from a distance, such as absence from a project or silence on a proposal.
What would you want to be true about this team in two years that is not true now?
Why ask it
This is the ambition question without the vocabulary of vision statements, and the answers tend to be concrete: shipping without heroics, or not needing them in every escalation. It also tells you what kind of contribution would count as valuable rather than merely visible.
What would have to happen for you to call this a good year?
Why ask it
Because they will name two or three things, you learn their real priorities in ranked order. If your current project appears nowhere in the answer, that is information you should act on rather than resent.
What could I do that would make your job easier?
Why ask it
Kept for last, this converts everything you have heard into something actionable and is very rarely asked. A specific request in reply is a good sign; a polite deflection usually means they have not thought about your role in much detail, which is itself worth knowing.
How to use these questions
Practical guidance for the conversation itself
Getting something out of the conversation
Bring one observation, not just questions
Skip-levels go better when you contribute something the CTO cannot see from where they sit: a pattern in support tickets, a place where two teams duplicate work, a reason a deadline slipped. It changes the meeting from an interview into an exchange.
Pick two questions and let them run long
A half hour holds two real subjects. Choose the two whose answers would change what you do next week, and resist the urge to cover ground you could read in a company update.
Ask about worries rather than plans
Plans are already published; worries are not. Questions about what is fragile, expensive or overdue get you information you cannot get anywhere else and usually produce the most engaged part of the conversation.
Write down what you heard the same day
The useful details are specific: a number, a system name, a named forum where decisions happen. Six weeks later you will remember the tone and none of the specifics unless you wrote them down.
What the answers usually tell you
- The distance between their stated priorities and what your team is working on. That gap explains most unexplained friction.
- Whether they can state the case against their own plan. If not, dissent has probably stopped reaching them.
- How they describe other executives. Precision and fairness here suggest disagreements get resolved rather than accumulated.
- Whether they know numbers about their own organisation, such as spend, turnover or delivery. Absence is not damning but it tells you what is not being watched.
- What they ask you. A CTO who spends half the meeting asking questions is using the time better than one who spends it presenting.
Common pitfalls
Using a skip-level to go around your manager
Complaining about your direct manager to their boss almost always gets relayed back, and it damages the relationship you have to work in daily. If the problem is genuinely with your manager, raise it as a specific, dated account rather than as an impression, and expect it to be discussed with them.
Asking things that were answered at the all-hands
It signals you were not paying attention and wastes a scarce half hour. Reference what was said and ask about the part that was left out instead.
Turning it into a pitch
Arriving with a proposal you want approved changes the dynamic and closes off the more useful conversation. Ask about the constraints first; the proposal will be better for it and can go in an email afterwards.
Forgetting the power difference
However friendly the conversation, this person influences your pay and your prospects. That is not a reason to be guarded, but it is a reason to be careful about naming colleagues critically.
Follow-ups worth keeping ready
- "Who owns that at the moment?" The quickest way to find unclaimed work.
- "What have you already tried?" Prevents you from proposing something that failed last year.
- "How would I know if that was getting better?" Turns a stated priority into something measurable.
- "Would it help if I wrote that up?" A low-cost offer that often turns a conversation into an actual assignment.