Someone has to ask the dumb questions

Here’s a scenario that is likely to feel very familiar: You’re in a meeting, and you’re convinced that everybody is talking past each other because they are making a different set of unspoken assumptions about the topic at hand. You want to speak up, an idea or question simmering in your mind, but you end up dismissing it as too obvious or simple to voice.

The fear of looking foolish

The hesitation to ask simple questions often stems from a fear of judgment, a nagging imposter syndrome whispering that such inquiries might reveal incompetence. Yet, in my experience, it’s quite the opposite, and “dumb” questions often cut through assumptions and lay a clear foundation for understanding. It might well be that everybody is coming to the discussion from the same angle, but, more often than not, different perspectives cause misunderstandings whose impact may not become evident until much later, when you have already invested considerable time and resources into the wrong idea.

A few years ago, I was called in to help a couple of tech leaders resolve a long-running conflict about the use of microservices. I started by asking each of them to articulate their point of view, without the other interrupting. One was adamantly against microservices, and had come to the meeting with a long list of resources to back up their argument that monolithic applications were much easier to maintain. Unsurprisingly, the other leader held a mirror image of this point of view, and claimed that microservices are superior because they make it possible to break a complex system into simpler components that can be evolved and improved more quickly.

I let the conversation go on like this for a little bit, then raised my hand and asked a single question: “What is a microservice?”

My interlocutors stopped their bickering, and almost in unison turned to look at me with a mix of incredulity and contempt on their faces. For the first time in the better part of an hour, they seemed to finally agree on one thing: I was either incompetent or crazy for asking such a stupid question. What business did I have being in this discussion if I didn’t even know what a microservice was?

“Humour me,” I said. “Would one of you please explain what a microservice is?”

The person who was in favour of monoliths rolled their eyes, sighed and said something along the lines of “Well, a microservice is a tiny standalone application that provides a single piece of functionality. You could have, say, a microservice for checking passwords, one to manage a user’s personal information, and yet another one to manage their permissions. You can see why it’s so attractive: Small services feel like they should be easy to write and maintain because they do one thing and one thing only, but in reality you end up with a complex matrix of applications that require a lot of network traffic to communicate and are known to fail in spectacularly difficult-to-predict ways.”

“Hold on,” piped up the other person. “That’s not what a microservice is at all. You’re not supposed to create a different service for every little activity… otherwise, of course you end up in a mess of applications that is impossible to maintain. What I had in mind was splitting our big monolithic application into separate systems that are logically grouped together. For example, we could have a system manage everything that has to do with the user—authentication, authorization, settings, and so on. That way, there could be a team dedicated to maintaining that functionality, and we wouldn’t end up with bits and pieces of it spread across multiple parts of the codebase like we have today.”

Neither person was looking at me anymore. The monolith advocate was silent for a few seconds, then spoke up again. “Hmmm, but then what you’re describing is nothing more than a set of well-designed APIs that every part of the codebase must use rigorously. Do we really need to have multiple services? I’m worried about managing all the network interactions.”

I’ll spare you the rest of the discussion, but asking the dumb question led to a breakthrough in the discussion—not because I knew more about microservices than these folks, but because they were going at the problem from two very different perspectives that they had not bothered to reconcile.

Making dumb a norm

Seasoned professionals often instinctively ask these questions, mostly because they’ve been bitten by the consequences of leaving them unanswered. They understand the value of clarity and are confident enough in their status to not worry about how they’ll be perceived. If you’re just at the beginning of your career, however, it can be really hard to stick your neck out.

In a great working environment, the process of asking “obvious” questions is normalized by design and encouraged. The simplest way to do so is to be upfront about it. Start by saying, “This might seem like a basic question, but I want to make sure we’re all on the same page.” Ultimately, you want to foster a culture of openness and curiosity, where every question is a stepping stone to deeper understanding and better solutions.

Even if you’re not in an environment where this is the norm, you can still ask basic questions by saying that you want to make sure you fully understand a problem so that you can make meaningful contributions. In my experience, folks won’t mind spending a little time explaining things if they believe they’re helping someone else—and will often end up helping themselves in the process.

Embracing the practice of asking ‘dumb’ questions isn’t just about getting answers. It’s a tool for building a stronger, more cohesive team dynamic where ideas and clarity thrive. So, the next time you find yourself hesitating to ask that dumb question, remember: it might just be the key to unlocking a more productive and insightful discussion.