Hacker News Reader

Comment by andrewla | Hacker News Reader

This has happened to me frequently at my current company. I get pulled into a meeting about something that I have no context on because it touches my area of expertise, and the discussions have apparently been stalling out.

I brace myself to be the idiot. I'm going to waste everyone's time asking questions that everyone knows the answer to, and I just got looped in, so everyone's going to feel like they need to walk through all the super-obvious stuff to satisfy the one guy who didn't do his homework.

So I start asking questions, and slowly begin to realize that nobody in the room has any idea what they are talking about. That there are fundamental misunderstandings and misconceptions about existing systems. And, naturally, it turns out that the questions I have are questions that other people have.

This has happened to me so often now that you would think the sinking feeling I get before I brace myself to look stupid would go away, but it never does.

View on HN

One of the best people I've ever worked with used this approach. "I'm going to ask stupid questions now." and "Just so I'm understanding the problem, <here's my interpretation of what you just said>." were two phrases she used all the time.

I am surprised at how difficult it has been to emulate her technique. Feeling comfortable asking the obvious questions is one half of the battle, but the other, more difficult half, is knowing what obvious questions to ask. Most of the time when I ask obvious questions, the replies are yes/no. She knew how to ask them in such a way that gets the person talking in greater detail.

It's kind of like being a great interviewer, there's a technique to asking questions in a manner which gets someone talking.

VP in my org does this, and it really disarms the room.

She’s big on that exact phrase of “this could be a really stupid question, but…”

She’s also really good about making sure other people are rewarded for doing the same by reassuring someone asking what might be a dumb question as, “that’s a a great question and I’m sure others were wondering the same…” before responding.

Great leadership, IMO.

In the group where I did my PhD, one of the professors would do this (but without pre-announcing). He would start with really basic questions and gradually build up to more complex questions.

This was great for two reasons: 1. it builds up large common ground for understanding; 2. if someone in a leadership position does this, others will not feel ashamed of asking questions that they think may be basic.

My PhD advisor was great at doing this. Just having him in attendance at colloquium made the talks more informative.

An EVP of Ops of a fortune 500 did this to an entire room of functional experts.

We were there to discuss a technical implementation.

She kicked it off by saying "Let me start by asking a simple question, why do we do this function?"

I am now considered a domain expert. I love this question. It surprises me at how few people start with the why, or even can articulate the why.

The room of experts, were assembled to roll out a new product in their area of functional expertise. None of us had an articulate answer as to the why. She kept on asking. She gently challenged bad answers with a follow up why. Then when everyone gave up, she gave her answer as to the why. It was brilliant.

Always start with the why. Then ask why again. Keep on asking until you understand why.

If it was just a setup to eventually providing an answer she already had in her pocket, is that the same thing really that's being discussed? Willingness to look stupid and earnestness to find an answer?

I like to assume everyone has a positive intent, until proven otherwise.

I always ask people why, because I sometimes learn something new, I often learn about the knowledge level of the other participants, and it anchors everyone to the fundamental problem we are trying to solve.

Sounds a bit like the Socratic method [1], just used for making sure everyone is aligned with the fundamental goals.

As someone who's recently been put in a position to make sure everyone's aligned (and failing quite a bit at it), it sounds like genius, in my opinion.

[1] https://en.wikipedia.org/wiki/Socratic_method

The Socratic method is where they eventually realize the answer, not one where you make them all feel frustrated before finally revealing it.

I assume frustration levels for both come down to the soft skills used to run the process.

Wielded w/o skill, the Socratic Method comes of patronizing and trite.

To stay respectful, it is polite to negotiate with all participants in its use.

To be fair, Socrates' goal was to make them realize they didn't actually have the answer, they only thought they did.

It doesn't seem like the same thing as asking dumb questions to uncover the truth that nobody has yet synthesized.

When you already (think you) know the answer, then it's a pedagogical technique. That's ok unless you happen to be wrong about the answer.

It may be that along the course of asking why 10 different times from different people she was able to identify the answer. It sounds like she got quite a few fragments of answers first.

There is an interrogation technique called Five Whys. I believe it was created by S. Toyoda, and was and very is effective in root cause analysis. The basic idea was to ask a question and follow up with "Why?" until an answer contained an alterable behavior... that answer would usually come with the fifth why. Once in a while I use it in a business meetings, and as long as the person who is being questioned doesn't get defensive or hostile, it is surprisingly effective.

5 Whys is great for getting depth into one causal subtree, but based on a paper I once read, answers can lack breadth when there is more than one cause (which is often the case). It said that "Why" is often best answered with a directed acyclic graph of causal relationships.

(Though when I tried to use a causal DAG for root cause analysis of an incident at my current company, I was told that I was wasting time and no one cares. But I thought the data I found was pretty interesting and worth exploring.)

Regarding the lack of breadth of a 5 whys analysis, there is a fishbone diagram that can be used before the 5 whys to ensure more breadth.

In manufacturing there is usually 4 big topics (person, machine, material, method), but there are many variations that can be used.

Trees or other visual depictions can be used too.

The point is to have some sort of structure and adapt it to your needs.

Similar here. Was pumped in an RCA with "why?" multiple times. The 'root cause' was I fucked up and missed something. But that was because "prod was broken right then, fix ASAP!" and no one else understands the problem, and we're understaffed, and people 'reviewed' the code without understanding what it was doing (or why) and one 'fix' led to another problem, and that 'fix' led to a third, and trying to explain this in an 'RCA' meeting confused the heck out of everyone because there were 3 different days/times people saw the problem, and could not understand it was one original thing that triggered, with cascading problems in the 'fixes', etc.

You keep asking "why?" and only want one 'thing' to be 'actionable'... you will raise my frustration level. The root cause is an emergent property of understaffing, poor communication practices and a belief that everything can be reduced to a jira card providing sufficient context and understanding for a diverse audience with different skills and needs.

