TechnicalTrust.org

July 10th

The Confidence Bluff:
The three most trust-building words in tech–and why almost nobody says them.

↓

Welcome to the first regular edition of Technical Trust. The format from here: one named pattern or practical move per issue, short enough to read between meetings, useful the same day. Today's pattern is the most common trust failure in our industry — and the one with the simplest fix.

THE CONFIDENCE BLUFF: guessing under pressure instead of saying "I don't know."

You've watched it happen. Someone technical gets asked a question they can't answer — in a demo, an architecture review, a sales call, an interview — and instead of admitting it, they improvise. The answer comes out fluent, plausible, and maybe 70% right. The room moves on. No one seems to notice.

Here's why it's so tempting: in the moment, the bluff appears to work. The questioner nods. The meeting continues. The expert's authority survives. Every incentive in the room rewards the guess.

And here's why it's a trap: technical claims are checkable. Not always immediately — but eventually, someone reads the docs, runs the test, asks your colleague, or simply remembers what you said when reality arrives. And when a bluff is discovered, it doesn't cost you one answer. It costs you every answer. Your counterpart now has to re-audit everything you've ever told them, because they've learned something more damaging than "he was wrong once." They've learned: this person will guess rather than admit uncertainty — and won't tell me which answers were guesses.

That's the asymmetry that makes the bluff so expensive. Confidence is cheap to perform and catastrophic to be caught performing.

Now the fix, which costs three seconds of discomfort:

"I don't know — let me find out and get back to you by Thursday."

Notice the anatomy. "I don't know" is the candor. "Let me find out" is the ownership. "By Thursday" is the part almost everyone forgets — the specific commitment that converts an admission of ignorance into a demonstration of reliability. And then, of course, you actually deliver on Thursday, which is where the real trust gets minted. (An "I'll find out" that never returns is just a slower bluff.)

Something counterintuitive happens when you do this consistently: your other answers get UPGRADED. The person across the table learns that when you do answer immediately, it's because you actually know — you've proven you're willing to say when you don't. One honest "I don't know" buys credibility for a hundred confident answers. I've watched people worry it makes them look junior. In my experience it does the opposite: juniors bluff because they think they can't afford the gap. The most senior person in the room is almost always the one most comfortable saying "I'm not sure — let's check."

Where to use this in the next seven days:

• ANSWERING: next time you feel the guess forming, catch it. Say the sentence, with a deadline. Watch what it does to the room.
• EVALUATING: when a vendor or candidate answers everything instantly, get suspicious, not impressed. Ask something obscure on purpose. You're not testing their knowledge — you're testing what they do at the edge of it.
• LEADING: if people on your team bluff, ask why. Usually it's because somewhere along the line, "I don't know" got punished. That's fixable, and fixing it is cheaper than the outages.

The pattern to remember: trust isn't built by having every answer. It's built by being reliable about which answers you have.

More patterns soon. If you've watched a Confidence Bluff go wrong — or found your own way to say "I don't know" without flinching — hit reply. The best stories end up shaping future issues (anonymized, always).