Ask the dumb question

The fastest way to lose an engineer’s trust is to fake technical understanding. The fastest way to earn it is to ask the naive question openly and defer to their judgment on their craft. As a PM, your value is not pretending to know how it works. It is being clear about what needs to happen and humble about how.

I ask dumb questions on purpose, and it has served me well.

Faking it is expensive

When a non-engineer nods along to something they do not actually understand, two bad things happen. The conversation moves forward on a misunderstanding, which surfaces later as wasted work. And the engineers clock it immediately, because they always can, which quietly tells them your input cannot be trusted.

So I do the opposite. I name the gap out loud. I will literally open with “dumb question, but,” and then ask the thing I do not understand. For example, when we were dealing with bugs, I asked plainly, might be a dumb question, but if the bugs exist in production, wouldn’t they also exist in staging, so shouldn’t we fix them there too? It is a simple question. Asking it openly got us to a real answer faster than pretending I already knew would have.

The naive question is not a weakness. It is the shortest path to a shared, accurate understanding, and engineers respect it far more than confident nonsense.

Defer on their craft

The other half of this is knowing where my judgment ends and theirs begins.

When we discussed having a teammate peer review another engineer’s work, I framed it as a good thing and added something I genuinely believe. It is always good to have peer review, because looking at the same thing all the time is an easy way to miss something, and that happens to me all the time. But then I made the boundary explicit. The engineer might have a different opinion from a technical perspective, and on that ground, his view should carry more weight than mine.

That is the posture. I own the what and the why, the problem we are solving and why it matters. They own the how. When we disagree on the how, I do not pull rank, because it is not my rank to pull. Deferring to their expertise on their craft is not weakness either. It is respect, and it is usually correct.

Why humility is the stronger position

It can feel safer to project authority, especially as a PM who does not write the code. In reality, humility is the stronger position with a technical team.

Admitting you do not know something invites the expert to teach you, which makes the decision better and makes them feel valued. Pretending you know shuts that down and makes the decision worse. Over time, the PM who asks good naive questions and defers on craft earns more real influence than the one who postures, because engineers will actually tell them the truth.

This connects to a bigger habit of mine. When a domain is not yours, you do not reason it out alone. You find the person who lives in it and ask. With engineers, that person is sitting right next to you.

Your job working with engineers is not to out-engineer them. It is to be crystal clear about the goal and genuinely humble about the implementation, and to make it safe for them to correct you.

So the next time you are tempted to nod along to something technical you do not fully follow, try the other thing. Say “this might be a dumb question,” and ask it. What is the question you have been afraid to look dumb asking? That is probably the one worth asking out loud.