Who hasn't sat through a 40-minute architecture review where nobody asked a single question? The presenter walked us through diagrams, service boundaries, data flows, and deployment strategies. Heads nodded. People took notes. When they asked "Any questions?" the room stayed silent.
Afterward, walking back to our desks, a colleague leaned over: "Did you understand the part about the event sourcing? I didn't follow how that connects to the existing system." I admitted I had the same confusion. Over the next hour, three more engineers approached me with variations of the same question. We'd all been lost at the same point. We'd all stayed quiet.
That meeting cost us more than 40 minutes. It cost us a week of back-and-forth on Slack, two follow-up meetings, and a design revision that could have happened in real-time if any of us had just asked.
Why we don't ask
Here's the thing: we're not being lazy or disengaged when we stay silent. We're responding to programming that's millions of years old.
For most of human evolutionary history, survival depended on being accepted within small, cooperative groups of 50 to 150 individuals. Trust, reputation, and group standing weren't nice to have; they were essential. Exile or even marginalization could mean facing predators, starvation, or rival groups alone. Our brains evolved to be exquisitely sensitive to social evaluation because the cost of getting it wrong was death.
Brain imaging studies show that social rejection activates the same neural pathways as physical pain. When you feel that twinge of anxiety before asking a question in a meeting, that's your brain treating potential embarrassment as a genuine threat to survival. It's the same system that kept your ancestors from doing anything that might get them kicked out of the tribe.
Public speaking consistently ranks as one of humanity's most common fears, affecting roughly 75% of people. Some studies rank it higher than fear of death (which, as Jerry Seinfeld pointed out, means at a funeral most people would rather be in the casket than giving the eulogy). Asking a question in a meeting isn't exactly public speaking, but it shares enough characteristics to trigger the same avoidance response: you're singling yourself out, drawing attention, and risking judgment from the group.
Software engineers, in my experience, often have an additional layer to work through. We tend to be people who prefer time to process information before responding. We're trained to think before we speak, to consider edge cases, to not make claims we can't defend. Admitting confusion in real-time, in front of peers who might know more, can feel like a professional and social vulnerability we'd rather avoid.
What silence actually costs
Research on high-performing teams expected to find patterns around individual talent, optimal team composition, or management styles. Instead, the single most important factor was psychological safety: the shared belief that the team is safe for interpersonal risk-taking. Teams where people felt comfortable asking questions, admitting mistakes, and challenging ideas significantly outperformed teams where people played it safe. It wasn't about having smarter people; it was about people being willing to act smart together.
The research from McKinsey is sobering: only 43% of respondents report a positive climate within their teams. That means more than half of teams are operating in environments where people don't feel safe speaking up. Think about the implications. More than half of meetings have questions that aren't being asked, concerns that aren't being raised, and ideas that aren't being shared.
I've seen this play out in painful ways. A junior developer who didn't ask about a confusing requirement, then spent two weeks building the wrong thing. A production incident that could have been prevented if someone had asked "what happens if this service goes down?" during design review. A six-month project that went sideways because nobody wanted to be the person to say "I don't think we've validated that customers actually want this." The silence feels safe in the moment. The costs come later.
Seeing it from the other side
The insight that changed my approach didn't come from being in the audience. It came from being the presenter.
As I moved more and more into technical leadership and management, and started hosting meetings frequently and with different stakeholders, I developed a sense for where questions would arise. After enough repetitions, I learned to anticipate the tricky parts: the place where the logic gets dense, the transition that isn't obvious, the assumption you're making that not everyone shares. I could see it in people's faces and body language when something I said wasn't landing. The slight furrowing of brows. The pause in note-taking. That look of concentration that's actually confusion trying to hide. I think I also developed a spidey-sense for it from teaching children.
In those moments, I would hope someone would ask. Please, just ask. I can see you didn't follow that. But they rarely did. So I'd find myself going over the same material from a different angle, trying to clarify without explicitly calling anyone out for being confused. Sometimes it worked. Sometimes it didn't, and I'd only find out later when the misunderstanding surfaced in their work.
This experience from both sides, seeing the confusion as a presenter and feeling it as an attendee, eventually crystallized into a simple commitment: I would be the person I wished I had in my own meetings. When I was in someone else's presentation and I noticed that familiar look of confusion on a teammate's face, I'd ask the question. Not just for myself, but for them.
I've made this a deliberate practice now. When I'm confused about something in a meeting, I assume at least two other people share my confusion. When I have what feels like a dumb question, I ask it anyway. Not because I'm naturally comfortable with public attention (I'm not), but because I've been on the other side. I know what it's like to see the confusion and wish someone would just ask.
Here's what I've noticed: when you ask the "dumb" question, something interesting happens in the room. Shoulders relax. People lean in. Often, the answer reveals that the question wasn't dumb at all, that there was genuine ambiguity or complexity that needed unpacking. Sometimes the presenter realizes they skipped a crucial step (and they're grateful someone caught it). Other times, the discussion that follows surfaces issues nobody had considered. But here's what I think matters even more: you've just given everyone else permission to ask their questions too. You've demonstrated that this is a space where not knowing something is acceptable. The psychological barrier to the next question just got lower.
I've started thinking of it as a small act of leadership that anyone can do, regardless of title or seniority. You're not just getting your question answered. You're actively shaping the team's culture toward openness. You're being the person you wish you had.
How I actually do this
Being "the person who asks" isn't about being fearless or lacking self-awareness. It's about having a few techniques that make asking feel less risky.
Frame questions as clarification, not challenge. There's a difference between "That doesn't make sense" and "I want to make sure I understand, could you walk through how X connects to Y?" The first sounds like criticism. The second invites explanation. Same underlying confusion, very different social signal.
Take ownership of the confusion. "I might be missing something, but..." or "This might be obvious, but I'm not following..." These phrases acknowledge that the gap might be yours, which makes the question feel less like an accusation that the presenter was unclear.
Ask for examples or specifics. "Could you give a concrete example of how that would work?" is almost always a productive question. Abstractions sound clear until you try to instantiate them, and asking for specifics often reveals hidden complexity without implying anyone did anything wrong.
Voice what others might be thinking. "I'm wondering if others are curious about..." or "One thing I suspect people might be wondering is..." This makes the question less personal and explicitly signals that you're asking on behalf of the group.
Follow up when answers are unclear. If the response doesn't actually address your confusion, say so. "I think I'm still not quite getting it, let me try asking a different way..." It's tempting to just nod and figure it out later, but that defeats the purpose.
When not to be the person
I'd be lying if I said this always goes smoothly. There are situations where asking isn't the right call.
If the meeting is running long and your question isn't urgent, you might be better off taking it offline. Read the room. If people are visibly anxious to leave, asking a question that could spin off into a 15-minute tangent isn't being helpful, it's being inconsiderate. If you're genuinely the only person who doesn't understand something fundamental (and you're sure about that), asking might not be the best use of everyone's time. This is rare, in my experience, but it happens. "I should have known that before this meeting" questions are better asked privately.
If the question could come across as undermining someone's credibility, think carefully about phrasing and timing. There's a difference between "How would this handle a spike in traffic?" (legitimate technical question) and "Did you consider traffic at all?" (sounds like an accusation). The goal is shared understanding, not scoring points.
And sometimes, despite your best efforts, the culture simply isn't ready. I've seen teams where asking questions was genuinely career-limiting, where the unwritten rule was that you should already know everything. In those environments, survival might mean playing along while working to change the culture more gradually, or recognizing that you're in the wrong organization.
The ripple effect
When teams have someone who consistently asks questions, something shifts. The questions themselves become data about where communication is unclear, where assumptions differ, and where the team needs to align. Over time, asking becomes normalized. Other people start doing it too.
There's also something that happens when the team rallies to answer a question together. The presenter might respond first, but then someone else adds context, and someone else shares a related experience. The question becomes a shared problem to solve rather than an individual exposure to survive. That collaborative dynamic builds relationships in ways that silence never does.
I think about the meetings I've been in where I didn't ask, where I stayed silent because I didn't want to be the one. The architecture review at the start of this post wasn't an isolated incident. It was a pattern I repeated for years before I started doing things differently. All those meetings where I nodded along while being confused, then spent hours afterward piecing things together, could have gone differently.
We can't rewire millions of years of evolution. That anxiety when you're about to speak up is probably never going away entirely. But we can recognize it for what it is (an outdated threat detection system) and act anyway. If you're in a meeting and you have a question, there's a good chance someone else has the same question. They're waiting for someone to ask it. They're hoping someone else will be the person.
Be the person. Ask the question.