In a japanese company that I worked at previously, answering RCA must be clear and in detail way. I got used to it so when I explain something to people, I want them to NOT ask any further question again because I compiled all the information they needed, including prevention. Their next response should be "got it understood" or clarifying their action. Other than that, I think I failed to explain things in a very basic way

> The 'root cause' was I fucked up and missed something.

It's really hard to do RCA when people are blaming themselves. It had to suck to be in that meeting. A really good RCA isn't about finding a single actionable thing, it's about finding our what the root cause of the problem is... which in this case, might have been whatever originally broke production and caused an emergency fix that failed three times.

"It's really hard to do RCA when people are blaming themselves"

Often, the root cause is someone made a mistake. You can say there should have been other systems to prevent/review/etc, but the root cause is a mistake a person made. You can '5 whys' it to death, but I made a mistake (or... someone did).

"whatever originally broke production" - in this case, I made a mistake. That mistake wasn't caught until production. Then the fixes were all broken too.

I don't always blame myself for everything, but if I've made a mistake, I'll own up to it. For me, it helps me be aware of what I can do to avoid those in the future. This may or may not be some rca-checklist other people can refer to, because... it's not 'actionable' to anyone but me.

sometimes I go straight into technicalities for the sake of time (to colleagues at the same level) and wonder if they actually understood what i said.

I like it when they ask basic questions. at least then I can then explain the basics to them without having to feel like I'm patronizing.

I would honestly take a hefty payout to work for this person.

I love these examples, they helped me realize that I'll often preface "this could be a really stupid question" and then ask the question—even though I'm quite confident I already know the answer—because I had sensed that other people in the room might have been feeling lost. I actually do this quite often, even when I'm hearing two people talk with each other but actually talking past each other.

Also, I just took a training and observed the trainer hear a participant say that she felt frustrated with the process, and then the trainer immediately asked the room something like, "How many other people are feeling frustrated as well?" And of course, numerous hands went up, and it seemed to help show the person she wasn't alone.

Long time CTO here. I brazenly and declaratively ask stupid questions and suggest stupid ideas. It usually leads to a break in a logjam, and I recognize that people in the room don’t always feel as free as me to be naive or uninformed. It’s the nature of my job and the coverage I need to manage across the org… devs aren’t as inclined to go this route, but this is also why some of my personality driven PMs are often so successful in a similar vein… they’re not invested in being or looking right, or even smart.

fuck that it’s salesmanship, and salesmen make poor leaders.

which as a salesman i’m definitely in position to comment

Yes, thank you, this is very important. Whenever someone says they might be asking a stupid question, I make sure to interrupt and remind that there are no stupid questions, only stupid people asking questions.

>> Most of the time when I ask obvious questions, the replies are yes/no. She knew how to ask them in such a way that gets the person talking in greater detail.

Dumb question here, but is it as simple as starting your question with "how" or "what" rather than "does"? The former invite explanation and the later looks for a yes/no.

My big thing lately is to not ask rhetorical questions (which can be sarcasm in disguise) as they either cause people to be defensive or simply agree. Either way they do not speak directly about the "obvious" problem.

> Dumb question here, but is it as simple as starting your question with "how" or "what" rather than "does"? The former invite explanation and the later looks for a yes/no.

Yes, this is the 101 of basic interviewing in journalism. Inexperienced reporters often ask too many "does" questions and are puzzled afterwards as to why the interviewee didn't talk much.

"Does" is also used when the journalist aims or pushes for a straightforward, yes-or-no answer. For example to interfere to a politician who is trying to avoid direct answers by trolling the interviewer with some off-topic agenda.

Also, this is a funny proposal with regard to the Five Ws: https://www.newyorker.com/humor/daily-shouts/additions-to-th...

& "(can you) describe (how) ..." is supposedly helpful too

> Dumb question here, but is it as simple as starting your question with "how" or "what" rather than "does"?

I really appreciate that you used the technique that people were discussing and it still seemed to work here, at least it worked on me. I found myself thinking, "No no, that's not a dumb question at all and I feel grateful that you asked it!"

So, thank you for that meta experience :-)

One thing you learn in sales is the value of open-ended questions. Until you consciously look at it, it's hard to realize how bad the questions we tend to ask are.

Yes/no questions are the worst. But even questions like "What did you do?" aren't great because the answers can often be rather short.

A better question is often posed like "Tell me about X" or "Describe how you did Y".

Of course this isn't universally true, there is value in binary answers.

But often you may find yourself, let's say in a sales context, asking something like "What tool are you using for project management?"

The answer will then be something like, "I'm using Jira".

Instead, if you ask, "Tell me about what you're doing for project management on your team", the answer may be much more detailed.

"We follow the agile methodology and use Jira for our task management. We've got a dedicated project manager on the team who..."

Getting good at asking the right questions is worth the effort.

That depends. Yes/no questions are great when you want to quickly validate something. Open-ended questions are great when you want to get a lot of information. Yes/no are for confirmation, open-ended for exploration. Different goals.

Hmm. Often times, an open ended question results in a much more accurate answer. Humans tend to approximate or even lie to force an answer to fit a limited choice question. Example: you want to know if water is falling out the sky. You ask: Is it raining? Response is no. You walk out the door and are rendered unconscious by golf-ball size hail.

Better to have asked, "what's it like outside?" or, "what's the weather right now?"

I think his response meant in situations where you just need to figure out which project management tool they use so you can log in for the first time, binary questions are the right tool for the job (information gathering). But I mostly agree that, in the big picture, the broad questions are more helpful for solving the complex problem you’re facing.

and nobody is going to say it’s not raining when it’s hailing outside… but I understand if that was just a metaphor. You’re probably asking that question to figure out what kind of clothes to wear, and they would probably infer that. It’s so contextual though.

Again, I think that depends on where you are in the exploration/confirmation spectrum. I don't really think about it when doing it, but usually I use open ended questions for stuff I don't know, and yes/no questions to link things to my existing mental model.

That also depends on the person. With some people open ended questions are great, with others yes/no are better.

I'll also add that yes/no questions are often faster if you get the response you expect.

