Questions to Ask a CTO
Questions to ask a CTO in a meeting, most of them for the CTO of the company you work for: a skip-level one-to-one, a new joiner's intro chat, an open Q&A, or the half hour you get after a review. They begin with priorities, then cover the technology itself (debt, security, backups, cost and AI), how decisions really get made, the CTO's own career, and how to work well with them. The notes say what a full or a thin answer tells you, and the aim throughout is to understand what the person is worried about, not to make an impression. A chief executive who is not technical can put the Technology group to their own CTO as it stands. At a startup, the Priorities and Technology groups each close with questions for that stage: runway, promises made to early customers, shortcuts taken on purpose and who holds the accounts. The last group is for founders, chief executives and board members choosing a CTO for a startup or a growing company: what they still build, what they refuse to build, and how they handle deadlines, budgets and hiring.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Priorities
What are the top technical priorities for the next twelve months, and what narrowly missed the list?
Why ask it
The list itself is probably on a slide somewhere; the near-misses are not. Whatever just missed tells you what gets cut first under pressure, and what a little extra evidence might still move back up.
What keeps you up at night about our technology?
Why ask it
CTOs get asked this often enough that most have a real answer ready: a database nobody dares upgrade, a contract with an uptime clause, a platform that depends on two people. Compare it with what your own team grumbles about each week. If the two lists do not overlap, one of you is missing something, and it is worth finding out which.
Which company goal leans hardest on engineering this year?
Why ask it
A technology strategy only means something next to a business goal: a revenue target, a new market, a renewal the company cannot afford to lose. If the CTO names one quickly, work attached to it will get people and patience. A long pause can mean the plan was written inside engineering and handed upwards.
What are you spending most of your own time on this quarter?
Why ask it
A calendar is more honest than a strategy deck. The reply might be hiring, one large customer, a migration or board work, and it is often not what the team assumes. Where it differs from the published priorities, ask which of the two you should plan around.
Where do you want our technology to be in three years, and what has to change first?
Why ask it
A twelve-month plan is a list. Three years out you get a picture instead: fewer services, a platform other teams build on, a product that runs in a second region. Asking what has to change first shows whether that picture has a starting point or is still only a direction.
What would have to happen for you to call this a good year?
Why ask it
Most people name two or three things, and the order they come out in is the ranking. If your current project appears nowhere among them, treat that as something to act on, not something to resent.
What are we saying yes to this year that we said no to last year?
Why ask it
A change of mind is easier to describe than a plan, so you tend to get one concrete example: a customer segment, an integration, a rewrite that was refused twice. Then ask what tipped it. A customer, the board and a competitor are three different reasons, and each says who the roadmap is really answering to.
What is the strongest case against our current roadmap?
Why ask it
You are listening for whether a counterargument comes easily. Someone who can argue the other side well has been hearing from people who disagree, and is usually a safe person to take a problem to. If nothing comes, ask who inside the company last made that case.
Which project would you not start again, knowing what you know now?
Why ask it
Most roadmaps carry one piece of work that survives because of what has already been spent on it. A leader who will name it while it is still running is showing you how much candour the place can stand. Follow up with what they would need to see before stopping it, not with whether it will be cancelled.
What is a competitor doing technically that you take seriously?
Why ask it
Competitors tend to be waved away at the all-hands and studied in private, so a one-to-one is where you hear the real view. What they pick shows what they think the product competes on: speed, price, data or reliability. If nothing worries them, ask who the company last lost a deal to.
How does the amount of runway we have change what you are willing to build?
Why ask it
Money in the bank sets the length of bet a startup can afford, and a CTO who is close to the numbers will say which projects only make sense if the next round closes. If they do not know the runway, that is the thing to fix before anything on the roadmap.
What has been promised to a customer that the product cannot quite do yet?
Why ask it
Early sales often run a little ahead of the software, and the CTO is the one who knows by how much. Ask for the date attached to each promise. Selling next month's feature is ordinary at a young company, but the engineers should hear about it from inside the building and not from the customer.
Technology
How much technical debt are we carrying, and how do you decide when to pay it down?
Why ask it
Nobody claims to have none, so listen for the rule. A fixed share of each cycle, a named list with owners, and "when it breaks" are three very different policies, and only the first two give the work a place in a busy quarter. If you have one piece of debt in mind, name it and ask where it sits on the list.
Which decision from earlier in the company's life are we still paying for?
Why ask it
The story behind it often explains constraints that look arbitrary from the inside: a data model built for the first customer, a framework chosen because a founder knew it. Notice whether they call the original decision reasonable for its time. Someone who can be fair to an old choice is more likely to be fair about yours.
What have we built ourselves that you would simply buy today?
Why ask it
Build or buy is easier to talk about through a real example than as a principle. Home-grown deploy tools, billing code and internal admin panels come up often, and each one named is maintenance somebody is still doing. Ask what stops the switch; it is very often the cost of migrating.
What breaks first if usage grows ten times?
Why ask it
A CTO who still knows the system will name a component without hesitating: the main database, a queue, a nightly job that already runs for hours. That tells you how close to the detail they are, and the part they name is where scaling work will find a sponsor.
Which part of the system does only one person really understand?
Why ask it
Small teams nearly always have one: the billing code, the deploy scripts, an integration a contractor wrote and left behind. Naming both the person and the plan to spread the knowledge shows the risk is being managed. If the person is you, this is a graceful way to raise it.
If we found a breach tomorrow morning, who takes charge and what happens in the first hour?
Why ask it
Security policy is easy to describe and hard to check, but a first hour is concrete: who gets the call, who can shut things off, who tells customers. Named people mean the plan has been rehearsed. Notification duties differ by country and by contract, so it is fair to ask who knows which ones apply to you.
When did we last restore from a backup for real, and how long did it take?
Why ask it
A date and a duration mean somebody ran the drill. "We take them nightly" answers a different question, because a backup nobody has restored is only a hope. Ask out of curiosity and not as an audit: the gap is common and most CTOs know they have it.
Who owns the infrastructure bill, and how much of it do you think is waste?
Why ask it
Hosting and tooling costs are often nobody's job until finance asks about them, and a frank "I do not know" is a common reply. In that case you have found unclaimed work whose result anyone can read off an invoice. If they do give a figure, ask how they arrived at it.
How are we using AI in the product and in our own work, and where have you drawn the line?
Why ask it
Most CTOs now have a position on coding assistants, on customer data going to outside models, and on which features need a model at all. The line is the part to listen for, since a clear one means someone has thought about data and liability. If the policy is still being written, ask what people should do in the meantime.
Which new technology are you watching closely, and which are you deliberately ignoring?
Why ask it
Turning down a fashionable tool takes more thought than adopting one, so the ignore list is where the reasoning shows. You also hear how they evaluate things: a small trial with an end date, a trusted engineer's opinion, or whatever a vendor showed them last week.
Which shortcuts are we taking on purpose right now, and what would tell you it is time to go back and fix them?
Why ask it
A young company is right to skip some things, and a CTO who chose them can list them: thin tests, a single server, a release step done by hand. The trigger is what separates a decision from a habit, whether it is a customer count, a first large contract or a second engineer.
Who besides you can get into every account the product depends on?
Why ask it
Hosting, the domain name, the app store listing and the payment provider are often opened under one person's email in a startup's first weeks and never moved. This is about a lost phone or a sudden illness as much as a falling-out. A second named administrator on each account is a small job that tends to wait until it is urgent.
Who gets woken when something breaks at night, and is it always you?
Why ask it
In a team of three it usually is the CTO, which works for a while and then wears a person down. Ask what has to be in place before the load is shared: a second engineer who knows the system, alerts that say what is wrong, a written set of first steps. An early hire should ask it too, since the reply partly describes their own nights.
Does the company own all of the code, including what contractors and early helpers wrote?
Why ask it
Work done by a freelancer, an agency or a friend before the company was formed does not always belong to the company unless something was signed. That depends on the country and on the contract, so the useful reply is a list of who wrote what and where the paperwork is, with a lawyer's reading of anything unclear.
What would an investor's technical review turn up that you would sooner fix first?
Why ask it
Ahead of a larger funding round or a sale, someone from outside may read the code, the access list and the open-source licences in use. A CTO who has sat through one can usually name a few sore spots without being pressed. For a founder, the reply turns a vague worry into a short list with a cost against each line.
Decisions
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 often knows the current process is strained before anyone says so. A clear answer names a person, a written proposal or a regular review. A vague one is an invitation to suggest something.
When product and engineering disagree about what comes first, who makes the call?
Why ask it
Ask for the last time it happened, not the principle. Some companies settle it between two executives, some push it down to the team, and some let it drift until a deadline decides. Whichever it is, you now know where to take a prioritisation problem of your own.
How do you find out when something is going wrong, and how long does that usually take?
Why ask it
Bad news can reach a CTO through a dashboard, a manager's weekly report or an angry customer, and each route has its own delay. If they admit they tend to hear late, you have learned something about the reporting culture, and that they would probably welcome hearing from you directly.
What did we change after the last major outage, and has the change held?
Why ask it
Incident reviews produce action lists, and action lists tend to go quiet. If they can say which items shipped, somebody followed through; if they remember only the night itself, probably nobody did. Either way you learn whether reliability work keeps its time once the pressure is off.
Which numbers do you look at every week, and which one do you trust least?
Why ask it
The weekly numbers are the ones that move decisions, whether that is uptime, delivery, spend, hiring or churn. The distrusted one is worth more to you. A metric the CTO doubts is one your team could fix or replace, and they will notice who does.
What does the executive team argue about most?
Why ask it
Most CTOs will answer in themes, such as pace against reliability or which customers to serve first, and that is all you need. Knowing the live argument tells you which proposals will pass easily and which will stall whatever their merit. Do not push for who said what.
What does the board ask you about engineering, and which question is hardest to answer?
Why ask it
Boards tend to ask about dates, cost and risk, and seldom about code. The question the CTO finds hardest marks where the evidence is thin, and if your team holds that evidence, a clear write-up would be welcome. At a company with no board, ask about the chief executive or the owners instead.
Which part of the business do you wish you understood better?
Why ask it
Support, finance and one particular market are common answers, and the admission costs them little. If you know that part from the inside, perhaps because you sit near support or came from the industry you sell to, offer twenty minutes on it. That is a better reason for a second meeting than anything about your own career.
Their career
What route brought you to the CTO job, and which step taught you the most?
Why ask it
Some CTOs were the first engineer, some came up through management, and some arrived from product or consulting. The route explains their instincts, since people tend to trust whatever worked for them on the way up. It is also easy to answer, which makes it useful when the conversation needs warming up.
What did you have to stop doing when you moved from engineering into the executive team?
Why ask it
Reviewing code and fixing things themselves at midnight are the usual answers, and many admit they held on longer than they should have. If you are heading towards management yourself, this is a free preview of what the move costs.
What is the hardest part of being a CTO that you did not expect?
Why ask it
People who took the job for the technology often find the hard part lies elsewhere: letting someone go, defending a budget, being the one who says a date will slip. It is a different job at twenty people and at two thousand, so ask how the hard part moved as the company grew.
How do you keep your technical judgement current when you are not building every day?
Why ask it
Reading, side projects, sitting in on design reviews and leaning on a few trusted engineers are the common answers. The last one matters to you directly, because those engineers are how technical opinion reaches the top. "I do not have the time" is an honest reply, and worth remembering when one of their calls seems dated.
Which technical bet of yours went wrong, and how did you find out?
Why ask it
Pay attention to how the news arrived: a metric, an engineer who spoke up, or a customer. Someone who tells this story easily, without blaming whoever built the thing, is someone you can bring bad news to.
Nobody else here has done your job, so who do you learn from?
Why ask it
The top technical job can be a lonely one. Their sources might be a circle of other CTOs, an investor, a former boss or a shelf of books, and when one of them keeps turning up behind later decisions you will know where the idea came from.
What would you tell an engineer who wants to be a CTO one day?
Why ask it
Naming the destination gets a better reply than "any advice for me?". Notice whether they talk about technical depth, about learning the business, or about people, because that is what they believe the job really is. Treat it as one person's route and not a rule.
Which of the jobs you do yourself today should be the first to go to someone else?
Why ask it
A startup CTO is often also the release manager, the support desk for the hard tickets and the person who resets passwords. Whichever they pick shows what they think their own time is for. If they want to keep all of it, ask what gave way the last time two of those jobs collided.
Team
What do you wish engineers brought to you more often, and what less?
Why ask it
The "less" is the polite way to find out whether the thing you were planning to raise is the thing they are tired of hearing. Expect them to separate problems that arrive with a proposal from problems that arrive alone.
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
Formal promotion criteria are written down; the judgement that comes before them is not. Listen for whether the signals are about output, about other people improving around someone, or about how a person handled one bad situation. An example of someone who recently got more scope, and why, is worth asking for.
How do you decide who gets the interesting projects?
Why ask it
Good work gets handed out somehow, and the method is rarely written down. A candid reply may mention who delivered last time or who happened to be in the room, which is uncomfortable and still better to know than to guess at. If you want a particular project, this is the moment to say so.
What do you want to see in an engineer before you hire them?
Why ask it
The description is of the team they are trying to build: specialists or generalists, people who have seen scale or people who learn fast. It is also an indirect account of what they value in the engineers already here. If it sounds nothing like your team, ask what changed.
Which skills should engineers here be building now?
Why ask it
The answer hints at where the company is going before anyone announces it: data work, security, a new platform, people who can talk to customers. It is also the most practical career advice they can give you, because it names what is about to be scarce in this particular building.
Where will the next few hires go, and what would change that plan?
Why ask it
Headcount is about the most honest statement of priorities a company makes. Where the hires go shows which teams are seen as stretched and which are expected to cope. Hiring plans usually carry a condition, such as a funding round or a revenue number, and asking what would change the plan brings it out.
When good engineers leave, what reason do they give, and what do you think the real one is?
Why ask it
Exit interviews collect polite reasons, mostly pay or a new opportunity. A CTO who offers a second, less comfortable explanation has been paying attention, and whatever they name is probably being worked on. Keep it general and do not ask about a named colleague.
How would you describe the engineering culture you want, and where are we furthest from it?
Why ask it
Skip past the adjectives and listen for behaviour: shipping without heroics, reviews that take a day and not a week, people saying so early when a date is at risk. The gap is the practical part, because closing it is the kind of contribution that counts as valuable and not merely visible.
What could I do that would make your job easier?
Why ask it
Save it for the end of the meeting, when it can turn what you have heard into something to do. A specific request in reply is a good sign. A polite deflection may only mean they have not thought much about your role yet, which is worth knowing too.
Hiring a CTO
What did you build yourself in the last year?
Why ask it
At an early-stage company you need to know whether they still write code, review it, or do neither. Any of the three can suit the role, so decide which one you need before the interview and compare. Someone who has managed for years may describe a prototype or a script, and that is a fair answer.
How do you decide what not to build?
Why ask it
Much of a CTO's value lies in what they turn down. Ask for the criteria and for one thing they stopped, including who was unhappy about it. A candidate who talks only about delivery may be one who accepts every request and then misses dates.
How do you handle it when engineering says six weeks and the business needs three?
Why ask it
The useful answers are about reducing scope, shipping something narrower, or being explicit about what is being traded. An answer that amounts to finding a way is how teams end up in permanent overtime.
How do you know whether the team is productive?
Why ask it
Some candidates reach for individual counts such as tickets closed or lines written; others look at how often the team ships and how often a release has to be pulled back. Ask what they did the last time the numbers looked fine and the team was plainly struggling. "I talk to people" is honest, and the fair follow-up is how that works with forty engineers instead of eight.
How would the engineers who last worked for you describe you as a boss?
Why ask it
Asking for the team's view makes a rehearsed answer about leadership style harder to give. Listen for something a little unflattering, such as impatient in reviews or slow to delegate, since no team describes its boss in pure praise. Then ask whether you could speak to one of those engineers as a reference.
How do you recruit engineers when the company is not well known?
Why ask it
A candidate from a large firm may never have had to sell a job, because the name did it for them. Ask who their first three hires here would be and whether those people would follow them. Named people, or a clear plan for finding strangers, count for more than confidence.
What have you done about security in a company at our stage?
Why ask it
You are testing a sense of proportion. A small company usually needs the basics done well, such as who has access to what, where secrets are kept and whether backups restore, long before it needs a full enterprise programme. If you sell to regulated customers the bar is different, so say so and see how the answer changes.
What does your engineering budget usually go to, and what did you cut last time money got tight?
Why ask it
People, hosting, tooling and contractors are the usual lines, and a candidate who has owned a budget will give rough proportions without looking anything up. What they protected in the last squeeze shows their priorities more plainly than anything they say about vision. If they have never held the budget, it is better to learn that now.
What would you want to learn in your first month here before changing anything?
Why ask it
The question hands them permission to go slowly, and you are watching whether they take it. Listen for who they would talk to outside engineering: support, sales, your largest customers. A candidate with a rewrite in mind by the second week had decided before looking.
Explain a technical trade-off you made recently as you would to a board with no engineers on it.
Why ask it
Half the job is translation, and this lets you watch it happen instead of asking whether they are good at it. A strong answer says what was given up, what it cost in money or time, and when the decision would be looked at again. If you are not technical and cannot follow it, your investors and customers will not follow it either.
Where do you think a CTO's job ends and a VP of engineering's begins?
Why ask it
Titles mean different things from one company to the next, so you are checking their picture of the role against the job you actually have. Some CTOs want to run delivery and people; others want architecture and the outward-facing work, and expect someone else to manage. Both are legitimate, and you should know which one you are hiring before the offer goes out.
What would you need from me to do this job well?
Why ask it
Good candidates have conditions: a say in the roadmap, a hiring budget, a seat in customer conversations, a limit on what sales can promise. Hearing them before the offer is far easier than discovering them in the third month. Be wary of "nothing, I will make it work", because few people take a job like this with no conditions at all.
How to use these questions
Practical guidance for the conversation itself
Getting something out of the conversation
Match the group to the meeting
A skip-level suits the Priorities and Team questions. An open Q&A in front of the whole company has room for one question, so take it from Priorities or Technology and keep it short. The career questions belong in a coffee or an intro chat with no agenda. A chief executive checking on their own CTO can start with Technology: the breach, backup and one-person questions need no engineering background to ask or to judge. At a startup, where the meeting may be two founders at one desk, go to the questions that close Priorities and Technology: runway, shortcuts and account access matter more there than a three-year plan. The final group is for the other side of the table, founders and boards interviewing a candidate, and there every answer should arrive with an example.
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.
- How specific the answers are. A named system, a date or an owner means the subject is being managed; "we are looking at it" usually means it is not yet.
- 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.
- With a candidate, whether the examples come from a company near your size. Habits that suit several hundred engineers rarely fit a team of twelve, and the reverse is just as true.
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.