Questions to Ask CTO in Town Hall
Questions for a company town hall or all-hands where the CTO is taking questions in front of everyone. The constraint is that they have to be answerable in public, useful to more people than just you, and phrased so they get a real answer rather than a deflection.
The questions
Open any question for the note
Of this year's technology priorities, which is most likely to slip, and what would we do if it did?
Why ask it
Asking which one will slip is harder to deflect than asking whether everything is on track, and it gives the CTO a legitimate way to talk about risk in public. If the answer is that none of them will, the room will remember that in six months.
We have heard what we are building this year. What did we decide not to build, and why?
Why ask it
Roadmap presentations rarely mention what was cut, and knowing the discards tells teams which requests are dead rather than pending. It also tends to produce the most concrete reasoning in the whole session.
What are we asking teams to stop doing to make room for the new priorities?
Why ask it
This is the question everyone in the room is privately worried about, which is exactly why it works well in a town hall. A CTO who names something specific is being straight; one who says we will find efficiencies has just told the team to absorb the work quietly.
How much engineering time is currently going into keeping existing systems running, and where would you like that number to be?
Why ask it
Framing it as a current number and a target invites an honest answer rather than a defence. It is also the most useful single figure for anyone trying to understand why feature delivery feels slow.
What is the plan for the systems engineers spend the most time working around?
Why ask it
Everyone knows which service or tool costs the team hours each week, and asking in public makes it harder to keep deferring. Watch whether the answer includes a person or a quarter, because without one of those it is not a plan.
How would the engineering hiring plan change if revenue came in below plan?
Why ask it
This is a fair question and the honest answer is usually cautious, which is still informative. Compare the response to what the finance leader says at the same meeting, since inconsistency between them is the real signal.
How do you decide which teams get new headcount?
Why ask it
Allocation is the decision that most affects daily life and is least often explained. An answer that describes a process, even an imperfect one, is more reassuring than an answer about investing where the opportunity is greatest.
In practical terms, how do you expect AI tooling to change what is asked of engineers here?
Why ask it
Asking for practical terms steers away from a speech about the future and towards specifics: expected output, review standards, or what is now considered acceptable to generate. Whatever the answer, the whole room wants it on the record.
What is our position on sending customer data to external services, and who decides that?
Why ask it
Naming the decision maker is the part that matters, because most teams are unsure whether this sits with security, legal or the individual engineer. A clear answer prevents a genuinely serious mistake later.
What does the security work for the coming year look like, at whatever level you can share publicly?
Why ask it
The caveat is deliberate: it makes the question askable in a large meeting and gives the CTO room to answer without disclosing specifics. If there is no answer at all, that itself tells the room where security currently sits.
After the last significant incident, which of the follow-up actions are still open?
Why ask it
Post-incident actions are widely written and less widely finished, so asking about completion rather than intention is the useful version. A CTO who knows the status without checking is close to the work.
Which metric do you personally watch to judge whether engineering is healthy?
Why ask it
Because they can only name one or two, you learn what actually governs decisions rather than what appears on a dashboard. Delivery-based answers and reliability-based answers imply very different priorities for the year.
What is the biggest technical risk you would want every engineer here to understand?
Why ask it
This invites something genuinely educational rather than reassuring, and it is one of the few town hall questions that makes the whole room better informed. Vagueness in reply usually means the risk is commercial or organisational and cannot be said aloud.
How are decisions about tools and platforms made, and how does someone propose a change?
Why ask it
Half the audience has a suggestion and no idea where to send it. The answer should end with a name, a channel or a document, and if it does not, the process does not really exist.
How should a team handle a customer request that conflicts with the roadmap?
Why ask it
This is the daily conflict in most companies, and a public answer becomes something teams can point to afterwards. Listen for whether the escalation path is a person or a committee, because the second one usually means the request dies quietly.
How would you like someone to raise a concern that their own manager does not share?
Why ask it
Asked in public, this gets a considered answer and tells everyone what the accepted route is. It also gently tests whether the stated openness has a mechanism behind it, such as a named skip-level or an anonymous channel.
What are the levels above senior engineer, and how many people moved into them last year?
Why ask it
The first half is a documentation question and the second half is the real one, because a ladder with no recent movement is decoration. The number is checkable, so a vague answer stands out.
What is the honest state of our documentation, and does anyone own it?
Why ask it
Almost every organisation is bad at this and admitting it in public is a small act of credibility. If the answer assigns ownership to everyone, expect nothing to change, and that is worth knowing before you volunteer.
What has changed in your thinking over the past six months?
Why ask it
This is a generous question that still produces substance, since leaders rarely get asked what they revised. An answer naming a specific reversal shows the strategy is being tested rather than defended.
What is one thing you would like the engineering team to hold you accountable for this year?
Why ask it
It offers the CTO a good moment rather than putting them on the spot, which is why it works as a closing question in a public setting. A specific commitment gives everyone something to refer back to; a general one about being available does not.
How to use these questions
Practical guidance for the conversation itself
Asking well in a public meeting
One sentence, no preamble
In a large meeting, a question with a two-minute setup loses the room and invites a vague reply. State the question and stop; the context can go in the follow-up if it is needed.
Ask what many people want answered
The test for a town hall question is whether at least twenty other people would like to hear the answer. Anything narrower belongs in a team meeting or an email, where it will get a better answer anyway.
Use the submission tool if there is one
Many all-hands run on a system where questions are submitted and upvoted in advance. Posting early, in plain language, is the single most effective way to get a question asked, and upvotes give the CTO cover to answer something uncomfortable.
Ask for a number or a name
Questions that request a figure, a date or an owner are much harder to answer with a general statement. Compare "are we investing in reliability" with "how much of engineering time went to reliability last quarter".
Reading the answer you get
- Whether the answer contains anything checkable. A response with no number, name or date is a position, not information.
- Whether they say what will be given up. Any plan that adds priorities without removing any is being funded by unpaid overtime.
- Whether their answer matches the finance or product leader's on the same subject. Inconsistency across a single town hall is the most useful thing you will learn all quarter.
- How they handle a question they cannot fully answer. Naming the constraint is a good sign; pretending there is no constraint is not.
- Whether follow-up actually happens. A promise to come back on something is easy to make and easy to track.
Common pitfalls
Do not escalate a personal grievance in public
A town hall cannot resolve a problem with your manager, your level or your project, and raising it there tends to harden positions. Use the meeting for questions about how things work, and take individual issues to a one-to-one or to a formal channel.
Do not name colleagues or teams critically
A question that identifies a team as the problem will be remembered by the people in it long after the answer is forgotten. Ask about the system or the process instead, which is usually where the real cause sits.
Do not expect a straight answer on finance or headcount
Anything touching funding, layoffs or acquisitions is often legally constrained, and the vagueness may not be evasion. Ask anyway if it matters to you, but read a careful answer as a limit rather than as bad faith.
Do not ask something already covered in the update
It costs the room time and signals you were not listening. Reference what was presented and ask about the part that was left out.
After the meeting
- If you got a partial answer, send one short written follow-up the same day, quoting what was said and asking the narrower version.
- If you were promised a number, ask for it once more in two weeks. Doing this politely and consistently is how a town hall becomes useful rather than performative.
- If your question was not reached, post it in the submission tool for next time rather than raising it privately, so it stays a shared question.
- Keep a short note of commitments made in front of the whole company. They are the easiest things to follow up on and the most often forgotten.