Maybe appending "... Or something else?" to a limited choices question can avoid the problem GP @indymike mentioned, whilst still generally be quick

Is it raining or something else outdoors?

Do you like Vi or Emacs or something else?

Do you want to hang out for a coffee or something else?

Usually I don't think it's necessary. My yes/no questions are something like "Okay, so we need to put some more info into that file since that's what exported to the billing database, is that correct?". When I don't know something, I try yes/no questions at first. If I get "yes", then it's resolved. If I get a no, I will ask open-ended questions to explore the subect. Once I think I have a correct mental model ready, I will ask yes/no questions to validate it. If I get a no, then it's the cycle again.

For the "Is it raining outside", I honestly don't know anyone that would just tell me "no" when there's hail outside. For the "Do you like Vi or Emacs or something else?", it would be "What text editor/IDE do you use? Why?". "Do you like Vi or Emacs" by itself is not a yes/no question, it's a "what box are you in" question. For "Do you want to hang out for a coffee or something else?", that would be something like "Do you want to hang out at <TIME>?".

An important part for me is that in yes/no questions, no are supposed to be the exception. In my mind, when I ask them, it's not a 50/50 chance. It's more of a 80/20. If it was a 50/50 chance, that means my mental model is not precise enough.

A similar technique is demonstrated in the old Video Arts So You Want To Be A Success at Selling? video series starring John Cleese, in the Part 2 video ("The Presentation") iirc, in a scene where a salesman uses the Five Whys (or what is effectively that, though the term isn't used) to prevent the loss of a customer account.

> "I'm going to ask stupid questions now." and "Just so I'm understanding the problem, <here's my interpretation of what you just said>." were two phrases she used all the time.

This is my approach when getting pulled into something. If I have no idea, I want to get that idea. I'll also use "this may sound stupid, but..."

One of the smartest people I've ever met in business was also this way. He also never nodded his head in agreement unless he actually understood and agreed. If he wasn't sure, he'd pause for a minute and work it out, even if it meant pausing the flow of the meetings. Some people interpreted it has him being "slow" but it really meant he actually understand all of the things he was nodding to.

Huh, interesting. I've done this pretty much my whole (programming) career. As a non-traditional, I always felt it was a weakness to be "that guy", but it's good to know that it's a common tactic.

Luckily, I've always been around coworkers that never put me down for asking those questions.

Reminds me of something from decades ago in India, there was only television channel and it was state run. Early evenings were dedicated to rural areas and farmers there.

Most of them were illiterate and did not understand what plant scientists or professors were talking about re inputs or seeds or Tractors etc needed to modernize Ag.

So the format would be an interview in the middle of a coconut grove or a farm. The interviewer(usually female) would ask a question and the expert would answer. After he finishes answering, she’d turn towards the camera and go like “what you are basically saying is..” or “what he is saying..”..and she’d give the wrong details. Then the expert would interrupt her and explain it again with the correct answer. There were a lot of English words he’d use and she’d break them down in the vernacular and also in the same order as his sentence.

These wrong things repeated by her were obvious misunderstandings anyone unfamiliar with fertilizer application would make…it was probably scripted so that the answer can be ‘corrected’ multiple times and also probably reflected mistaken notions by the viewer. Never once was the viewer(here, it was the illiterate non English speaking village farmer) made to feel dumb but always as though they are learning something valuable and special.

It was like Sesame Street for farming adults. It was awesome and kept me glued to the television screen. I would memorize all the IRRI rice hybrids and probably was the only one in school who knew IR20, IR64 and IR8…and urea application rates for them.

Ask anyone of a certain age who their favourite Sesame Street character is …and you would have cracked effective communication technique for that time period.

This is brilliant. I sometimes produce educational videos to teach kids programming. A recurring challenge we have is pitching the information at a level that’s interesting but not confusing for beginners and kids who are less literate. This format I’d like to try out

https://www.indeed.com/career-advice/career-development/acti...

When you active listen, even if the question might feel stupid, the feeling gets lost in the fact hat the other person is receiving your attention. This technique is also teach for other contexts like counseling, or debating using the Socratic method.

I've had PMs always lead questions like that, using "this is probably a stupid question..." and alternatives and I came to dread discussions with them, as I knew this meeting would involve loads of wasted time constantly 'excusing' their question instead of just asking it.

Just how long do they draw it out? Phrasing "So, stupid question: [insert question" really shouldn't add that much time, right? Or is the problem that the questions really are stupid?

I have a weird job title but my position is probably closer to your PM, and I also use this strategy, so I'd like to know how to not annoy people!

Sounds as if you're doing it in a good way :-) (I'm not GP)

Thanks for the suggestions. I'm commenting on this thread so I can save it for future reference.

Perhaps a better approach is to click on "favorite" at the top. I personally find it easier than trying to go through my comments history.

Additionally, if you click the timestamp of a comment, you can “favorite” the individual comment!

It’s embarrassing how long it took me to find that button.

this is also part of a coterie of non-threatening communication most women implicitly learn while growing up, to realize desired outcomes without negative pushback.

Am woman, hard agree!

I don't like to say "I'm going to ask a stupid question". First of all, it feels disingenuous to me, people who say that never actually think that their questions will be stupid. And the second reason is that I think I might even convince myself that my questions are stupid... I know it sounds silly to some but little things like how you talk about yourself (and your questions) is important.

I often ask these "stupid" questions, though. I usually start with: "it might have been said in other meetings, but just to be sure, what is...", "I might be a bit slow, could you explain X once again just to make sure I understand it", "So just to paraphrase what we've been discussing, X is Y, is that correct?", and sometimes I just ask "what does $acronym stand for and why is it important for us now".

I, too, often find that nobody knows the answers to very basic questions and we are in a meeting of 6-12 people...

>> First of all, it feels disingenuous to me, people who say that never actually think that their questions will be stupid.

I preface some of my statements with this, and I fully expect them to be stupid. In fact, many of the questions I ask that I don't preface with the above disclaimer are in fact quite stupid.

