Were Not Really Stranger Questions

What People Are Actually Asking About This

I keep seeing people post about this in various corners of the internet, and most of the answers I've seen are either too surface-level or completely off base. So I'm going to write down what I know from actually working through this stuff, not from reading blog posts about it. Were Not Really Stranger Questions is essentially a framework for identifying when a question someone asks isn't really the question they should be asking. It comes from a place of pattern-matching — noticing that a lot of the problems people bring to table are misdiagnosed at the root level. The technique was loosely popularized in certain online communities around 2021, though the core idea pre-dates that by quite a bit. It's not a formal academic concept. It's more of a heuristic you pick up by doing a lot of problem-solving work and realizing that 60% of the time, the stated problem and the actual problem are different things entirely.

Were Not Really Stranger Questions

The name is a bit of a meme reference, sure, but the mechanic behind it is straightforward. When someone presents a question, you pause and consider whether the question itself is misframed. The most common form of this is when a person asks how to do X, when the real issue is that X isn't the right move to make in the first place. Another variant is when someone asks a technical question because they don't want to admit the real concern is organizational or social. Here's a specific example from my own experience. I was consulting on a project where a team lead came to me asking why their automated deployment pipeline was failing on Fridays. Every single Friday. The question seemed very technical on its face. I spent a couple of hours looking at logs and configurations before I realized the actual pattern: the senior engineer who had written most of the pipeline code left the company in late June, and his replacements hadn't touched it. The Friday failures weren't a technical issue. They were a coverage gap. The team kept asking the wrong question because the surface symptom looked like a bug. The workaround I ended up using was simply to document the pipeline's dependencies and assign an on-call rotation specifically for that system, which resolved the issue within a week. I wasted about two days chasing the original question before reframing it. This is the core practice. You have to be willing to tell someone that their question is wrong, and you have to do it in a way that doesn't make them defensive. That part is harder than the analytical part. I've found that framing it as "let me make sure I understand what you're trying to accomplish" rather than "that's not the right question" gets you significantly further. People respond differently when you approach from curiosity instead of correction.

One thing beginners consistently miss is that this framework doesn't apply to every question. If someone asks you a direct technical question and they actually want a direct technical answer, applying this heuristic will make you look pretentious and unhelpful. The signal for when to use it is when the question feels oddly specific, when the person seems stuck in a loop of troubleshooting the same issue, or when the stated goal doesn't seem to match the actual outcome they're chasing. In those cases, the question is probably a stranger. There's also a significant limitation worth noting. This approach can easily slide into arrogance if you're not careful. The line between "helping someone see their misframed question" and "talking down to someone about what they really mean" is thin. I've seen people use this framework as a way to avoid answering questions they didn't want to deal with. That's a failure mode, not a feature. If you find yourself reframing someone's question more than once and they still seem confused or frustrated, you've probably gone too far. Back off and just answer the original question directly. The other practical issue is time. Reframing takes longer upfront than just answering. If you're working in a context where quick responses are expected — a help desk, a fast-moving Slack channel, a support ticket — spending twenty minutes deconstructing someone's question is usually not the right call. The framework works best in environments where there's room for dialogue and iteration.

I've also noticed that this heuristic tends to work better for complex, systemic problems than for simple technical ones. Asking "how do I fix this broken SQL query?" doesn't benefit from the framework. Asking "why does our reporting system keep producing inconsistent numbers across departments?" does, because that kind of question almost certainly has layers beneath the surface. The complexity of the problem is a decent proxy for whether the question might be misframed. There's no official download or tool for this. It's a mental model, nothing more. Some people have tried turning it into checklists or decision trees, and those can be useful as reminders, but the actual practice lives in your judgment. You can't algorithm your way through recognizing a misframed question. It's pattern recognition built from experience, and experience is the one thing you can't outsource. The closest thing to a practical guide I've seen is a short set of prompts you can run through internally before responding to a tricky question: What is the person actually trying to achieve? What assumption is baked into how they're asking this? What would the right question look like if they knew what they really needed to know? Those three steps take about thirty seconds and catch more misframed questions than I care to admit.