Understand before you speak
There is a kind of professional who, in any technical discussion, can tell you precisely which parts of what they just said are solid and which are provisional. They don't do it as a disclaimer. They do it because they actually know where their understanding ends, and they have organized what they know around that boundary. I have spent a long time trying to understand how people get that way, because it is rarer than it should be and more valuable than almost anything else I look for in an engineer or a leader.
My best guess is that it comes from having been, at some point, in a situation where nothing external could rescue you. I had one of those early in my career, and I still think about it.
The room
I was sent abroad, alone, to a two-day technical workshop run by a counterparty we needed to integrate with. The brief was simple: go, understand their new interface, come back and tell the team what we had to build. I had no laptop — the company didn't hand them out then. There was no phone with email, no chat with colleagues, no shared repository to consult between sessions. I had an address written on a piece of paper, a notebook, and the expectation that whatever I came back with would be acted upon.
I remember the feeling of the first ambiguity. Someone in the room said something about message sequencing that could have meant two different things, and both interpretations had consequences for us. The normal reflex — "I'll check and get back to you" — was simply not available. I could ask the question now, in front of everyone, or I could not know. So I asked. It was a slightly embarrassing question, the kind you'd rather have answered in private, and the answer changed what we were going to build.
That pattern repeated for two days. Every unclear point had to be resolved in the room, because there was no later. In the evenings I reorganized my handwritten notes into a structure I could defend, because the next morning I would have to defend it — first to myself, then to the people who would ask me the hard questions back home.
What I brought back was not a transcript. It was a synthesis: what mattered and what didn't, where the risks were, what I was certain of and what I had been unable to pin down. It was better than any summary I would have produced with all my tools available. I have thought about why for years, and I think the answer is uncomfortable.
Tools for postponing
Tools for looking things up are also tools for postponing understanding. When you can verify later, you don't have to understand now. The gap between what you actually grasp and what you believe you grasp stays comfortably hidden, because nothing ever tests it in real time. You leave the meeting with notes, a sense that it went fine, and a list of things to check. The checking gets done — mostly — and the understanding gets assembled afterwards, piece by piece, from sources you didn't have to argue with.
That process produces something that looks like understanding and often functions as understanding. But it has a specific weakness: it was never stress-tested at the moment of acquisition. You never had to say, out loud, in front of someone who knew more than you, "I don't think I follow — can you say that again?" So you never found out which of your assumptions were wrong. The wrong ones survived, quietly, into the design.
Remove the tools and the gap is exposed immediately. You find out, in the room, where your understanding ends — and the only way to extend it is to ask, right then, while the person who can answer is in front of you. It is a more uncomfortable way to learn. It is also faster, and the result is more reliable, because every piece of it was tested the moment it went in.
What the constraint actually builds
I don't romanticize this. Being able to search, ask and verify is a good thing, and I would not give it up. What I'm describing is not a case against tools; it is an observation about what tools let you avoid, and what you lose by avoiding it.
The thing the constraint builds is a habit, and the habit outlives the constraint. The people I trust most in technical discussions all have it, and I'd bet most of them acquired it in some version of that room. The habit has three parts.
First, they build the synthesis before they speak. They don't narrate their notes; they tell you what the notes mean. When they don't know what the notes mean yet, they say so, instead of reading them out and hoping meaning emerges.
Second, they separate what they know from what they assume, and they do it unprompted. This is the part that looks like a disclaimer and isn't. It is the shape of their knowledge, made visible. Someone who says "the first two points are confirmed, the third is my inference" is giving you something far more useful than someone who presents all three with equal confidence.
Third, they ask the embarrassing question early. They have learned that the cost of asking now is a moment of discomfort, and the cost of not asking is a wrong decision discovered weeks later. That trade is so lopsided that, once you've seen it clearly, you stop being embarrassed.
Where this bites now
I think this habit is becoming more valuable, not less, and the reason is obvious once stated: answers are now a prompt away. Whatever you ask, something will produce a plausible, well-formed reply. That is enormously useful, and it is also the most sophisticated tool for postponing understanding ever built. If you don't know whether you understood the question, a fluent answer will not tell you. It will make you feel that you did.
So the scarce skill — the one that was always the real skill — is knowing whether you understood the question. Being able to say which parts of the answer you can vouch for and which you're taking on trust. Noticing the ambiguity before the answer paved over it. None of that comes from having better tools. It comes from having been, often enough, where the tools couldn't help, and having learned what your own understanding feels like when it's actually there.
The practical version is simple, and I still do it. Every so often I put myself in a situation where I have to explain or decide something without being able to check — a review where I commit to a position before opening the document, a conversation where I answer first and verify after. Not as a stunt. As a diagnostic. It tells me, fast and without mercy, what I actually know. Most of the time the answer is reassuring. Occasionally it isn't, and those are the occasions worth having.