Yeah I feel the same way. I never understood the "This may be a stupid question..." framing.

Asking fundamental questions in order to build up to a more complex understanding is the most effective way to learn, I have no hesitation about asking such questions.

One reason for the framing (when used by a senior person or someone in authority) is to give permission to more junior people who may be holding back on their own questions because they are afraid of looking bad.

It can easily backfire. Some one who has an urgent but basic question might refrain from speaking up if, beforehand, a senior prefaces their pointed probing question with "this is a stupid question...".

It's better to just kick things off with naive questions or even use a bit of humor to disarm people, so they don't feel like they have to be "advanced" all the time.

You don't say this is. You say "this may be" a stupid question.

The point is not that anyone with the same question should feel stupid; it's that I don't care if anyone thinks I am.

Depending on who is asking, the intention behind such framing is different. For someone in a leadership position, the point is to open up dialog and make folks comfortable enough to ask questions without them feeling they're at risk of humiliation or judgement. For others it may be to signal politeness and deference to the speaker.

Whatever the case, there are more effective, more genuine phrasings to use than to literally invoke "stupidity".

> more effective, more genuine phrasings

Examples please?

I was thinking about:

"I'd like to ask some things that might be obvious to many of you: ..."

> people who say that never actually think that their questions will be stupid

I use it all the time. Oftentimes they are stupid questions. Sometimes they're not, but generally that's when I'm not sure if it's a stupid question or not. And that's okay—the point is, it's fine to ask stupid questions.

Yeah, I like this tactic, but I don't think phrasing it with the word "stupid" is helpful.

I prefer to say things like "I'm not fully up to speed on this, so let's go back to basics/fundamentals for a moment", or "sometimes we're so focused on the details that we can't see the wood for the trees - let's take a step back and just run through it at a high level again".

That just sounds like corpratese though, the stupid question is much better in my opinion.

With yours it's to easy for someone to switch off and not hear what you said because they think you're talking bullshit.

In two sentences you managed to cram in 5 idioms/phrases that are basically corporate babble.

They sound like someone avoiding directly admitting that they don't understand something. Unwillingness to look stupid.

Gareth321 here https://news.ycombinator.com/item?id=28955167 mentioned "basic" instead of "stupid"

Yeah, to pretend to be "stupid" and basically dismiss your own question is kind of cloying or may be seen as disingenuous or even passive aggressive.

Folks who are good at communicating can always keep everyone feeling engaged and comfortable, while still getting to nitty-gritty WITHOUT resorting to saying stuff like "... this is stupid question, but...".

They're not pretending to be stupid. It's that they think their question might be stemming from not understanding something fundamental that everyone else in the room already knows.

If you think they're being disingenuous because you think they do understand what's going on, then it actually supports why they feel the need to preface their question with that phrase. You expect that they know it, so they make questions around it less jarring by admitting that they probably don't know enough.

In my view, admitting that you "might have a stupid question" is not disingenuous, it's a form of self-depreciation that disarms people and relaxes the room.

It's important to treat yourself with respect, but people also respect when you admit that you don't know something simple.

It's "self deprecation", depreciation is something different.

I'm not sure what kind of audience you think it works on.

I tend to get (particularly from people under 40) one of two inappropriate reactions to reflexive self deprecation - either exaggerated sympathy for my plight, or treating it as an exposed weakness to attack.

Whoops, yes I meant self-deprecation (I added an 'i' by accident)

Yes, some people will pity you, or treat it as a weakness. But having the courage to admit when you don't know something is a valuable trait that most people (in my experience) respect.

Also if you demonstrate your knowledge in other areas and contribute value to the meeting, people tend to forgive a few stupid questions in another area.

But "courage" is exactly the sort of response that bugs me. It's not courage, or passive-aggressiveness, it's etiquette. Responding with praise, or pity, or a put-down, it's all a failure to appreciate the formula for what I consider basic etiquette.

It's like when I'm having a meeting with my manager and I want to talk, so I start, they stop, I apologize for interrupting, and they say no, no, go on.

I assume there is no emotional drama going on. If they really want to continue talking, they can do so. That's why I apologize and pause. I'm not sorry, but I need to show appropriate deference.

It would be unfortunate if someone was building up resentment because they're not on the same wavelength about appropriate behavior. The purpose of etiquette seems to me to provide a formula to negotiate common situations without having to navigate emotional complexities.

But when different people have different rules, there's not much that can be resolved.

It's all about reading the room. If you're talking to a hostile crowd you're not going to expose weakness. I hope that most of these internal alignment meetings are not hostile, and are instead conducted with the intent to best deliver value to the business. In these instances, I have found comments like "I'm sorry to ask a basic question here..." work well to explain that I probably don't have as much domain experience as the others in the room; that I'm not trying to school them on their domain; and that I'm simply trying to gain understanding so that I can contribute.

"Basic questions" sounds nice :-) more nice than "stupid questions" I think.

(Probably the questions aren't literally stupid, or the person maybe would never have been hired in the first place)

"I'm sorry to ask a basic question here..."

Sure...but I think that an insight that I've gained is that this is an example of a formula which doesn't really communicate or explain all the things you mention. You aren't sorry, you don't know that your question is basic, and you don't think you're wasting peoples' time.

In effect, it's a "pointer" to a bunch of things, so it only works with people that are conditioned to such things and have them in their memory. One of the things you mention, "not trying to school them" sounds to me like deference, and I don't think deference can be quickly established without a formula. Like a salute, you have to do something arbitrary in a mutually understood way.

I think some of this might be cultural. For example, I think self-deprecation may be in general more widely appreciated in the UK than the US (though perhaps this is gradually changing).

I’m reminded of Arthur Dent (British) in the Hitchhiker’s Guide telling Zaphod, modestly, “oh, it was nothing” about something great he did, and Zaphod responding along the lines of “oh, it was nothing? In that case forget it then”, which was not at all what Arthur intended.

Well, I'm American, and there were definitely bits in that book that totally failed to translate for me. For instance, "Ford Prefect" seemed like a perfectly normal name - IMO the American edition should've changed it to "Ford Escort".

But being self-deprecating was not one of them. I feel like I'm surrounded by Zaphods, or something, and I'm not sure when it happened.

> ...it feels disingenuous to me, people who say that never actually think that their questions will be stupid.

I ask questions that have a decent chance of making me look stupid all the time. Even when the rational part of my brain says "if you have this question, it's likely that other people do too," there's a big part of me that worries, "nah, I'm the odd one out here."

> First of all, it feels disingenuous to me, people who say that never actually think that their questions will be stupid.

No, I often legitimately think that my question might (!) be stupid, because I'm aware that I'm coming into the discussion with less domain knowledge and experience than the other people in the room. I still think it's good for everyone (ie, not just me) to explain. (Sometimes it's clear that everything is just out of my league, in which case I shut up and let the meeting go on.)

