Skip to content
Question Vault?
Free to readNo accountNo email wallNo invented statisticsNo ads on medical, legal or end-of-life pagesCopy or print any set and take it with you
03 · Professional & Academic

Questions to Ask a CIO

For a candidate, a business partner, or a vendor with time in front of a chief information officer. Twenty questions on where the IT budget goes, how work gets prioritized, outages and recovery, technical debt, vendor lock-in, and how the team is staffed.

20 questions · each with a note on why · conversation guide

The questions

Open any question for the note

  1. How does your budget split between keeping things running and building something new?

    Why ask it

    Most IT budgets are dominated by run costs, and the ratio is the single most compressive fact about the job. A CIO who quotes it without hesitating manages by it. One who cannot separate the two is unlikely to be able to fund anything new without a fight.

  2. How does a business team get work onto your list? Is there a queue, a committee, or a chargeback model?

    Why ask it

    This tells you whether requests are governed or whether the loudest executive wins. Watch for whether there is a published intake path, because in its absence the real path is personal relationships and you should know whose.

  3. Once something is approved, how long until it's actually in production?

    Why ask it

    Lead time is the number business partners care about and IT rarely volunteers. If the reply is that it depends on the project, ask for the last three things shipped and how long each took from decision to live.

  4. Which system would hurt the most if it went down for a day, and how long would recovery really take?

    Why ask it

    The gap between the documented recovery objective and the honest estimate is where the risk lives. A CIO who names a specific system and a specific worry has thought about it. A blanket claim that everything is redundant is a paper answer.

  5. When was your last unplanned outage, and what caused it?

    Why ask it

    Recent incident detail shows whether there is a real post-incident habit. Listen for a root cause in terms of process and dependencies rather than a person, and for what changed afterwards.

  6. How do you decide whether to build something or buy it?

    Why ask it

    Look for a stated boundary, usually that anything close to how the company makes money gets built and the rest is bought. Without such a line, the decision drifts to whoever pitched most recently.

  7. Who can buy a new SaaS tool without talking to you, and how much of that do you think is happening?

    Why ask it

    Every organization has software bought on a department card. A CIO who estimates the scale and describes how they find it is dealing with reality. One who says it does not happen here has simply not looked at the expense reports.

  8. What's on your list to switch off, and what's stopping you?

    Why ask it

    Decommissioning is unglamorous and rarely funded, so the blockers are revealing: one team still depends on it, the data cannot be migrated, nobody knows what calls the API. This answer maps the awkward corners of the estate.

  9. Where's the worst of the technical debt, and what would it cost to deal with?

    Why ask it

    A CIO who can put a rough number and a rough date on the debt has made the case to finance before. Vague acknowledgement without a figure usually means the problem is being carried rather than managed.

  10. When two reports disagree on the same number, who decides which is right?

    Why ask it

    This is a governance question disguised as a data question. The answer names an owner or it does not, and where there is no owner, teams quietly maintain their own version of every metric.

  11. How is responsibility split between you and the security team?

    Why ask it

    Where the CISO reports to the CIO, security spending competes with delivery for the same budget. Where it reports elsewhere, the friction shows up as delayed approvals. Either arrangement works, but the failure modes are different and worth hearing described.

  12. What do you do when a vendor's roadmap stops matching what you need?

    Why ask it

    Look for a concrete example rather than a principle. The interesting part is what leverage they actually had: contract terms, a migration threat, a user group, or nothing at all.

  13. Which contracts are you locked into, and when do the big ones come up for renewal?

    Why ask it

    Renewal dates are where a CIO regains or loses freedom for years at a time. Someone who knows the dates by heart is planning around them. If you are selling, this is also the only calendar that matters.

  14. What have you tried with AI tooling, and what did you stop doing?

    Why ask it

    The stopped experiments are more informative than the live ones, because they show what was measured. Answers that are entirely pilots and enthusiasm with nothing retired suggest nothing has been evaluated yet.

  15. How much of the team is contractors or outsourced, and is that mix changing?

    Why ask it

    The ratio determines how much institutional knowledge walks out at the end of a statement of work. A rising contractor share alongside flat headcount usually means a hiring freeze that nobody has announced.

  16. What's the hardest role on your team to fill, and why?

    Why ask it

    The gap names the constraint on everything else they described. Pay, location policy, and legacy technology all show up here, and the reason given tells you which one they can actually influence.

  17. What does the rest of the executive team bring you that isn't really your job?

    Why ask it

    Every CIO absorbs work that landed nearby: facilities, procurement, data privacy, anything with a cable in it. The answer maps how the company sees the function, and how much of the week goes to things nobody planned for.

  18. What project have you killed, and how did you know it was time?

    Why ask it

    Stopping work is harder than starting it and more diagnostic. Listen for the signal they acted on and how long they waited, because that gap is roughly how long any troubled project here runs before someone intervenes.

  19. If the CFO cut your budget by ten percent tomorrow, what would go?

    Why ask it

    This forces a ranking that the strategy slides avoid. The order reveals genuine priorities, and if the answer is that nothing could go, the budget has no slack and neither will any commitment they make to you.

  20. What do you wish the rest of the business understood about how long this work takes?

    Why ask it

    A closing question that usually produces the most candid answer of the meeting: integration work, testing, data migration, the compliance step nobody sees. If you work with this person, it is also the expectation gap you can help close.

Talking to a CIO

Practical guidance for the conversation itself

Ask in the units they manage in

Ratios and dates, not adjectives

Run versus change budget, lead time from decision to production, incident count and severity, contract renewal dates. Questions framed this way get answered from memory. Questions framed around innovation get answered from the deck.

Anchor to a recent event

The last outage, the last renewal, the last project stopped. Specific recent events pull the conversation out of strategy language, and a leader who cannot recall any of them is describing someone else's estate.

Ask what they cannot control

Regulatory deadlines, a parent company's platform choice, a system inherited through acquisition. Naming these constraints early stops you spending the meeting on options that were never open.

If you're selling to them

  • Find out who signs and at what value the approval moves up to the CFO or the board.
  • Ask what the security review involves and how long it took the last comparable vendor.
  • Ask which of your competitors is already inside, and in which department. Displacement and expansion are different sales.
  • Ask when the incumbent contract renews. That date, not your quarter, sets the realistic timeline.
  • Ask what would have to be switched off for you to be switched on, and who owns that system.

If you're interviewing for the team

  • Ask what the on-call rotation looks like in practice, including how many pages a typical week brings.
  • Ask what share of the roadmap for this year is already committed to other departments.
  • Ask how the last two people in this role left, and where they went.
  • Ask who you need to convince to get a technical decision made, and how long that usually takes.
  • Ask which system you would inherit that nobody else wants to touch.

What tends to go wrong

  • Asking whether technology is aligned with the business. No CIO will say no, and the answer carries no information.
  • Leading with trend words. A question about a named technology gets a positioning answer; a question about what was retired gets a real one.
  • Confusing the CIO with the CTO. In many companies one runs internal systems and the other builds the product, and the wrong questions signal you did not check.
  • Spending the whole meeting on your own request. Ask about the queue first, then place your request inside it.
  • Taking a roadmap slide as a commitment. Ask what is funded and staffed, which is usually a shorter list.