On asking stupid questions

I try to set a high bar for the questions I bring to colleagues. Anything I can figure out on my own — with a textbook, or now with an LLM — I do. So the questions I actually ask people are the ones that clear the bar; they’re not questions I’m too lazy to answer myself. They’re questions that reflect a gap in my understanding of how systems fit together — shared budgets, control loops, the codependencies between things designed by different people (and in different decades).

I’ve noticed sometimes those open-ended questions driven by curiosity seem to trigger defensiveness.

I work at a company where some products have been in production for decades. Some of the people who designed components are still around but no one person understands the whole system or production process anymore. So a lot of my questions get answered with “that’s how it’s always been done,” which is the least satisfying answer.

I’ve also noticed that sometimes more senior or more accountable people demonstrate more defensiveness, even when I’m asking as genuine curiosity, not as an accusation. Junior engineers sometimes light up when you ask them to explain their reasoning. Chief engineers and tech directors tend to hear an implied insult: that you think you know better, or that you think they haven’t thought it through.

I think what’s actually driving this is “accountability exposure.” If you don’t have a well-defended reason for a decision, an honest question can look like an accusation. That risk doesn’t really exist for a (junior or regular) engineer explaining their own code or build process. It’s very real for a decision-maker whose name is attached to a program.

(There’s a related pattern I’ve seen from the other direction: projects that are already perceived as shaky sometimes over-ask for money, headcount, or schedule — not because they need that much, but because it gives them a built-in excuse later. “We missed the timeline because we didn’t get the resources we asked for” is a much easier sentence to say than admitting the plan itself was the problem. An outsider looking at a request for three mechanical engineers when the team clearly needs one would flag it immediately; an insider has a ready explanation for why they need all three. That’s probably its own post.)

I used to think the fix was to be visibly non-threatening — just another curious engineer, not someone with positional power. There’s something to that. It’s disarming, and disarmed people tell the truth. If I ask why something’s done a certain way and the honest answer is “that’s how it’s always been done,” I’ll actually get that answer — because I represent no accountability risk to them. Whereas if a (Musk-like) CEO with a reputation for tearing apart requirements asks the same question, “that’s how it’s always been done” isn’t an acceptable answer, and everyone knows it — so people are more likely to reach for something that merely sounds defensible instead (but isn’t the truth).

But disarming has a cost: people don’t feel obligated to go deeper for you. A cursory answer feels sufficient when it’s “just another engineer” asking, because there’s no exposure on their end if you walk away only half-informed. Nobody’s going to do the archaeology to figure out why a legacy choice was made just because I asked. The CEO creates pressure for a real answer; I get permission to be told the truth, but only the truth someone already has on hand.

What’s worked better is treating the first conversation as reconnaissance, not the real conversation. I asked a tech director once, fairly bluntly, whether there was an actual plan to move a product from engineering articles through low-rate initial production to full-rate production — or whether it was going to be “try it and see.” That shut the conversation down immediately. Too blunt, read as an accusation, too much accountability exposure for too little context on my part. It was mistake not to read the room better.

But it still told me something: there was a plan, so I wanted to learn about it. When I learned what I could (which was not easy as the leads were not forthcoming), it still didn’t sit right. But I knew I couldn’t go back with a vague feeling that the plan was not adequate. So I went and modeled it myself — in this case, what does the EMD-to-LRIP-to-FRP transition actually require, where are the long-lead items, where does labor or facility capacity get tight when programs compete for the same resources. Then I came back with sharper questions: not “what’s the plan,” but “what’s the plan for the long-lead items,” or “what’s the plan when this program and two others need the same test cell in the same quarter.”

I found that starting broad enough to learn whether you’re missing context, and if you hit defensiveness, don’t push — go do the homework instead. Come back with a question specific enough that it’s obviously not a challenge to their competence, and specific enough that a vague answer would itself be conspicuous. That proved to reveal the difference between an engineer who tells you the truth because you asked in good faith, and one who tells you the truth because your question was too well-informed to deflect.

All that aside, I still ask stupid questions and I’m not afraid of looking stupid doing so. When I ask some stupid questions, I hope to look stupid because it would mean the answers were somewhat obvious, or what I feared being true was laughably far from the truth. I’ve always had a high tolerance for letting myself look stupid, and I was inspired to call it out as such when I listened to the “Relentless” podcast with Isaiah Taylor — highly recommend.