It's this very awareness of one's own limitations that allows folks to overcome those limitations. If I might add my own (personal, biased, narrow) understanding; the whole concept of "stupid" is like a cognitive filtration mechanism. We filter ideas that others have by calling them "stupid" and then we attempt to avoid being filtered in that way, but that filter is kind of stupid. Unless you already know everything (protip: you don't) you run the risk of filtering based on an incorrect assumption.

I prefer using “basic” over “stupid”. A basic question is literally about the basics or fundamentals, while a stupid question implies something is wrong with the asker to even need to pose it.

I do this all the time. I'm a non computer engineer who gets pulled into all sorts of computer related things as the contact point with the actual business. Having a good BA and someone who asks stupid questions make such meetings end in positive results much more often.

I also preface with saying I'm going to ask stupid questions and if anyone holds it against me I'm ok with it. If I'm asking a question it's usually because I don't understand a consequent of something someone said that everyone seems to just nod their heads and agree with, and that gives everyone an opportunity to reconsider the fundamentals.

Whenever new people join the team, I always say, "Please ask stupid questions. I mean questions so stupid that you might think we would question why we hired you, because you think we think you should already know. Ask those types of really stupid basic questions. It will educated you, make us think, and I'm certain at least one other person already on the team doesn't know either."

I usually say, "please ask stupid questions, because if you don't then you'll run off in the wrong direction and work on the wrong thing for a week before the next review, and you'll have wasted a lot of project budget."

At my work, there's a bad combo of senior folks who whip off vague instructions in a single sentence, and junior folks who are afraid to ask questions. I'm in the middle, and I try hard to demonstrate that it's fine to badger the senior folks with questions, and to check in with them constantly. The senior folks like it because it gives them confidence that you're working it out. But some of our straight outta school colleagues just don't do this ("Gotcha. Sounds good!" is a very common email reply from them) and it leads to confusion down the road. After giving them the "ask questions" talk two times, I usually give up on them.

Also, in my position, I often have to review and edit reports that are largely written by electrical engineers and architects, and they all probably think I'm super dumb. I read the reports as the target audience (often non-subject matter experts), and so my comments are things like, "What do you mean by this [basic EE concept]?" I don't preface it with, "I know what this means, but the client might not, please elaborate..."

Please, please keep doing this and encouraging this behavior. The more senior on the ic track you get the harder it is to find time to mentor. The reality is that is a core tenet of our position and we may be staying silent to not smother the room. If you need help and you have a competent senior they should encourage your questions or delegate to an appropriate senior if they are too busy.

> I usually say, "please ask stupid questions, because if you don't then you'll run off in the wrong direction and work on the wrong thing for a week before the next review, and you'll have wasted a lot of project budget."

Does it help?

This sounds like they are expected not to waste time, so it might get even harder to ask a stupid question a minute too late, and especially to ask something tomorrow.

So far it completely depends on the person.

But you’re right that it might not be the best technique. I understand the hesitancy to ask questions after a certain amount of time has passed.

I work as a consultant and our time has to be billed to projects. The onboarding stinks, so the new hires often have no concept of billability/utilization nor project budgets. So I’m trying to drill in those concepts, too.

One of the additional lessons here is “the boss doesn’t always know what they’re talking about.” And that’s another hard one for them to accept. Question authority! If the instructions aren’t clear, then they might be nonsense. Have the guts to challenge the boss. And sometimes the challenge can come in the form of a million stupid questions.

> The onboarding stinks, so the new hires often have no concept of billability/utilization nor project budgets.

As an aside, do you think there is a business opportunity in teaching companies better onboarding? Growing headcount seems like an afterthought most places, and it’s a colossal waste.

The worst example I’ve seen is one company hiring some very expensive onshore consultants to build the basic structure of the application and then quickly hand it off to cheap offshore ones.

What really happened is that the onshore guys created a horrendous mess of untested and undocumented code full of bugs that the offshore ones had no hope of making sense of. And being remote and from a culture of high power distance further exacerbated the problem. It certainly worked out well for the onshore guys who got to bleed the client out of a whole other year’s worth of expensive hours.

The company I work for has 60k employees. I think during the pandemic - which started before I joined - we let go of a ton of office managers and the in-house IT team. So now there is one office manager for each local office, and she had no capacity or skill to answer my semi-technical questions when I joined (“how does the software licensing work?” etc).

So, maybe. It’s risky, like you’ve demonstrated.

> But you’re right that it might not be the best technique. I understand the hesitancy to ask questions after a certain amount of time has passed.

Something like this maybe: go to the new person, in the beginning every day, then once a week, then once a month, and say:

"Can you please ask three (3) basic questions about things you're slightly struggling with, and that you think everyone expects you to know, but that you don't?"

I've stolen a similar technique from one of my favorite coworkers ever, which is to preface my questions but "This might be a silly question, but...".

I like this because I feel like it kind of de-stigmatizes asking "obvious" questions. If you acknowledge that the the question might be redundant, but ask it anyway, I think it makes the dialog more approachable.

I think the biggest effect it has is that it stops people from thinking "is he stupid?" and getting annoyed at the question.

On my last team I coined the hashtag #StupidQuestionsEncouraged and used my role as a lead to both ask stupid questions and encourage others to do the same.

Yes, these are two great phrases and methods to vastly improve your communication skills! Many people seem to be OK with leaving a conversation with assumptions instead of assurances.

I think I possess this skill (at least partially), and the trick of "knowing what to ask" is to train yourself heuristics that guide you towards questions that reveal outstandingly large amounts of new information. Of course you have limited information, so those determinations about how much information a question's answer would yield are plagued by that. Hence the heuristics.

This is not easy to learn, and great understanding ability is a prerequisite.

For me, I think it's about your speed of thinking. If you ask a probing stupid question and get a "yes". If you are quick to reassemble your very low level of understanding into a (wrong) model, you can ask question about this model. "So that means that x goes into y to do z?" which makes you indeed look stupid but it also triggers the person explaining into "ok, this is a full out idiot, I need to go slow and explain in extreme detail". But then I interrupt when it goes to slow with a new pieced-together temporary model from some fact they let out and ask a new maybe less stupid question that makes the explainer go "ok, maybe they understand a bit more" and goes faster/skips details. And then it's like that back and forth until I understand it all and my questions goes into the territory of "yeah, that bit I don't understand either..." which leads us to go on a joint adventure into even greater understanding. A fellowship of the stupid.

My own issue with this method is trying to avoid sounding like I'm vying for brownie points by demonstrating knowledge after asking (what to them might be) a rudimentary question, especially so if my "update" is partially incorrect. It is to the point where I won't show someone I am aware of something simple they have just pointed out to me. Which either is something the author of the blog would condone or I have misconstrued in which instance it is useful to look like you have less understanding than you really do.

The top Business Analysts always posses this skill, too.

the problem with this approach is that it makes building trust very difficult, as trust is based on a combination of character and competence.

inquisitiveness during problem solving is admirable and good, but in the article many of the applications of 'looking stupid' only serve to render the author untrustworthy.

I know this might come off as adversarial, but might that say more about your metrics for trustworthiness than the party at question? Which bullets from the article would you consider untrustworthy?

Same.

“Just making sure I understand this correctly… stop me if I’m wrong” has worked wonders for my ability to contribute to a meeting.

> Most of the time when I ask obvious questions, the replies are yes/no.

I guess you might be asking straight up binary questions like - is it happening due to xyz? Maybe, changing the question format to something like - what do you think could be the cause behind _fill the situation here___? Just my humble opinion.

> That there are fundamental misunderstandings and misconceptions about existing systems.

This is debugging 101. You have assumptions about how a system works, but the output isn't matching those assumptions. You walk backwards over your assumptions and test them to see if they are true. Eventually you get to the precise place where your assumption is wildly different than the output, and there is your bug.

The more systems (or people) involved, the longer it takes, the more complexity.

Yep, eventually you're asking things like, "does the variable called 'username' contain the username?" Not too long ago I found that 'username', in fact, did not contain the username.

I once had a co-worker at a small company (2 developers, me and him).

In the spirit of doing less work, he proposed to me changing the meaning of "someProperty" to mean something different, without changing the name of that property.

Also, it was a boolean; so he wanted true values to actually represent false, and vice versa.

I politely pushed back on that one.

I work for the government so really know this feeling. I have a funny exemple in mind. Months ago I got pulled into a meeting because 'I know data'. The phrasing alone was a red flag. Lots of high level people in the meeting. Like 10 people, each one payed at least twice as much as me. The goal is to transfer data that is too big for our 'standard pipelines'. They are discussing building a whole new pipeline, contractors would be involved and all. I asked 'stupid questions': "- How big is the data we are discussing ? - '200 Go' - is it recurring ? - No - is it sensitive ? - No - Why don't we buy a 50$ 1to hard drive and transfer the data manually ?"

Last question was followed by the longest silence I ever heard in a meeting... I wasn't invited the next meetings. I heard it took them more than 5 other meetings to reconsider my solution. An intern has finally been sent to buy the hard drive last week.

I wonder if they felt that your idea made them look stupid / incompetent. (Which it seems they were)

Maybe then they didn't want you in the meetings?

(Whilst the idea was good so that's what they did in the end)

(200 Go = GB I suppose)

The problem was throwing the solution at their faces like that. The key to looking stupid is not making others look stupid.

There are ways to create roundabouts so that the solution looks “elegant” but only after “hard thought”.

There’s also the risk that the simple solution has some real limitation (eg. some regulatory issue) then you’ll will indeed look stupid

A lesson I've learned over time is that it's incredibly common for people within a company to have very different mental models of what different terms mean - especially if they work in different teams or departments, but sometimes even people the same team.

My favourite examples are things like "what is a user?" - the marketing department may be counting leads generated, engineers are thinking about records in a database table, some other team may think of users as company or group accounts.

This holds true for all kinds of other things too. You might have a project called "the login optimization project" and find that some people think it's about page load performance while others think it's about increased conversions.

For this reason, I'm always ready to ask the stupid questions.

> "what is a user?"

I have spent far more time than should be necessary aligning on terms like "customer" and "user."

I identify with this situation but my feelings about it are a bit different, although not intentionally. This mirrors my general disconnect with the article.

In this situation I feel some anxiety or hesitation about asking these questions, but I don't feel it as a fear of appearing stupid. Instead the anxiety seems to come from worrying that I am annoying or offending everyone with questions about things that are obvious.

I have no way of knowing which question is going to reveal the problem, so I will need to shotgun questions. I know that some people that I work with get this completely and will cooperate. Others will get defensive or tune out, so I need to find a balance or tone to try to avoid that.

It is similar to when I did tech support as a teenager and someone would call with a problem, wanting a tech sent to their house. I would start asking questions about the problem and they would not want to spend 5 minutes going through a few steps to try to solve it over the phone. I never felt that they thought I was stupid, I just felt they were impatient. Maybe they did think I was stupid, but I was so sure that I could find the answer that I never considered that.

I did support when I was in my late teens and I ALWAYS started at the very bottom, with the questions that seemed obvious, and worked my way up. Most callers thought it was annoying, so I would often prepare them for the silly simple stuff I was about to ask and ask them to humor me. It was especially painful if I was the 3rd person they had talked to.

I guess I still work this way although I've fallen out of the habit of warning people and asking them to humor me.

The "humor me" tier 2 or 3 tech support people are the best. By the time I've called in I've already done the usual stuff, that's why I called, at least they crack me up "what color is the light on the left side" or whatever, not just silence and clacking and background yelling of tier 1 while they "wait for me to power cycle".

Turns out I absolutely cannot do tier 3 support, but I can do 1 and 2 for friends and family and I'm the "whiz" or whatever. Tier three, for me, was basically me in a bad mood talking to me in a bad mood, in order to gatekeep the poor dev/DBA/NOC that had to actually fix things. No thx!

This is a useful skill to employ, though at the same time the frequent need of it is a sign of a dysfunctional system. Not always, but a lot of the time, I think. For one, many of these issues would be avoided if, for example, engineers were included in meetings with decision makers and designers during early phases of development, rather than introduce engineers to effectively tell them what to do now that all the decisions have been made absent any shared knowledge of how things can work under the hood. Not only could this result in reduced time spent, but it could result in less time performing re-iterations once engineering concludes that a request/feature is impractical. Impracticalities or better alternatives should be discovered as early in the process as possible, not later, because inevitably wasted time will be made up for via shortcuts and duct tape. Unless a company really cares about good craftsmanship and not releasing something until it's in an adequate state, quality will almost certainly be sacrificed.

Playing dumb, if you will, has served me well, yet it is also odd to me just how often it needs to be employed in the field of software.

You call it dysfunctional but I think it's just a communication technique to accelerate learning, like the author describes, that can be used in a plethora of situations and not just business meetings.

Oh, I definitely agree. My point, and maybe you still wouldn't agree, is that it can be a good technique to use under ideal or adequate circumstances yet also be a sign of functional weakness if it needs to be used too frequently.

Plenty of otherwise good things can be signs of dysfunction. An example could be a workplace where people are free to chill, do what they want, ride scooters, play games, etc., which can be really healthy and good for creativity, but also may be a sign of weak leadership and nothing actually getting done (wasting time and jeopardizing the future of teams). Having process is usually better than no process at all, but process can also waste time and be counterproductive.

In other words, nothing is necessarily to be viewed as good or bad.

Such behavior can be a good thing, but you could fall in your own bias thinking you know the problem better than them, to finally realize the problem outpace your scope and you are just impacted as anyone in the room.

It happen for me once, and this was an humility lesson.

Now I keep in mind I can feel I understand the problem then realize later I was all wrong too.

For sure! Another comment noted that this might be a sign of a dysfunctional organization, and I think there's a lot of truth there -- where systems have grown to such complexity that people involved in a larger project can't keep the whole thing in their head, and you get groups of people sort of faking it, assuming other people can fill in the details, and not wanting to appear ignorant about areas outside of your expertise.

I've been in other organizations (and even within this one) where my stupid questions revealed nothing new except that I had to go back and do some studying before I could usefully contribute.

I remember when I took a course in General Relativity as an undergraduate; I was much more math/CS focused than most people in the class, who were mostly physics people. And we would get together in study groups, and although I was respected for my general intelligence, it became clear that the questions I was asking were simply not the right ones -- that a physical/geometric intuition was something I did not have. In other words, I was actually the stupid one.

Much later I took a course in differential geometry, and eventually started seeing how it made sense mathematically, but I could never really connect it back to physical intuition. I think the problem that broke me was talking about the behavior of a point mass, and I had literally no idea how to attack that with the tools we had.

Yes, and I would argue this is one of the goals of asking basic questions. Specifically, when asking foundational questions, one of the objectives I keep in mind is to figure out the scope and my ability to understand the scope of the problem. Understand where that boundary exists is useful information.

Personally, I don't really care about this second-order effect that asking such questions might identify others that don't understand the problem correctly. I think it's, as you say, creating its own bias that pollutes your thinking. I've worked with enough experts outside of my own domain expertise, that this is not something that happens often.

Early in my career, I was conscious of asking these questions, so as to not appear like a fool, I thought I was expected to know the answers. I took a remote job a while back and realized that the only way to be successful in my role was to keep asking questions, learning about systems and the product. I did not care if my questions seemed stupid. I just asked away. And, it helped..immensely!

Yes and it feels like the older I get the more I have to be the one that plays this role to ask these basic questions as younger professionals are fearful to look dumb in front of others

The fear of looking stupid is a profound motivator in many professions. If you want to understand why so many of the stories posted about people using this technique are of more senior folks or people with more authority (bosses, mentors, professors, etc), this is why. Being willing to potentially "look stupid" requires enormous self-confidence.

And it may very well be that consequences for looking stupid are worse when you are junior. So it could be a natural progression.

This is me all the time haha sometimes I really am just "stupid" and the only one in the room without a clue, but many many times my stupidity has revealed no one really has any idea what they or the others are talking about.

I'm grateful to my parents or whatever it was that enabled me to not take myself too seriously and not care too much about people thinking I'm stupid, even at work, and even though it may cost me dearly in terms of career progression. (because I do think not all but many people who get ahead do so by very successfully avoiding being perceived as stupid, even if they are)

> you would think the sinking feeling I get before I brace myself to look stupid would go away

I can highly recommend reading, or listening to "Surely You're Joking, Mr. Feynman!". Asking "stupid" questions does not automatically make you intelligent, but it is a trait of highly intelligent people, exactly because of the reasons you describe.

We all know the story about how Newton asked why an apple fell to the ground, surely a lot of people would have thought you're a total idiot for asking that, and yet at the same time no-one would have been able to explain why.

The reason stupid questions are uncomfortable is that you're very likely to insinuate other people don't know the answer to a simple question, and we don't like making other people uncomfortable. Which is why you have to be humble when asking them.

> So I start asking questions, and slowly begin to realize that nobody in the room has any idea what they are talking about. That there are fundamental misunderstandings and misconceptions about existing systems. And, naturally, it turns out that the questions I have are questions that other people have.

I've had similar situations, it feels analogous to group based "rubber ducking"... having someone ask the questions perceived to be known or obvious by the existing groups can be extremely beneficial for all kinds of reasons, in the same way that a rubber duck (real or imagined) will get you to re-evaluate all of your assumptions and usually get you to find the assumption that's incorrect or problematic.

Imagine your comment being made in a meeting I got pulled into.

I brace myself. I'm going to waste your time. This is super obvious.

Here it goes: so uh, why do you continue to work with incompetent idiots instead of finding a workplace where people know what they are talking about instead?

Poor communication does not imply everyone involved is incompetent idiots. It's unfortunate, and important to address, but if you quit any project every time there is inadequate communication, you'll never get anything done.

Assumptions are inevitable. They get harder to question the longer they go unquestioned. Newcomers to a group can see them better.

Perhaps cutting people some slack and helping them work better by asking basic questions is a skill we all need to learn.

If you want to cut people slack, go cut them slack. Here's a question: look around you, you think cutting slack is what's needed?

If you think so, alright then. I don't.

I work with good people, and when they screw up, I cut them some slack.

Everyone sometimes screws up. Some more than others. Some distractingly so, and some so often that it's not worth continuing the relationship. But the mere fact that someone at some point screws up does not make them irredeemable. So, yes, I think cutting people slack is important.

This is totally orthogonal to being qualified for a job, or being good, or any other attributes people have that puts them out of their depth. If you work with a bunch of unqualified poseurs, then sure, slack isn't what's missing, and you should quit. But if you find yourself in that situation very often, I'd be asking different questions...

And nobody can know and do every damn thing that's why we have teams and an org. Sometimes you're in the room with experts from different specialties that don't understand each other. Sometimes you're in a team with very disparate domain expertise... Not getting anywhere in meetings is not always the sign of a dysfunctional org or stupid colleagues. It's everyday, everywhere, with everyone.

And. What if it's your customer in the room? Are you firing them for being 'stupid'?

The superclever types that thing their colleagues are stupid are often the most dangerous, as they'll just 'go it alone' and then leave when they fuck up and suddenly everyone is stupid and not grateful.

If someone asks a simple question, it’s great - because most likely executives will have the exact same question, but depending on your relationship with them, it could go a few ways (or more): 1) they just think you don’t get it because they assume the answer to the basic question and it’s not the assumption you’re operating off of 2) they call you on it during the presentation and make it look like you have failed to explain the fundamentals 3) they wait until after the presentation to ask the question, and others in the room aren’t really sure about it either, because you just assumed everyone knew.

