Humble Inquiry: Ask Questions You Can't Answer

The mental model

Humble Inquiry is a communication stance focused on asking questions from a place of genuine curiosity, rather than telling or advising. Coined by organizational psychologist Edgar Schein, it's about temporarily lowering your own status to build trust and learn what the other person truly thinks and feels. You ask because you don't know.

How it works

Humble Inquiry operates on three levels. First is pure inquiry, asking open-ended questions like "What's on your mind?" or "What would that look like?". Second is diagnostic inquiry, where you start to focus your curiosity on specific areas, such as "Can you give me an example of that?". Third is confrontational inquiry, where you introduce your own ideas, but still as a question, like "Have you considered trying X?". The key is to spend most of your time in the first two levels, building a shared understanding before offering solutions.

When to use it

Use Humble Inquiry when building relationships and psychological safety is paramount. It is highly effective in manager-report 1-on-1s, team retrospectives, coaching sessions, and user research. It's also critical during incident post-mortems to understand systemic issues without assigning blame. The goal is to surface information that wouldn't otherwise be shared.

When not to use it

Humble Inquiry is not appropriate in emergencies where direct, clear commands are necessary ("Shut down the server now!"). It's also less effective when a simple, factual answer is required ("What time is the meeting?"). Using it in these situations can seem evasive or unhelpful. It's a tool for exploring complexity, not for transactional communication.

One canonical example

A junior engineer says, "I'm blocked on this ticket." A manager using a telling approach might say, "Did you try X and Y? Go do that." A manager using Humble Inquiry would ask, "What have you tried so far?" and then "What was the result of that?" or "What's making it tricky?". This uncovers the real problem—perhaps a misunderstanding of the requirements or a flaky test environment—instead of just treating a symptom.