How to Say I Do Not Know as a Leader

A few years ago I sat in a board meeting where a director asked me whether our new payment routing engine could handle a specific failover scenario across two regions. I did not know. I had a strong hunch, but a hunch dressed up as a fact is exactly the kind of thing that costs you a licence or a customer. So I said, "I don't know, but I'll have a precise answer by Thursday." The room went quiet for a second, and then we moved on. Nobody thought less of me. I checked afterward.

The instinct to bluff is strong, especially when you are the person everyone assumes has the answers. I have watched capable engineers and executives torch their credibility not by being wrong but by pretending to be certain. Saying "I don't know" well is a skill, not a confession. Here is how I've learned to do it.

The cost of the confident guess

Early in my career I worked under a VP of Engineering who never admitted uncertainty. Ask him anything and you'd get a crisp, decisive answer delivered with total conviction. It took me about six months to realise that roughly a third of those answers were wrong. The problem wasn't that he was stupid. He was very smart. The problem was that his confidence was completely uncorrelated with his accuracy, and once you notice that about someone, you stop trusting any of it.

In fintech the confident guess has a specific price. We once shipped a change to a settlement batch job because a senior person "was pretty sure" the cut-off time was 23:00 UTC. It was 22:00. That one-hour error meant a day's worth of merchant payouts landed a business day late, which triggered support tickets, a frantic reconciliation, and an awkward call with a client who ran payroll off those funds. The fix took an afternoon. The trust took a quarter to rebuild. All of it avoidable if someone had said "I'm not certain, let me check the runbook."

Knowing when you actually don't know

The hard part isn't the humility. It's the self-awareness. Most bad guesses come from people who genuinely believe they know. You have to develop a reliable internal signal for the difference between "I remember this" and "I am reconstructing something plausible." Those two feel identical from the inside, and that is the trap.

The test I use is simple: could I defend this to a regulator with a source? If the answer lives in a document, a config file, or a dashboard I can point to, then I know it. If the answer lives only in my memory of a conversation from eight months ago, I treat it as a hypothesis. Memory is a lossy compression algorithm, and mine has shipped bugs to production more than once.

The most dangerous phrase in engineering isn't "I don't know." It's "I'm pretty sure," said fast, with a shrug, by someone senior enough that nobody checks.

Say what you do know, then draw the line

"I don't know" on its own can read as unhelpful, or worse, as evasion. The version that builds trust is bounded. You show the edge of your knowledge precisely, which is itself a demonstration of competence. Someone who can tell you exactly where their certainty ends usually knows a great deal.

So when that director asked about cross-region failover, the useful answer wasn't just "I don't know." It was: "I know we replicate the transaction ledger synchronously within a region and asynchronously across regions, so I know we can lose a data centre. What I don't know is our exact recovery time if we lose an entire region during a settlement window, because we've never run that specific game day. I'll get you the measured number." That answer contains three things I'm sure of and one honest gap. It sounds like a person who has done the work.

The commitment that makes it credible

An admission of ignorance without a follow-up is just a shrug. What converts it into leadership is the commitment attached to it. Every "I don't know" from me comes with a who and a when. Not "I'll look into it" — that is where answers go to die — but "I'll have the failover number from the SRE team by end of day Thursday."

And then you have to actually deliver it, unprompted. The whole thing collapses if people learn that your "I'll get back to you" is a polite way of ending the conversation. I keep a running list of these promises, and closing them is non-negotiable. The payoff is enormous: when you reliably return with answers, people stop needing you to have them on the spot. They trust the process instead of demanding false certainty in the moment.

The permission structure you set for everyone else

Here is the part that took me longest to understand. When the most senior person in the room admits they don't know something, they hand everyone else permission to do the same. The reverse is also true, and it's poisonous. If you bluff, your team learns that bluffing is what success looks like here, and they start doing it too. Now you have a culture where nobody says "I'm not sure" during a design review, and that is how a fintech ends up with a data model that quietly assumes every account has exactly one currency.

I make a point of saying "I don't know" in public, in front of juniors, on purpose. In incident reviews especially. The behaviours I most want to encourage on a team look something like this:

• Stating a confidence level, not just a conclusion — "I'm 90% sure" is more useful than a flat assertion.
• Asking "how do we actually know that?" without it being treated as an attack.
• Distinguishing between what the logs say and what someone assumes happened.
• Being willing to say "my earlier answer was wrong" the moment new evidence shows up.

None of that survives in a room where the boss pretends to be omniscient. You get the epistemic hygiene you model.

Match your candour to the blast radius

Not every uncertainty deserves the same treatment, and pretending otherwise turns you into someone who can't make a decision. The calibration I use is blast radius. If someone asks which shade of blue to use on a button and I'm unsure, I'll just pick one — the cost of being wrong is a two-minute revert. I don't need to run a study.

But if the question touches money movement, customer funds, regulatory reporting, or data we can't un-leak, my tolerance for guessing drops to roughly zero. Those are the domains where "I'm pretty sure" is not an acceptable input to a decision. I once killed a Friday-afternoon deploy because the engineer couldn't tell me with certainty whether a migration was reversible. He was annoyed. On Monday we found the migration would have locked a table holding live balances for several minutes during peak hours. The annoyance was worth it. The rule is: the more irreversible and expensive the mistake, the more you earn the right to slow down and say "I need to be sure first."

Humble is not the same as hopeless

There's a failure mode on the other side, and I've fallen into it. You can say "I don't know" so often, or so limply, that you start to look like you don't know anything at all. Uncertainty theatre is its own credibility drain. If every answer is hedged into oblivion, people stop coming to you for decisions, and a CTO who can't decide is not doing the job.

The resolution is that "I don't know the fact" and "I can't make the call" are completely different statements. You very often have to decide without complete information — that is most of the job, actually. The honest version sounds like: "I don't have data on how this scales past ten thousand transactions per second, and we won't have it before we need to ship. Given that, my judgment is we go with the queue-based design because it fails more gracefully, and I'll own that call." That's not certainty. It's a decision made in the open, with the gaps named. People respect that far more than false precision.

What the habit does to your own thinking

The external benefits are real, but the quieter payoff is what admitting ignorance does to you internally. Every time I say "I don't know," it opens a small task: go find out. Over a couple of decades that habit has closed thousands of gaps in my understanding that I'd otherwise have papered over with a confident guess and never revisited.

The people who stop learning, in my experience, are almost always the ones who got good at sounding like they already knew. They removed the very signal that tells you where the work is. A gap you refuse to name is a gap you'll never fill. I'd rather feel the small sting of not knowing something and use it as a to-do item than protect my ego and stay ignorant. The engineers I've admired most are the ones who, thirty years in, still say "huh, I've never actually understood why that works — let me dig into it."

Conclusion

The strange payoff of admitting ignorance is what it does to the opposite claim. Every leader issues a private currency of certainty, and most of them are quietly inflating it — one confident guess at a time — until the word "sure" from them buys nothing. Spend "I don't know" freely and honestly, and you're doing the reverse: backing the currency. So when you finally do say "I'm certain," the room believes you, because they've watched you refuse to spend that word to fill an awkward silence. The bounded version — "I don't know X, but I know A, B and C, and I'll have X by Thursday" — is how you keep the account solvent. The answer you fake today is a withdrawal from the one balance you can't overdraw twice.