I think it’s OK to ask dumb questions twice. If you don’t get it by the third time (or fail to remember), then we might need to step back and revisit fundamentals, or your mental model might need adjustment so that the information makes sense in context.

This happened to me recently,

A team I work with sometimes was blocked on a couple of PRs for about a week. I needed one of the team members for something and their lead wasn't doing much to help remove his roadblocks to helping me so I stepped in asking my really basic questions about what they were trying to achieve.

Within about 30 minutes we released one PR and deleted the other. The one we deleted was blocking the other but there wasn't actally a need for it due to some spec change that happened earlier, just nobody could figure out why it was needed or what needed to be finished before it could ship.

IMO this is the hallmark of a good engineer. One of my absolute favorite engineers/mentors did this. Having just one of these people in the room can be a huge differentiator in problem solving in a group setting.

This is feasible as long as your expertise is recognised in the organisation or you are in a position of power or your organisation is open to this kind of behaviour (quite often it isn’t the case). A junior asking this kind of questions in the wrong organisation may help fixing the problem at hand, assuming they are taken seriously, but they are likely to hinder their career progress if they repeat this behaviour too often. In many many many organisations looking smart is way more important than being smart.

(I’m not saying it’s a good thing)

This is essentially the Socratic method. Arriving at a shared understanding through the asking of questions. I employ this technique regularly and it rarely fails me.

