A few years ago I was in a kickoff for a new data platform. Fifteen people on the call, half of them senior, all of them nodding along while a director described an architecture diagram with about thirty boxes. I was nodding too. Then a principal engineer who had been quiet the whole meeting unmuted and said, “wait, sorry, I’m going to ask the dumb question. Why are we doing this at all? What’s the user problem?”. You could feel the room exhale. Nobody had verified the user need. The whole project, six months of planned work, was building on an assumption that turned out to be wrong by the end of the week.
That moment changed how I behave in meetings. He wasn’t being clever. He genuinely didn’t follow. He was the most senior person on the call and he was happy to look like he didn’t get it, because his job, in his head, was to make the right thing get built, not to look smart. Nine times out of ten, the “dumb” question is the one half the room secretly wanted to ask.
I’ve since spent a lot of energy training myself to be that person. The reflex to nod and pretend is deep. But the math, once you actually look, is so lopsided it feels embarrassing not to.
The asymmetry, in plain numbers
Asking the dumb question costs you, generously, thirty seconds of mild social discomfort. The person explains, you say “thanks, got it”, the meeting moves on. Approximately nobody else cares.
Not asking can cost you, depending on the meeting, a sprint, a quarter, or in extreme cases an entire project. You build the wrong thing. You design around a constraint that turns out not to exist. Or, mundanely, you spend three days trying to use a Python library in a way the docs would have ruled out in five minutes.
The dumb question I didn’t ask in the kickoff for an Airflow migration cost me about six weeks. I had assumed the new scheduler supported a particular SLA feature because everyone was talking about it as if it did. It did not. By the time I asked, “to be clear, is this going to give us the SLA semantics we had before?”, we’d moved fifteen DAGs over. Day-one cost: thirty seconds. Actual cost: multiple weekends.
Thirty seconds versus six weeks. You will not get a better trade in your career.
How senior engineers ask, and why it works
If you watch the engineers you most respect, you’ll notice they ask “stupid” questions all the time. But there are a few patterns to how they do it that make it land differently from how an anxious junior asks the same thing.
They don’t apologise for asking. There’s no “sorry, this is probably obvious”, no “I might be missing something but”. Those phrases telegraph weakness, and they make the listener vaguely sympathetic in a way that gets in the way of just answering the question. The senior version is closer to, “I don’t follow, walk me through it”, or, “wait, can you back up a step, why does that follow?”. It is direct without being aggressive. Curious without being hedged.
They ask in a way that makes it about the explanation, not their understanding. “I’m confused” is different from “explain that bit again”. The first is about you and your brain. The second is about the material. The second is much easier for the room to accept and answer.
They are willing to keep asking until they actually get it. This is the part juniors find hardest. The first follow-up is okay. The second feels excessive. The third feels like you’re being difficult. But often the actual confusion lives in the third question. Senior engineers will ask three or four times until they hit the bit they don’t understand, and then they’ll say so, and people will explain it. The room respects this more than people expect. What it does not respect is someone who asks once, says “okay got it”, and then twenty minutes later is still visibly lost.
A small phrase that helps me a lot: “let me make sure I follow”. It signals that you’re checking your own model, not failing at theirs. “Let me make sure I follow: when the upstream job fails, the downstream skips, but it doesn’t alert?”. This is neutral phrasing. It produces an answer, not reassurance.
Public versus DM, and the rule of three
Here’s a rule of thumb I picked up somewhere and cannot remember the source: if there’s a decent chance three other people in the room have the same question, ask it in the room. If you genuinely think you’re the only one, ask in DM after.
The “rule of three” matters because the cost of asking in a meeting feels personal, but the benefit is collective. You ask, and three people who were also lost get unstuck. You stay quiet, and four people leave the meeting confused, and the project moves forward on a shaky shared understanding. The asymmetry is so heavily in favour of asking that you should weight your default toward public, not private.
Where the DM is right: when the question is genuinely about you, your context, your gap. “I haven’t worked with Airflow before, can you explain what an XCom is?” is a DM question. “Why are we using XComs to pass data instead of writing to a table?” is a meeting question, because it’s about the design, not your knowledge. Most of the questions I’ve held back over the years were the second kind, dressed up as the first kind in my head. That is a useful thing to notice.
A side-effect of asking publicly: junior engineers in the room learn that asking is okay. The reason juniors don’t ask is partly because they’ve been watching, and they’ve concluded that experienced people don’t ask. If they see you ask, they’ll learn the opposite. Modeling matters here in a way that handing them an “it’s okay to ask questions” speech doesn’t.
The rubber duck follow-up
The last move I want to flag is what I think of as the rubber duck follow-up. After someone explains something, instead of just saying “got it”, I’ll often say, “let me explain it back to make sure I got it: so when X happens, the upstream Y fires, and the downstream Z reads from the queue. Is that right?”.
There are two reasons this is one of the most useful habits I have. First, it surfaces misunderstandings before they cost anything. About a third of the time, the person I’m explaining back to says, “almost. Actually Z reads from a different queue, and that’s important here”. Caught for the price of a sentence. Second, it makes the speaker feel heard, which is a non-trivial social benefit, especially when the speaker is a domain expert who is used to being half-listened to. Repeating it back proves you actually engaged.
I do this in 1:1s, in design reviews, in Slack threads, in incident calls. It is by some margin the cheapest thing I do that consistently saves me work. Engineers who are bad at this routinely build the wrong thing because they “got it” without really getting it. Engineers who do it well often realise mid-rephrase that they’re confused, and fix it before it becomes anyone else’s problem.
The rubber duck name is not coincidence. The technique is the same as rubber-duck debugging, where you explain a problem to a stuffed animal and find the bug because you had to put it into words. Doing this with a human who can correct you is even better. You get the benefit of articulating the model, plus the benefit of being told where the model is wrong.
Pretending to understand is the most expensive thing you can do
The thing I most want to tell anyone in their first few years of engineering is this: pretending to understand is by far the most expensive habit you can develop. It is more expensive than skipping tests. More expensive than not writing docs. More expensive than not pushing back on bad scope.
When you pretend to understand, you commit, silently, to building or maintaining something on top of a model that is wrong. Every line of code you write after that point inherits the wrongness. Every estimate you give is built on it. By the time the misunderstanding surfaces, often weeks later, you have carried the wrongness so far that unwinding it costs days at minimum, and the unwind itself is awkward, because everyone now has to admit they thought you knew. They didn’t ask either, after all. Curiosity, it turns out, is contagious. So is its absence.
The way out is the practice version of the rule. Every time you feel the urge to nod when you don’t understand, treat it as a flag. Make yourself ask. Even if it’s small. Especially if it’s small. The reps train the reflex, and within a year or so, the embarrassment cost flattens to almost zero, because you’ve simply stopped caring whether you look smart in meetings. You care whether you understand the thing. That is a much better trade.
Takeaway
The question you’re afraid to ask is, statistically, the most valuable question in the room. The cost is thirty seconds of looking briefly uncertain. The benefit is a sprint you don’t waste, a project you don’t misalign, a teammate who stops being silently confused because you broke the seal. Senior engineers ask without apology, ask until they actually understand, repeat back what they heard, and treat “stupid” questions as a load-bearing tool rather than a social liability. If you take only one habit from any career advice, make it this one. Curiosity scales. Ego doesn’t.