The most obvious question
It’s something I repeat as often as I can: Always ask the most obvious question you can think of. This tends to come up in relation to a meeting, but is valuable in various contexts, including design or code review, strategy documents, and incident response. It’s hard, much harder than it seems. But it’s always worth the effort.
The most obvious question tends to be the one most visible to newcomers and most elusive to old-timers. It’s a consequence of the Paradox of Expertise: The most experienced people in a discussion tend to elide basic facts, common assumptions, and institutional knowledge in order to get to what they see as the decision or topic at hand. But it’s important to bring this background information to the front when a group is working together to solve a problem, or make a decision.
Consider a meeting.
MANAGER: We’re here to decide on committing to feature A, or feature B. We’ve been talking about this on and off for a month, we know the tradeoffs, and we need to make a decision so we can move ahead and plan our next sprints.
TEAM: … (Silent stares. Someone is fidgeting with the cardboard wrapper on their coffee cup.)
MANAGER: I’ve pulled up the memo on screen. This reflects the data behind the two feature ideas, and is current as of the last meeting. Does anyone have anything new to add?
Now, at this point, the junior designer in the room might think, Huh. The conversion funnel data points here actually remind me of these bug reports we keep seeing, showing that the existing feature is partly broken for mobile users. I wonder if we’d get the same benefits by just fixing that feature?
Then she thinks, …Nahhhh. Someone else here has seen those reports. It must not be an option.
Guess what, though? Nobody has thought of that. The manager has been working for so long on this feature memo that she’s developed blinders, and has stopped accepting new information or revisiting her assumptions. She’s also under pressure from the VP of Product, who wants to see some forward motion from this team. Even apart from her, the group in general has come to think of the existing feature as outdated, so it hasn’t occurred to them that it might actually just be broken.
The most valuable thing that could happen at this moment in the meeting would be for the junior designer to speak up and ask this obvious question that has surfaced in her mind. It could save the team months of effort. So, what needs to happen for her to talk?
Ask the dumb question
The paradox of the Obvious Question is that the most senior people, and generally the most white, most male people, will be the most comfortable asking “dumb questions.” They can say, “I have this one, really dumb question.” The subtext is, “You all know I’m smart, and I definitely know I’m smart, but I’m going to discount this big, important question as ‘dumb’ to protect all of us from the possibility that this group is wrong on a fundamental consideration.”
This is the same sense of safety that allows someone to bring up Chesterton’s Fence: “I know we all want to replace this feature. Do we have historical data or the original design doc to show why we built it in the first place? Has something changed since then?”
Problem is, the senior people are less likely to find the most obvious questions. A new teammate, or a junior employee, has the least institutional memory, and thus the least institutional bias. That’s an incredibly valuable perspective to bring to bear on a problem. But this newcomer, like the junior designer above, is hyper-aware of her newness. She’s trying to learn by listening to all of the seasoned hands talk through the situation. She doesn’t want to sidetrack the meeting with a question that will make the team think, “Well, that was a waste of time. She should have read the memo first. Ack, newbies!”
For the junior designer, speaking up is a risk. The key to enabling risk-taking on a team is psychological safety. How do we increase this sense of safety?
Increase psychological safety
I’ve found three effective ways to increase this sense of safety, in relation to asking questions. The first two are immediate and repeatable; the third is a long game.
1. Ask the most obvious question you can think of. Model the behavior and the attitude you want to see: You’re curious, willing to be wrong, asking permission of the team to “rewind” for a minute and consider something they glossed over or assumed.
2. Say out loud that you don’t think you’ve thought of the only, or the most obvious question. Say, “Does anyone else have any really basic, really obvious questions on their minds? Because I guarantee someone else is thinking the same thing as you, and not saying it out loud.”
3. Work on the diversity of that team. Diversity from every angle: Race/ethnicity, gender identity, socio-economic status, country of origin, career history, age, education, dietary restrictions, you name it. When you consider a candidate for the team, ask yourself, “How can this person increase the diversity of the team?” The more points of view in the group, the less a chance that any one member will feel like an outsider. Diversity on a team greatly decreases the risk of falling victim to prevailing opinion.
Diversity → safety → obvious questions → …profit
Remember that the reason this team needs to make it safe for the junior designer to speak up is ultimately to save the company months of misplaced effort. There’s real money, and heartache, riding on the group dynamic. There is absolute business value to working on this.