Just to provide additional context...

This works and should be encouraged if you are indeed very smart and very quick, typically introverted and are actually going to be rolling up your sleeves to pitch in.

This approach is painful for everyone else and should be discouraged if you are a very extroverted and very non-technical person with no plan on actually helping out whatsoever with the actual execution on solving the problem at hand and really are only contributing to look smart in front of any leadership who happens to be in the room.

Definitely be aware of the Dunning–Kruger effect - which is a cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability.

I do this all the time too and have observed the same results! I ask a lot of dumb questions like "what does XYZ stand for?" and "what was the original problem you were trying to solve by taking this course of action?". Even though I always have that same sinking feeling, usually by the 4th or 5th question I have a very clear idea of what's going on.

This is my life at the moment. Even when I think I may know what is being discussed, experience has shown that a lot of people will try and fake it and being the idiot who doesn’t have a clue and needs it explained is useful for everyone.

I don’t know what it is about the IT trade, but so many people seem to find it difficult to admit that knowing everything is impossible.

> I have no context on because it touches my area of expertise, and the discussions have apparently been stalling out.

> I brace myself to be the idiot.

I don't think not knowing something makes one an idiot. Having hard time understanding something does. I don't think your example applies here.

This is such an eye opening experience, especially when you are new to the corporate world.

It's amazing how frequently fancily dressed, well speaking, high paid people sit in rooms and essentially role play being adults while just having absolutely no clue what is going on.

Probably because of status loss. Do they acknowledge your perceptiveness, intelligence and intellectual honesty after you demonstrate it each time? It would undermine their own status.

->nobody in the room has any idea what they are talking about

I have seen a few people unwilling to admit that they don't know...when they're supposed to know. The easiest way out they come up with is 'we will discuss this offline'.

Being able to say I don't know and I don't understand is incredibly powerful.

Happens to me all the time.

Reply on news.ycombinator.com