Why your best engineers stay silent in meetings

It's not that they don't have questions. It's that you've made asking them too expensive.

Jan 20, 2026

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Every engineering leader has sat in a meeting watching heads nod along to something that made no sense. You’ve done it yourself. The architecture diagram that seems to have three impossible arrows. The product requirement that contradicts itself in adjacent sentences. The technical explanation that assumes knowledge nobody in the team actually has.

And here’s what happens next: nothing. Everyone leaves the meeting, everyone pretends they understood, and two weeks later you’re debugging a system that was built on a foundation of collective confusion.

This is a leadership problem, not a comprehension problem.

The real cost of silence

When people on your team don’t understand something, they might not tell you. They tell each other - on Slack, after meetings, in hallway conversations you’re not part of. Or even worse, they tell no one. They just quietly build the wrong thing, make incorrect assumptions, and hope the gaps in their understanding don’t matter.

The cost isn’t just the rework. It’s the damage in psychological safety. Every time someone nods along to something they don’t understand, they’re reinforcing the belief that confusion is shameful. That asking questions is risky. That appearing knowledgeable matters more than actually being knowledgeable.

As a leader, you’re either actively dismantling this dynamic or you’re reinforcing it. There’s no neutral.

Some will stay silent

Your senior engineers aren’t staying quiet because they’re insecure. They’re making a rational calculation based on the environment you’ve created.

Think about the last time someone asked a “basic” question in a meeting. What happened? Did someone sigh before answering? Did the explainer use phrases like “as I mentioned earlier” or “this should be straightforward”?

These micro-signals accumulate. Your team members are pattern-matching on every interaction, building a model of what’s safe and what isn’t. If asking questions carries even a small social cost, most people will pay the larger cost of confusion instead.

The irony is that your most senior people might have the hardest time asking questions. They’ve built their credibility on being the ones with answers. Admitting confusion feels like a threat to their standing.

The value of visible confusion

Confusion, surfaced early, is one of the most valuable signals. It tells you where your documentation is weak, where your architecture is hard to reason about, where your product requirements have gaps.

Hidden confusion, on the other hand, is pure liability. It compounds. It shows up as bugs, as missed deadlines, as systems that work in ways nobody intended.

The difference between these two outcomes is almost entirely about culture. And culture is leadership.

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Making confusion visible: the leadership playbook

Creating psychological safety around confusion isn’t done by giving speeches or putting values on the wall. It’s exhibiting and advocating for specific behaviours, repeated consistently, until they become norms.

Start with yourself. In your next technical discussion, find something you genuinely don’t understand and say so, out loud, in front of your team. Not a humble-brag about some obscure edge case. Something real. “I’m not following how this handles the failure mode we discussed last week. Can someone walk me through it?”

This works because it’s modelling. You’re showing your team that senior people ask basic questions. That confusion is expected, not embarrassing.

Reward the question, not just the answer. When someone asks a clarifying question, especially in a meeting, explicitly acknowledge it: “Good question - I was wondering the same thing” or “Thanks for asking that, it’s not obvious.” You’re not being patronising. You’re creating positive reinforcement for a behaviour you want to see more of.

Change how you run meetings. Before ending any technical discussion, pause and ask: “What’s still unclear? What are we assuming everyone understands but maybe we don’t?” Then wait. The silence is uncomfortable, but it’s where the value lives.

Create private channels for confusion. Not everyone will ask questions in group settings, no matter how safe you make it. That’s fine. In your 1:1s, explicitly ask: “Was there anything in this week’s planning that you’re not fully clear on?” Make it routine. Make it expected. Make it safe.

Separate learning from evaluation. One reason people hide confusion is that they’re worried it affects how you perceive their competence. You can help by being explicit: “I don’t expect anyone to understand this immediately. My job is to make sure you have what you need to figure it out”. Then follow through - never use a question someone asked as evidence against them.

Documentation

There’s a pattern I’ve seen work well: whoever has to struggle to understand something becomes the person who documents it. Not as punishment, but as recognition.

The reasoning is simple. The person who just figured something out knows exactly what was confusing. They remember the mental model that didn’t work, the assumption that tripped them up, the question that finally unlocked it. Fresh understanding produces the best documentation.

This also flips the script on confusion. Instead of being something to hide, it becomes a contribution. “I didn’t understand this, so I documented it for the next person” is a statement of value.

As a leader, you can encourage this by asking: “Now that you’ve figured this out, would you mind writing up what you learned? The next person to hit this will thank you”.

A deeper principle

What you’re really building isn’t just a culture where people ask questions. You’re building a culture where the organisation learns faster than the problems it faces.

Every system has complexity. Every codebase has dark corners. Every product has requirements that don’t quite make sense. The question isn’t whether confusion exists - it always does. The question is whether that confusion stays hidden until it causes damage, or surfaces early enough to be addressed.

Your job as a leader is to make surfacing it the obvious, safe, rewarded choice.

One thing to try this week

In your next team meeting or technical discussion, wait for a moment where something isn’t fully clear. Then say: “I want to pause here. I’m not sure I fully understand how this works, and I’d guess I’m not the only one. Can we walk through it together?”

Notice what happens. Notice how people respond. Notice whether the room relaxes or tenses.

That response tells you something important about the environment you’ve built. And it gives you a starting point for the environment you want to create.