Most board members know they should be asking about technology. Few know what questions actually matter. After conducting 50+ technical assessments, here's what we've learned about the questions that surface real insight.
Every board meeting includes some version of the technology update. Engineering is on track. We're making progress on the platform. Security is under control. The CTO presents, the board nods, and everyone moves on to the next agenda item.
The problem isn't that boards don't care about technology. It's that they don't know what questions to ask. And the questions they do ask tend to generate reassurance rather than insight.
The questions that don't work
Here are the questions boards typically ask:
- "How's the technology?" (Too vague. Invites reassurance.)
- "Are we secure?" (Binary framing. The answer is always "yes, but...")
- "Is the team performing?" (Subjective. Depends who you ask.)
- "Are we on track with the roadmap?" (Compares plan to plan, not plan to reality.)
These questions have something in common: they can all be answered with opinions rather than evidence. And when questions can be answered with opinions, you get the opinions that are easiest to give.
The five questions that work
Here are the questions that actually surface useful information:
- What would it cost us to rebuild the core platform from scratch? Not because you're going to rebuild it. But because the gap between "cost to rebuild" and "current investment" tells you how much technical debt you've accumulated. If the answer is "we could rebuild it in 6 months with the current team," your architecture is probably clean. If the answer is "it would take 3 years and twice the team," you have a problem worth understanding.
- If our top 3 engineers left tomorrow, what would break? Every organization has heroes, the people who built the critical systems and carry the institutional knowledge. The question isn't whether you have heroes. It's whether you know who they are and what happens if they leave. If the CTO can't answer this question in specific terms, that's a finding.
- What percentage of engineering time goes to new features vs. maintenance? Most boards assume engineering is building the future. Most engineering teams are actually maintaining the past. The ratio tells you whether you're investing or just treading water. Below 50% on new features is a warning sign. Below 30% is a crisis.
- When was the last time we had an outage, and what caused it? Not "have we had any outages?" but "tell me about the last one." The specificity matters. A healthy engineering organization can tell you exactly what happened, why, and what they did to prevent it from happening again. Vague answers suggest either poor incident response or incidents that aren't being tracked.
- What's the oldest code in production, and who understands it? Every codebase has archaeology. The question is whether anyone still knows where the bodies are buried. Code that's old, undocumented, and understood by no one is a liability. Code that's old, stable, and well-understood is an asset. The difference matters.
The common thread
Notice what these questions have in common: they ask for specifics. Numbers. Names. Dates. They can't be answered with "we're doing great" or "we're on track."
They also ask about risk, not progress. Boards spend too much time asking "are we building what we said we'd build?" and not enough time asking "what could go wrong?"
How to ask these questions
The way you ask matters as much as what you ask. A few principles:
Ask for evidence, not opinions
When someone says "our security is solid," the follow-up is "show me." When someone says "we're making good progress," the follow-up is "what shipped last quarter?" Opinions are easy. Evidence requires homework.
Ask the same questions over time
One data point is an anecdote. A trend is a story. If you ask "what percentage of time goes to maintenance?" every quarter, you'll see whether things are getting better or worse. One-off questions generate one-off answers.
Ask different people
The CTO sees one version of reality. The senior engineers see another. The people who joined six months ago see a third. Triangulation reveals truth.
"The questions you ask determine the reality you see. Ask better questions, see clearer reality."
What to do with the answers
Asking good questions is only half the work. The other half is knowing what to do with answers that concern you.
If you learn that 3 engineers hold all the critical knowledge, the response isn't to fire them or demand immediate documentation. It's to understand the risk and make informed decisions about mitigation.
If you learn that 70% of engineering time goes to maintenance, the response isn't to demand more features. It's to understand why, and whether investing in reducing that burden would accelerate future work.
The goal isn't to catch people doing something wrong. It's to see reality clearly enough to make good decisions.
When you need more than questions
Sometimes questions aren't enough. When you're preparing for a board presentation, planning a major initiative, evaluating an acquisition, or navigating a leadership transition, you need more than answers to questions. You need an independent view of reality.
That's what we do. We go into the codebase, the commit history, the architecture, and we surface the five stories that matter: the exposure, the heroes, the liability, the fragility, and the alignment between what was promised and what was built.
But even without that level of depth, better questions lead to better understanding. Start with these five.