Questions to Ask Technology Leaders
Questions for a conversation with a CTO, VP of engineering, or other technology leader, covering how they spend their time, how they make build or buy calls, how they judge productivity, and how they handle incidents.
The questions
Open any question for the note
What does your week look like now compared to when you were writing code?
Why ask it
Concrete and hard to answer with slogans. The split between meetings, hiring, and writing documents is the clearest picture of what the job actually becomes.
What's the last technical decision you made yourself?
Why ask it
Separates leaders still close to the work from ones who only approve. A leader who cannot recall one has moved fully into management, which is worth knowing either way.
How do you decide whether to build something or buy it?
Why ask it
Most leaders have a rule of thumb, usually about whether the thing is core to the product. Listen for whether cost, staffing, or control is doing the real work in the decision.
How do you tell a genuine technical risk from a preference argument?
Why ask it
Engineering disagreements are routinely dressed up as risk. Leaders who can separate the two tend to run calmer teams and fewer rewrites.
How do you handle work that the business will never fund directly?
Why ask it
Honest answers involve folding it into feature work or holding a fixed share of capacity. A general answer about prioritization usually means it does not happen.
How do you know whether your team is productive?
Why ask it
Watch whether they cite shipped outcomes, cycle time, or something softer like team confidence. A leader who reaches for ticket counts is telling you a great deal.
What kind of engineer does well on your team, and what kind struggles?
Why ask it
The second half is the useful half. A leader who cannot describe who struggles has probably not looked closely at why people leave.
How do you keep enough technical depth to ask good questions?
Why ask it
Answers are usually specific practices: reading design documents, sitting in on incident reviews, keeping a small project. No practice at all means they are drifting from the work.
What's your approach when you can tell a project will miss its date?
Why ask it
The real question is when they tell people, not whether. Leaders who escalate early tend to be trusted by peers outside engineering, which is most of the job.
How does hiring work at senior levels here?
Why ask it
Shows whether they interview personally, what they screen for, and how much weight goes on past company names versus demonstrated work.
How do you protect focus time for engineers?
Why ask it
Concrete answers include meeting free days, a rotating interrupt owner, or a hard cap on planning ceremonies. No mechanism usually means it has not been tried.
Where does your team disagree with the rest of the company most often?
Why ask it
Names a real tension: deadlines, quality, security review, headcount. It also shows how they represent engineering upward when the room is not friendly.
What's a technology you decided not to adopt, and why?
Why ask it
Restraint is harder to talk about than adoption, and the reasoning shows how they weigh novelty against years of maintenance.
What are you doing with AI tooling, and what hasn't worked?
Why ask it
The failures are the informative part. A leader who describes only pilots and enthusiasm has not measured anything yet.
What happens after a serious incident?
Why ask it
Look for whether the follow up is structural or a promise to be more careful. Blameless review is easy to claim and much harder to actually run.
What do you look for before promoting someone into leading others?
Why ask it
Describes the ladder in practice rather than on paper, and it reveals what the company quietly rewards.
What did you get wrong about leading engineers early on?
Why ask it
Invites a specific admission. Common ones involve promoting the strongest coder or trying to remain the best engineer in the room.
What's the hardest conversation this job asks you to have?
Why ask it
Usually performance or redundancies. How they describe it shows whether they think in terms of headcount or of colleagues.
How did you decide to move into leadership, and would you go back?
Why ask it
Some miss the work and will say so plainly. A candid answer here is more useful to anyone weighing the same move than any amount of general career advice.
What advice would you give someone one step below you who wants your job?
Why ask it
Ask this last. By then they know enough about you to say something specific rather than offering encouragement.
Getting a Real Answer from a Senior Leader
Practical guidance for the conversation itself
Match the Question to the Setting
A conference hallway or a panel
You have two or three minutes. Ask one question about a decision they made rather than a trend they observe, and skip anything that needs internal detail they cannot share publicly.
An interview loop
Questions about incidents, focus time, and who struggles on the team give you the most signal about daily life. Keep the career advice questions for later; they use time you need for assessment.
A mentoring or skip level conversation
This is where the reflective questions belong. Send one in advance if you want a considered answer rather than an improvised one.
How to Read the Answers
- Specific beats fluent. A leader who names one project, one date, and one person is describing something that happened.
- Ask for the counterexample. If they describe a process that works, ask when it last failed.
- Listen for who gets credit and who gets blamed across several answers. The pattern is more reliable than any single story.
- Note the questions they redirect. Compensation, attrition, and layoffs are often deflected for real reasons, but repeated deflection on engineering practice is different.
What Wastes the Conversation
Asking about industry trends in general
Senior leaders answer these on autopilot and you learn nothing you could not read. Ask what they decided differently as a result of a trend instead.
Framing a question as a test
Asking a leader to justify a public technical choice tends to produce a defense rather than an explanation. Ask what the alternatives were and what the tradeoff cost.
Asking six questions at once
Long compound questions get answered in the easiest part. One clause, then silence, gets more.